Firmware

[OliverH]

I had a look on my open MSuper (battery change/ preparing for Bluetooth mod) today. If it's making noise in the stand while changing the phases with small tilts/ forward/ backward moves between your feets the cables getting hot/ very hot. As I saw the first time the  cables routed to the motor I thought: they're pretty thin/ small. Only a suggestion what's going on and how high the current can be.

[electric_vehicle_lover]

Just tested new try for firmware. This time, the angle output is multiplied by a constant and the result goes to the motor duty-cycle:

// keep zero value angle when the board is on balance
  angle = INITIAL_ANGLE - angle;

  if (angle > 3) angle = 3;
  if (angle < -3) angle = -3;

  float kp = 15;
  speed = angle * kp;

  motor_set_duty_cycle ((int) speed); // -1000 <-> 1000

For what I can understand, there isn't a smooth transition on the motor direction changing... I need to figure what is need to have that. Maybe here is needed the PD or PID controller, as the oscillation seems that KP may be to high??
Any ideas?

I also measured the time that takes to read the IMU and it is about 15ms!! The control cycle should have this 15ms - the code is here: https://github.com/generic-electric-unicycle/firmware-gen1_boards/blob/balance_control/src/main.c

 

Edited April 23, 2016 by electric_vehicle_lover

[lizardmech]

Are you using the MPU6050 built in sensor fusion?

[electric_vehicle_lover]

No, I am getting the raw values from the MPU and doing the fusion in firmware.

[lizardmech]

I found quite a few code examples to study via youtube videos.

This one has quite good speed and balance, link to code is in comments.

 

[electric_vehicle_lover]

I am stuck

As you can see on the bellow videos, I tried to control the balance and doesn't work. And I don't think the problem is the calculation of the angle or such, as I did other test were I simulate the balance and expected the motor to stop or have almost no visible vibrations - as you can see on the last video, that's not possible.

I believe that while I can't stop the motor, I will not be able to make the balancing work :-(

Any ideas??

----

Just tested new try for firmware. This time, the angle output is multiplied by a constant and the result goes to the motor duty-cycle:

// keep zero value angle when the board is on balance
  angle = INITIAL_ANGLE - angle;

  if (angle > 3) angle = 3;
  if (angle < -3) angle = -3;

  float kp = 15;
  speed = angle * kp;

  motor_set_duty_cycle ((int) speed); // -1000 <-> 1000

For what I can understand, there isn't a smooth transition on the motor direction changing... I need to figure what is need to have that. Maybe here is needed the PD or PID controller, as the oscillation seems that KP may be to high??
Any ideas?

I also measured the time that takes to read the IMU and it is about 15ms!! The control cycle should have this 15ms - the code is here: https://github.com/generic-electric-unicycle/firmware-gen1_boards/blob/balance_control/src/main.c

Trying balance:

 

I did another test that is quick inverting the motor direction, just as I expect to happen when trying to balance. On this situation, I expect that motor stays almost stopped.
The video I registered, the direction inversion happens at every 15ms, to simulate the video on top, where the loop from the balance control happens at ~15ms (due to the minimum time needed for the read IMU values). I also tested to increase or lower this time of 15ms, from 150ms to 1ms and even 0.1ms.
The duty-cycle is configured by the potentiometer value and I tested to increase/decrease.
Decreasing the time to lower values of 15ms didn't improved much the result.

Here is the code:

  value = adc_get_PS_signal_value () / 16.0; // value is from 0 up to 4096
  if (flag == 0)
  {
    motor_set_duty_cycle ((int) value);
    flag = 1;
  }
  else
  {
    motor_set_duty_cycle ((int) -value);
    flag = 0;
  }

The result:

 

[electric_vehicle_lover]

I am not stuck any more :-)

So I was using SVM (Space Vector Modulation) to drive the motor - it's 3 phases always with current and not just 2 while one is off like some discussed before.
Happens that using SVM seems that I can't quick change the direction of the motor!! As discussed here the problems: 

But with SVM I have the motor running at his best speed and lowest noise...

And then I remember that at begin I were using another way to drive the motor (kind of a copy from original controller of my cheap EUC) that made a lot of noise at high speeds but at low speeds the motor could quick change direction and there was no noise.

So I went back (how I love GIT for version control ;-) ) to get the old motor control code and tried to balance and here is the result -- I am happy now :-)

 

 

The code is here: https://github.com/generic-electric-unicycle/firmware-gen1_boards/blob/balance_control-1/src/IMU/imu.c

But the main controller code / kind of PID is here:

// zero value error when the board is on balance
  current_error = INITIAL_ANGLE - angle;

#define ANGLE_MAX 2
  if (angle > ANGLE_MAX) angle = ANGLE_MAX;
  if (angle < -ANGLE_MAX) angle = -ANGLE_MAX;

  float kp = 1;
  float ki = 1;
  float kd = 1;
  float angle_old;

  progressive_term = current_error * kp;
  integrative_term += current_error * ki;
  derivative_term = (current_error - old_error) * kd;
  old_error = current_error;

  duty_cycle = progressive_term + integrative_term + derivative_term;
  motor_set_duty_cycle ((int) duty_cycle); // -1000 <-> 1000

[lizardmech]

I have my modified VESC ready to test but I need help with the software, I think it's not starting up due to the drv8302 not being their to give it's no fault signal.

[lizardmech]

I think I know why all the balancing vehicles run stm32f10xx MCUs. The ST MCUs come with a motor control firmware generator that has pictures you click on and it just needs a few values entered for it to spit out some code. TI instaspin has many examples but they're all just code in an IDE. Haven't got it running yet, was having touble setting a common ground so I had to order some voltage converters to run everything off the battery.

[electric_vehicle_lover]

I renamed the project to " EGG firmware - the first OpenSource firmware for electric unicycles"

EGG because my cheap generic EUC makes me remember an egg due to his form. Also I like eggs and is an "easy word".

Edited May 9, 2016 by electric_vehicle_lover

[lizardmech]

4 minutes ago, electric_vehicle_lover said:

I renamed the project to "EGG firmware - the 1st OpenSource firmware for Electric Unicycles"

EGG because my cheap generic EUC makes me remember an egg due to his form. Also I like eggs and is an "easy word".

You should try the ST motor control application, you can use it to test MPU and balancing software until the motor control is finished. You just input motor specs and which pins you are using and it spits out a source code with motor control, you can just add whatever functions you want on top of it.

[electric_vehicle_lover]

@lizardmech Current firmware controls the motor very well, it can change direction very fast and with torque. At the same time, it can rotate to high speed and with low noise and low current. The only missing piece on firmware right now is the PID control for balancing - and it seems to be working in part, but needs more work and tweaking.

Anyway, I may try the ST motor control application as that can be a source of knowledge :-)

[electric_vehicle_lover]

I woud like to share my experience:

I want to build my 30km/h EUC and so I bought the motor and controller from MicroWorks. I also were designing and 3D print a shell, since I don't have shell that works with this motor axle dimensions.

The problem: first time I connected the power to the board, I could connect with Milbay App and read there the board voltage, so the board were working. With the wheel on the air, I verified that it balanced (motor did run on both directions) until I accelerated and the motor some noise and stopped. Then the board didn't worked anymore. I tested again with other board and the same did happen, this time the shell brole with the vibrations/force of the motor and the board works although seems some mosfets are in short ciruit.

I were using using my lab power supply and the max current were setup to something like 1A or 2A - I guess the problem were that motor did run until that current and after the power supply quick drop/shutoff and that made the system to do something wrong and the mosfets did shortcircuit or something like that...

[Chriull]

27 minutes ago, electric_vehicle_lover said:

..

The problem: first time I connected the power to the board, I could connect with Milbay App and read there the board voltage, so the board were working. With the wheel on the air, I verified that it balanced (motor did run on both directions) until I accelerated and the motor some noise and stopped. Then the board didn't worked anymore. I tested again with other board and the same did happen, this time the shell brole with the vibrations/force of the motor and the board works although seems some mosfets are in short ciruit.

I were using using my lab power supply and the max current were setup to something like 1A or 2A - I guess the problem were that motor did run until that current and after the power supply quick drop/shutoff and that made the system to do something wrong and the mosfets did shortcircuit or something like that...

That does not sound like a "nice" brown out behaviour... ;(

Could easily be also a reason for faceplants with weak/aged/low capacity battery packs... Or also some burned motherboards while "heavy" breaking...

[electric_vehicle_lover]

More reasons to build our own firmware....

[Chriull]

An own firmware is just a part of the solution (if brown out detection is "implemented at the pcb)- the most important part would be a brown out safe H-Bridge/moset driver...

[Tilmann]

(Forgive me if this is not relevant as I didn't really follow this tread)

Jane just published a video on Instagram, which seems to show the tool used by GotWay to load the firmware to ACM16 boards:

 

[lizardmech]

I registered on a semiconductor manufacturers website for free samples and they actually sent me $200 worth of mosfets and IGBT modules for testing without even checking. I'm interested to see if using IGBT modules is feasible for EUC, you get the entire 3 phase half bridge and drivers all in one sealed IC.

[Tilmann]

27 minutes ago, lizardmech said:

I registered on a semiconductor manufacturers website for free samples and they actually sent me $200 worth of mosfets and IGBT modules for testing without even checking. I'm interested to see if using IGBT modules is feasible for EUC, you get the entire 3 phase half bridge and drivers all in one sealed IC.

Hmmm, now that sounds interesting! Are you suggesting, that modules like these could be a professional solution to our H-bridge problems? http://www.infineon.com/dgdl/Infineon-FP100R07N3E4-DS-v02_01-en_de.pdf?fileId=db3a3043324cae8c013262bbe5453970 (I just picked one with very limited knowledge. Here's the overview: http://www.infineon.com/cms/en/product/power/igbt/igbt-module/igbt-module-600v-650v/channel.html?channel=ff80808112ab681d0112ab69e70c0364).

I worked on an IT project in the factory, where those are made and could try to establish some contacts if this develops into a promising route . I do recall, that those modules required mounting on some impressive heat sinks though.

[esaj]

6 hours ago, lizardmech said:

I registered on a semiconductor manufacturers website for free samples and they actually sent me $200 worth of mosfets and IGBT modules for testing without even checking.

Wow, have to try that myself some day  Although the large manufacturers might not be so eager to send components all the way to here (for free). I always look at stuff like rail-to-rail opamps, but then don't buy them because "they're so expensive" (like a couple of euros a piece ). I did buckle a bit and got a few LMV358's (about 80-90 cents a piece, low voltage rail-to-rail dual opamp) and then felt bad when I didn't figure out any use for the second op-amp in a circuit and had to terminate it

6 hours ago, lizardmech said:

I'm interested to see if using IGBT modules is feasible for EUC, you get the entire 3 phase half bridge and drivers all in one sealed IC.

IGBTs are something totally new to me... I do know that they're some sort of "cross-breed" between BJTs and mosfets, but not much more than that. Interested to hear what you find out   I recall someone (hobby16 maybe?) mentioning in the past that the wheels should use IGBTs instead of mosfets...

5 hours ago, Tilmann said:

Hmmm, now that sounds interesting! Are you suggesting, that modules like these could be a professional solution to our H-bridge problems? http://www.infineon.com/dgdl/Infineon-FP100R07N3E4-DS-v02_01-en_de.pdf?fileId=db3a3043324cae8c013262bbe5453970 (I just picked one with very limited knowledge. Here's the overview: http://www.infineon.com/cms/en/product/power/igbt/igbt-module/igbt-module-600v-650v/channel.html?channel=ff80808112ab681d0112ab69e70c0364).

I worked on an IT project in the factory, where those are made and could try to establish some contacts if this develops into a promising route . I do recall, that those modules required mounting on some impressive heat sinks though.

Like I said above, I know next to nothing about IGBTs, but if those are specifically meant to drive motors, one could easily imagine them being used in EUCs... Don't know what's stopping it currently (size? weight? price? something about the IGBTs themselves that makes them unsuitable?). From the little that I peeked at the datasheets, it seems they have a gate (like mosfets), but the conducting path is marked as collector and emitter (like in BJTs). Much larger gate charges than usual power-mosfets (something like from a few tens up to few hundred nCs in mosfets, 0.75 µC = 750nC in those IGBT-bridges), but guess it just needs that much more current to switch on and off rapidly? Maybe a high current mosfet-driver could also drive those? Also, looking at the voltage/current graphs, might need quite large heatsinks (maybe), as there's always something like at least 0.5V voltage drop over the collector and emitter + conducting losses + switching losses? Really out of my league though

[Tilmann]

4 hours ago, esaj said:

Wow, have to try that myself some day  Although the large manufacturers might not be so eager to send components all the way to here (for free). I always look at stuff like rail-to-rail opamps, but then don't buy them because "they're so expensive" (like a couple of euros a piece ). I did buckle a bit and got a few LMV358's (about 80-90 cents a piece, low voltage rail-to-rail dual opamp) and then felt bad when I didn't figure out any use for the second op-amp in a circuit and had to terminate it

IGBTs are something totally new to me... I do know that they're some sort of "cross-breed" between BJTs and mosfets, but not much more than that. Interested to hear what you find out   I recall someone (hobby16 maybe?) mentioning in the past that the wheels should use IGBTs instead of mosfets...

Like I said above, I know next to nothing about IGBTs, but if those are specifically meant to drive motors, one could easily imagine them being used in EUCs... Don't know what's stopping it currently (size? weight? price? something about the IGBTs themselves that makes them unsuitable?). From the little that I peeked at the datasheets, it seems they have a gate (like mosfets), but the conducting path is marked as collector and emitter (like in BJTs). Much larger gate charges than usual power-mosfets (something like from a few tens up to few hundred nCs in mosfets, 0.75 µC = 750nC in those IGBT-bridges), but guess it just needs that much more current to switch on and off rapidly? Maybe a high current mosfet-driver could also drive those? Also, looking at the voltage/current graphs, might need quite large heatsinks (maybe), as there's always something like at least 0.5V voltage drop over the collector and emitter + conducting losses + switching losses? Really out of my league though

"Really out of my league" applies to me even more so. What I can tell: some IGBT modules are specifically designed to drive motors! The applications range from industrial servo motor controllers to hybrid automotive cars to high speed trains. Other typical applications are wind mills, where the generated power needs to be transformed before it can be fed into the power grid. 

The module I referenced, physically looks like the type used for hybrid cars (I am too damned ignorant to tell by the electrical characteristics). Physical dimensions are about 12cm x 6cm x 2cm, guestimated weight max. 200 grams. The heaviest part is the copper base plate, which is optimized for thermal flow to the heat sink. As those modules are meant for automotive applications, we are looking at motors upwards of 20kW.  Here are some typical development kits for those babies: http://www.ehitex.de/application-kits/infineon/2341/hybridkit1 (too big for e-wheels) and http://www.ehitex.de/application-kits/infineon/2539/aurix-motor-control-application-kit-with-tft-display (too small). Observation 1: only the small kit lists "Hall Sensors" for motor position, the big one doesn't. Observation 2: we are in a price range here, which blows amateur budgets .

Nevertheless, there are some very good reasons to explore that route: a correctly sized IGBT solution should cost only a fraction of the prices for the evaluation kits. It should lower overall production cost of our wheels due to higher integration and - most important - I have seen the enormous efforts going into quality control with the production of such modules (and helped with some IT projects to implement them). When those modules fail, its subject to the 8 o'clock evening news and ruins the image of top automotive brands. So, they are designed not to! As we are trusting our bones to our wheels, that's the standard to go for. Example: inside the IGBT modules, the components are soldered to coated ceramic tiles and to the copper base plate. To ensure proper thermal flow, the solder needs to cover the full contact area, no air bubbles are allowed. For automotive or high power applications, every single module is x-rayed! With the slightest sign of irregularity, it goes to the garbage can.  I have seen truck loads of modules going to trash. Somehow I don't have that level of confidence with the montage of discrete components and generous supply of hot glue in our wheels today .

So, if somebody here really knows this IGBT stuff, please contact me. I can't promise much, but I'll sure try to utilize my contacts into that industry (applies only to infineon, sorry).

[lizardmech]

I have been reading about IGBTs, while MOSFETs are typically favoured for high switching speeds and lower voltages it's not such a clear choice for motor control. Motor control is usually only around 5-20khz which IGBTs can do. IGBTs are more difficult to drive and have higher losses when conducting which gives the impression they are inferior, however there is one big difference, MOSFET switching losses greatly increase as size of the MOSFET increases either through larger fets or parallel fets. Apparently when adding more or larger MOSFETs you reach a point where switching losses are producing more heat than you saved by reducing RDs on resistance.

This limitation could be why you see lower switching speeds on powerful models like KS. If they are limited by switching losses adding additional fets won't do anything.

[electric_vehicle_lover]

And the motor and board works. Next I want to measure the motor speed to see if this motor really runs at 30km/h. Later I want to run it with my firmware and see if it runs with the same velocity.

First try: 

And the first riding: 

 

Soon I will document and share the all project.

[lizardmech]

Can you ride on your firmware now? Or just run the motor?

[electric_vehicle_lover]

@lizardmech the current state of the firmware, you can see on the video. I just paused the development to focus on building an EUC for me to ride, since my girlfriend is almost riding, I also want an EUC for me so we can both take advantage of next months of sun e beach :-)

Now I would like to build 2 EUCS of 30km/h for me and for my girlfriend and use the cheap generic for young son. Than I will be back to focus on the firmware.

Maybe I will want to have the firmware for this gen2 boards and 30km/h motor. Also I will also want to have RGB LED strip and strong lights... so I have a lot to do for the 3D design.....