Firmware

[Tomek]

9 hours ago, lizardmech said:

You can already do this right now with the VESC though. Only reason it isn't possible to ride a EUC using it at the moment is no one is willing to finish the last bit of code while I finish working adapting the hardware for 60V+.

hmm, a simple first step with the firmware would be to hack a VESC-controlled hoverboard (no 60V+ needed)... I'm tempted to do it as a learning project, but waiting for VESC 6 to be released (although it's gonna be 2x the old VESC price at launch, ouch)

[electric_vehicle_lover]

2 hours ago, Tomek said:

hmm, a simple first step with the firmware would be to hack a VESC-controlled hoverboard (no 60V+ needed)... I'm tempted to do it as a learning project, but waiting for VESC 6 to be released (although it's gonna be 2x the old VESC price at launch, ouch)

Another option is to use cheap ready available $55 MicroWorks 30B4 board with the OpenSource Shane Colton FOC firmware, which have a lot of good documentation (unlike VESC), including balancing documentation and algorithm (yes, Shane Colton did a few balance systems like segways) and runs on the same microcontroller STM32F103 as the one on MicroWorks 30B4 and similar cheap chinese boards (including the most popular boards like Gotway, KingSong, AirWheel, etc, I believe).

I am going with this plan because I have all the resources I need and seems the most secure path for me, now I just need a bit more time to finalize the Shane Colton firmware analysis and I will start implementing it in small phases.
First phase will be keeping my current running motor code and measure the motor speed, Id and Iq currents, output them by bluetooth and make a graph on a spreadsheet, to verify that my current code lacks the FOC and that's why it works so bad at medium and high speeds... where phase error/rotor angle/Id current should be higher and need correction.

Edited March 13, 2017 by electric_vehicle_lover

[lizardmech]

13 hours ago, electric_vehicle_lover said:

Another option is to use cheap ready available $55 MicroWorks 30B4 board with the OpenSource Shane Colton FOC firmware, which have a lot of good documentation (unlike VESC), including balancing documentation and algorithm (yes, Shane Colton did a few balance systems like segways) and runs on the same microcontroller STM32F103 as the one on MicroWorks 30B4 and similar cheap chinese boards (including the most popular boards like Gotway, KingSong, AirWheel, etc, I believe).

I am going with this plan because I have all the resources I need and seems the most secure path for me, now I just need a bit more time to finalize the Shane Colton firmware analysis and I will start implementing it in small phases.
First phase will be keeping my current running motor code and measure the motor speed, Id and Iq currents, output them by bluetooth and make a graph on a spreadsheet, to verify that my current code lacks the FOC and that's why it works so bad at medium and high speeds... where phase error/rotor angle/Id current should be higher and need correction.

There's no point using those old boards, it should be easy to build a cheap vesc around $55 if you're willing to tolerate the same lower quality parts and 2 layer PCB like on chinese controllers. I'm not sure motor identification is practical on an older m3 core either. There's much better MCU options as well if you exclude VESC the f103 is just old and outdated now.

[electric_vehicle_lover]

Today I got the system to output the the commanded PWM value and motor speed (in erps - electronic rotation per second) over the bluetooth, recorded the values and created a graph. I am not sure the motor speed value is correctly in erps... but the value seems to follow the motor speed.

As usual the code is on github, here: https://github.com/EGG-electric-unicycle/firmware-gen2_boards/blob/modifiedFOC/motor.c

Next I want to calculate the motor Id and Iq currents and plot them, comparing to motor speed!!

Edited March 15, 2017 by electric_vehicle_lover

[lizardmech]

Do you have FOC code rotating the motor now?

[electric_vehicle_lover]

2 hours ago, lizardmech said:

Do you have FOC code rotating the motor now?

No and should take a while until I get it. For now no FOC, just the same old code. Since for FOC I will need to measure currents Id and Iq and control the current Id to be zero, I want now to measure Id current to compare in the end with FOC, to compare the winnings of having FOC. The only objective of FOC is to control and maintain Id current at zero - with that the motor will rotate at his best speed, lowest noise and best efficiency of energy consumed.

[lizardmech]

Don't you just take current A.B,C and do a park transform to get the id and iq values?

[electric_vehicle_lover]

3 minutes ago, lizardmech said:

Don't you just take current A.B,C and do a park transform to get the id and iq values?

Yes, and I am doing this (not tested yet), the same as in the code of Shane Colton:

    // ABC->dq Park transform
    // ------------------------------------------------------------------------
    float temp;
    temp = qfp_fmul(ia, qfp_fcos(motor_rotor_position));
    temp += qfp_fmul(ib, qfp_fcos((motor_rotor_position) + degrees_to_radiands(120)));
    temp += qfp_fmul(ic, qfp_fcos((motor_rotor_position) - degrees_to_radiands(120)));
    float id = temp;

    temp = qfp_fmul(ia, qfp_fsin(motor_rotor_position));
    temp += qfp_fmul(ib, qfp_fsin((motor_rotor_position) + degrees_to_radiands(120)));
    temp += qfp_fmul(ic, qfp_fsin((motor_rotor_position) - degrees_to_radiands(120)));
    float iq = temp;

Edited March 16, 2017 by electric_vehicle_lover

[lizardmech]

His method is strange, all the other FOC code I have take ABC currents and transform to alpha and beta using clark transforms then convert alpha and beta using park.

[electric_vehicle_lover]

Shane Colton does a simplified control method... he describes very well on his documentation.

[electric_vehicle_lover]

I used the formulas of TI training series 2014 (also the same VESC use I believe) to calc Id and I q:

//---------------------------
// Clarke transform assuming balanced currents
float i_alpha = ia;
float i_beta = qfp_fadd(qfp_fmul(ONE_BY_SQRT3, ia), qfp_fmul(TWO_BY_SQRT3, ib));

id = qfp_fadd(qfp_fmul(ia, qfp_fcos(motor_rotor_position)), qfp_fmul(ib, qfp_fsin(motor_rotor_position)));
iq = qfp_fadd(qfp_fmul(-ia, qfp_fsin(motor_rotor_position)), qfp_fmul(ib, qfp_fcos(motor_rotor_position)));

And the graph result:

And then switched to the formulas used by Shane Colton:

// ABC->dq Park transform
// ------------------------------------------------------------------------
float temp;
temp = qfp_fmul(ia, qfp_fcos(motor_rotor_position));
temp += qfp_fmul(ib, qfp_fcos((motor_rotor_position) + degrees_to_radiands(120)));
temp += qfp_fmul(ic, qfp_fcos((motor_rotor_position) - degrees_to_radiands(120)));
float id = temp;

temp = qfp_fmul(ia, qfp_fsin(motor_rotor_position));
temp += qfp_fmul(ib, qfp_fsin((motor_rotor_position) + degrees_to_radiands(120)));
temp += qfp_fmul(ic, qfp_fsin((motor_rotor_position) - degrees_to_radiands(120)));
float iq = temp;

And the graph result:

The code from Shane Colton seems to put the currents on positive values (as expected). When the speed is higher (or increasing) the Iq current is higher as expected, as also Id current.
The result have a lot of noise - I think it can be improved improving the timings where ADC measure (sync with PWM) and also improving the rotor angle calculation. I think I will do that on next steps and keep using the Shane Colton code.

[lizardmech]

I'm not sure if it's a good idea to use that much of his work was done around 2008-2010 when 8 and 16bit MCUs running at less than 20mhz were the norm. Trading performance or more complex software to try and reduce MCU workload is a really bad idea with the power of modern MCUs. You should download Ti control suite and motorware they have the best examples I have found. There's actually a few completely open source FOC servo drive examples in there, you could probably make a Ti based EUC in a matter of weeks. I want to use the ti f28377s it has an open source FOC example provided, the software is nicely documented, the motor control components are neatly split into separate macros and documented. Only reason I'm not using it instead of VESC at the moment is I don't know how to code mundane things like getting it to stream data over USB and adding motor detection code. 

[electric_vehicle_lover]

I want to learn and I prefer to go with the basics and grow from there ;-)

[lizardmech]

2 hours ago, electric_vehicle_lover said:

I want to learn and I prefer to go with the basics and grow from there ;-)

That's not the basics though, you're trying to use a relatively untested FOC design which likely has various complications, the open source Ti ones are very much superior. You have to make a centralized ISR like the Ti ones else you will end up with convoluted code like in the VESC 4.  The F103 is actually not so good for motor control the PWM and ADC are not good, likely why most EUC run low PWM speeds and are a little noisy. Even the F4 and F7 variants aren't well suited, all the things suited for motor control are in their F3 line but it's lacking in ram and CPU performance.

[electric_vehicle_lover]

I put the current to be measured always at the middle of PWM cycle, this way is avoided to measure while any PWM switching.
I also implemented the motor position interpolation (steps of 1 degree) and the motor is now quieter! Just after this I finally got good results on measuring Id and Iq currents...

I also filtered a lot the Iq and Iq current but still they seem to follow well the changes on the PWM so seems ok.

I will try the same code with another motor I have and see if I get the same results. For now, here is the graph of Iq and Iq currents (the power supply did measure 1.7A at motor max speed):

Video (note: the motor vibrates a bit and the loose shell seems to amplify the noise):

 

Edited March 17, 2017 by electric_vehicle_lover

[lizardmech]

Looks pretty good, will you start working on the EUC related functions soon?

[electric_vehicle_lover]

Finally I have FOC running :-)

Without FOC - power supply did measure 1.7A at motor max speed:

With FOC - power supply did measure 0.38A at motor max speed:

But the motor still have the vibrations and the same noise.. I don't think the noise is much lower with FOC (I am not sure if this motor is working well, that's why I need to test with another motor).
And as we can see, the current did lower about 4.5 times!! (however the speed did also lower a very small bit, about 0.08 times).
On the FOC graph, is clear that Id current (blue line) is trying to be 0 while the Iq current (red line) is the total motor current/torque, that increases when motor increases speed and increase with negative value (regen / charging) when motor decelerates!!

Next steps can be to test with another EUC motor and maybe improve and clean the code. Also current code is done only for rotating in only one direction, need to make it for the both directions. Then I also needs to do the estimator code for the rotor angle and compare with actual code that uses hall sensors. Then finally I should go to the balance / EUC application code.

Edited March 18, 2017 by electric_vehicle_lover

[lizardmech]

Mine is pretty noisy when run unloaded, I wouldn't worry too much.

[KingQueenWong]

@electric_vehicle_lover  Good Job! You can try to use Q15 or Q16 to increase Control Law speed.

[electric_vehicle_lover]

I th

11 hours ago, KingQueenWong said:

@electric_vehicle_lover  Good Job! You can try to use Q15 or Q16 to increase Control Law speed.

I think you wanted to say control loop speed. I am already using Q15, with the OpenSource lib Qfplib-M3: https://www.quinapalus.com/qfplib-m3.html

I am using the same modified FOC as Shane Colton and that means fast loop (at PWM frequency = 0.1ms) don't need heavy processing, jut the slow loop that I am now running at 4ms. With time I hope to improve and measure the times at each loop...

[electric_vehicle_lover]

I can't make run my old motor from my EUC nr 2... I already verified that the hall sensors sequence in the code is correct (I did debug and run the motor by hand to verify). I also changed the sequence of angles but also didn't worked.

My code runs on the motor of my EUC nr 1 but not on motor of EUC nr 2. As you guys can see by the pictures, the placement of the hall sensors are totally different..!!

MicroWorks 500W motor have the same hall sensors connections as my EUC nr 2.

Pictures:

- https://github.com/EGG-electric-unicycle/documentation/wiki/Motor-EUC1

- https://github.com/EGG-electric-unicycle/documentation/wiki/Motor-EUC2

- https://github.com/EGG-electric-unicycle/documentation/wiki/Motor

- https://github.com/EGG-electric-unicycle/documentation/wiki/Motor-MicroWorks-500W-30km-h

Can you guys help me to understand how should I drive the motor from EUC nr2?? For nr 1 motor I am displacing the rotor angle by 60 degrees on each hall sensor transition: https://github.com/EGG-electric-unicycle/firmware-gen2_boards/blob/modifiedFOC/motor.c

switch (hall_sensors)

{

case 8192:

motor_rotor_absolute_position = 100; // 4

break;

case 24576:

motor_rotor_absolute_position = 40; // 5

break;

case 16384:

motor_rotor_absolute_position = 340; // 6

break;

case 20480:

motor_rotor_absolute_position = 280; // 1

break;

case 4096:

motor_rotor_absolute_position = 220; // 2

break;

case 12288:

motor_rotor_absolute_position = 160; // 3

default: return; break; }

Edited March 20, 2017 by electric_vehicle_lover

[lizardmech]

Have you tried 120 degrees?

[Tomek]

the placement shouldn't matter as sensors detect each(!) magnet... but you seem to be making a mistake. each sensor ticks 47(if counted right) times per revolution, so imo it should be just 360/141 degrees displacement each sensor transition

...or am i confusing sth.?

[electric_vehicle_lover]

15 minutes ago, Tomek said:

the placement shouldn't matter as sensors detect each(!) magnet... but you seem to be making a mistake. each sensor ticks 47(if counted right) times per revolution, so imo it should be just 360/141 degrees displacement each sensor transition

...or am i confusing sth.?

@Tomek I couldn't understand what you mean. Can you please explain using other words?

After reading this page: http://mitrocketscience.blogspot.pt/2011/08/hall-effect-sensor-placement-for.html I think my EUC2 motor have the hall sensors at 60º while my EUC1 motor have hall sensors at 120º. I think the motors driven by 6 steps commutations have hall sensors at 120º and the ones by FOC have hall sensors at 60º - like MicroWorks 500W motor.

Still looking to understand what I need to do to driver my EUC2 and MicroWorks 500W motor...

[electric_vehicle_lover]

I measured the phases voltages when rotating the motor by hand - the voltages are the generated voltages, the BEMF. I used 3 resistors in a start and the common connection I connected to the board. I verified each phase voltage related to the same hall sensor signal and I got the following results when measuring the times between the same hall sensor pulse and motor voltage phase.

EUC1 motor:
Angle between phase A and phase B = (47 - 294) % 360 = 113
Angle between phase B and phase C = (172 - 47) % 360 = 125
Angle between phase C and phase A = (294 - 172) % 360 = 122

EUC2 motor:
Angle between phase A and phase B = (290 - 56) % 360 = 234
Angle between phase B and phase C = (171 - 290) % 360 = 241
Angle between phase C and phase A = (56 - 171) % 360 = 245

Now I will try to understand what should be changed on the firmware to make EUC2 motor working.