Firmware

[electric_vehicle_lover]

The IMU MPU6050 angle read is now fast, at every 2ms. Before it was 15.6ms!!
I implemented DMA read of I2C MPU6050 and increased the I2C speed to the max of 400kHz.

The balance now reacts fast, in some parts seems near the commercial EUCs but is not there yet. Video:

And now a screenshot showing the value of key variables, sent by bluetooth to PC.:

- angle_error: this value should be zero when the EUC is in vertical. This value is the input for the balance controller algorithm, when increases to positive values the motor should rotate in "positive" direction. The inverse for negative values of angle_error.

- duty_cycle: this value is the output of the balance controller and the input to the duty_cycle motor controller. Duty cycle should be zero when the EUC is on vertical --> angle_error = 0.

- motor speed: is positive and negative, for clear indication of motor rotation direction. Motor speed is measured be reading the hall sensors period signal.

Balance controller algorithm should run fast and is running now at 2ms (500 times every second). The max theorical speed is 1000 times a second, imposed by the IMU MPU6050.

The next screenshot shows shows at left when I moved the EUC to one side and it balances. At the middle it shows oscillation as when I move it to fast, etc, as seen on the video:

 

Edited April 18, 2017 by electric_vehicle_lover

[Tomek]

nice progress. are you running it already at full current & voltage? if so, probably introducing a PID loop would be the logical next step to get the balancing to work properly, wihtout the oscillations you get.

[electric_vehicle_lover]

Hi @Tomek.

Not at full voltage and I just found the code I thought was working correctly for motor running on both directions, is not. At low voltage from 23V up to about 30V is ok but after that, in one direction, it goes wrong :-(

So now I have 2 main issues:
1. control motor code for medium/high velocity is not ready yet
2. balance controller is not working and I don't know a possible algorithm... (current motor control code is ok for testing/develop balance algorithm). The latest video have PID on balance controller... and I tested many values and with/without D term.
I am not sure PID is the correct algorithm for a balance controller... I found a good discussion here: http://www.plctalk.net/qanda/showthread.php?t=103066

Now I understand why EUCs keep increasing speed at a constant error angle, to have and increasing speed and so have acceleration because Force = m*a; Force is the force to needed to push the rider to vertical.

"The first thing you need to understand and account for is, even in the small signal sense, this is a non-linear system. A given set of PID tuning values will only be valid for a very small range of angles. So you either have to scale your PID output based on the angle of the bike or you will have to perform what is referred to as gain scheduling, which means to change the PID gains as the bike angle changes. Ideally I think gain scheduling may be the better plan. However, that will require you to make up a mathematical model of your system so you have something to calculate the gains from."

"I agree that PD is typical in controlling such "servo" systems with much inertia. Integral action is more useful for long-term trim in process control like chemical plants. But, I doubt basic feedback control will be sufficient for your process, which is trying to make an unstable system stable via active control.

You most likely will also need "anticipatory" action, termed "feed-forward" or "open-loop control". These are algebraic equations that look at disturbance variables to the system and apply control output before a set-point error is realized. If you add the proper dynamics (lead/lag), they are differential equations. Feedback control is like trying to keep a car in its lane by looking straight down at a lane line, whereas feed-forward would be looking ahead, seeing the lane curve and start turning the wheel a little early. Another example, think of Space X trying to land a tall, skinny booster on a barge in heaving seas. Feed-forward inputs might be approaching waves, tilting rate of the platform, approaching air gusts, ... Even if you have only the controlled variable as an input, there are additions to PID that act similarly. Look at Delta Computer's RMC motion controllers, which have enhanced derivative terms."

For the control motor code for medium/high velocity, I am being looking and thinking about the motor poles and the magnets... I am not sure the wave should perfectly sinusoidal... I want now to look for a PC oscilloscope that permit to register like continuous 10 seconds, were I can rotate the motor by hand and see the generated BEMF voltage - should be the same I need to generate with the firmware.
I am looking to OpenSource software like Sigrok and cheap PC oscilloscopes from china and that works on Linux.

[lizardmech]

Ultimately you're probably going to need a sensorless observer for high rpm. That's why I suggested basing it off the unconventional FOC Colton used without clarke and park transformations would lead to issues. He ended up using it for camera gimbals which only run at less than 60rpm where running many motors was more important than sensorless operation at high RPM.

[electric_vehicle_lover]

I am almost sure the issue is for now on the way I drive the motor - and I need to do it correctly, with or without rotor  angle correction that is given by the FOC.

I think the issue is about the number of magnets vs number of coils, that don't give a correct number of 360 degrees for each electric rotation. Here a technical review with details about a bicycle motor with the same number of magnets and coils:

Hihttps://www.electricbike.com/9c/

Running with hall sensors should be no problem for all speeds, as the FOC algorithm will detect the correct angle correction value and apply it continually. I don't think sensorless algorithm is a must have to get the correct angle, as even with an incorrect angle with increase speed, given by hall sensors, the algorithm find the correct angle by looking at Id current that must be zero, other values means the angle should be corrected with proportion. And this works well with my current code.

 

Edited April 22, 2017 by electric_vehicle_lover

[lizardmech]

It's difficult to troubleshoot hall based FOC because it doesn't seem to be used anywhere else. All the hall based examples I can find are BLDC type, while the FOC are typically encoder or sensorless. I think hall sensor FOC controllers are just sensorless controllers that only use the halls to assist at startup. It's possible there's a reason few FOC controllers operating only using hall sensors exist. Assuming it's theoretically possible for it to work all I can think of is the delay from the hall sensor possibly combined with deadtime being inserted by the gate driver causes issues.

[electric_vehicle_lover]

Well, balance EUC using brushless motor seems a unique application. That's why most examples we can find are different, like there is a lot for bicycles that most of don't do regen or not quick directions change like needed for EUC. EUC have specific needs. I want to have knowledge to understand the unique application of EUC.

[electric_vehicle_lover]

There is something with motor control... I found more people referring about the EBike controllers switching between 2 modes, at low/medium and high speed:

WhatcomRider wrote:The sine-wave controller is rated at 10-20 amps and is running in sensored mode. It is able to hold a steady speed as low as 3 rpm and smoothly ramps up to no-load speed. It is interesting that there is an audible change at around 130 rpm where it seems that the commutation shifts into a different mode.

I even documented this before, but from a EUC cheap board that doesn't FOC:

Pictures of electrical signals

Seems there are 2 different ways to control the motor - one for low speed up to medium speed and other for higher speed. The 1st way seems specific to this application were a motor may work at very low speeds and even stopped. The 2nd way seems to be the standard 6 steps trapezoidal control.

1st way, low to medium speed: yellow: phase 1, blue: hall sensor signal.

2nd way, high speed: yellow: phase 1, blue: hall sensor signal.

On the 1st way, when the wheel is stopped, there is a square (duty-cycle is 50%) on all the 3 phases (the signals are in phase) and the frequency is 15.625khz.

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

A bit out off topic:

I decided to look again to EBike controllers and decided to look for a cheap wide available controller that I could program the firmware. Seems EBike controllers (the cheap ones that most people use) aren't doing FOC.

After many searching, I found the cheap widely available from a chinese well known shop that exist since 8 or more years, that sells a recent controller that uses STM8S105C6T6 -- this microcontroller is also from ST and can be programmed with the same cheap ST LinkV2 cable that I am using with MicroWorks 30B4 board. Also for this STM8S105C6T6, there are OpenSource firmware and libs, to program on Linux <3
STM8S105C6T6 is much more limited than STM32F103 of 30B4 board:

(STM8S105C6T6) 16 MHz STM8S 8-bit MCU 32 kbytes flash VERSUS (STM32F103C8T8) 72 MHz ARM 32 bits 128Kbytes flash memory!!!

[Carlos E Rodriguez]

On 4/18/2017 at 7:51 AM, electric_vehicle_lover said:

The IMU MPU6050 angle read is now fast, at every 2ms. Before it was 15.6ms!!
I implemented DMA read of I2C MPU6050 and increased the I2C speed to the max of 400kHz.

The balance now reacts fast, in some parts seems near the commercial EUCs but is not there yet. Video:

And now a screenshot showing the value of key variables, sent by bluetooth to PC.:

- angle_error: this value should be zero when the EUC is in vertical. This value is the input for the balance controller algorithm, when increases to positive values the motor should rotate in "positive" direction. The inverse for negative values of angle_error.

- duty_cycle: this value is the output of the balance controller and the input to the duty_cycle motor controller. Duty cycle should be zero when the EUC is on vertical --> angle_error = 0.

- motor speed: is positive and negative, for clear indication of motor rotation direction. Motor speed is measured be reading the hall sensors period signal.

Balance controller algorithm should run fast and is running now at 2ms (500 times every second). The max theorical speed is 1000 times a second, imposed by the IMU MPU6050.

The next screenshot shows shows at left when I moved the EUC to one side and it balances. At the middle it shows oscillation as when I move it to fast, etc, as seen on the video:

 

@electric_vehicle_lover  Maybe this guy will share his code

 

[lizardmech]

4 hours ago, electric_vehicle_lover said:

 

A bit out off topic:

I decided to look again to EBike controllers and decided to look for a cheap wide available controller that I could program the firmware. Seems EBike controllers (the cheap ones that most people use) aren't doing FOC.

After many searching, I found the cheap widely available from a chinese well known shop that exist since 8 or more years, that sells a recent controller that uses STM8S105C6T6 -- this microcontroller is also from ST and can be programmed with the same cheap ST LinkV2 cable that I am using with MicroWorks 30B4 board. Also for this STM8S105C6T6, there are OpenSource firmware and libs, to program on Linux <3
STM8S105C6T6 is much more limited than STM32F103 of 30B4 board:

(STM8S105C6T6) 16 MHz STM8S 8-bit MCU 32 kbytes flash VERSUS (STM32F103C8T8) 72 MHz ARM 32 bits 128Kbytes flash memory!!!

If you're willing to try another MCU get one of these. mouser.com/ProductDetail/Texas-Instruments/LAUNCHXL-F28377S/ It has the best open source FOC code I have seen, its all under BSD or apache. Ti staff are very helpful as well, they will likely provide engineering assistance if we show them the idea of building an open EUC platform. At a minimum they usually will answer any questions on their forum within 24hr.

[electric_vehicle_lover]

1 hour ago, lizardmech said:

If you're willing to try another MCU get one of these. mouser.com/ProductDetail/Texas-Instruments/LAUNCHXL-F28377S/ It has the best open source FOC code I have seen, its all under BSD or apache. Ti staff are very helpful as well, they will likely provide engineering assistance if we show them the idea of building an open EUC platform. At a minimum they usually will answer any questions on their forum within 24hr.

I mean I have 2 different projects: develop firmware for EUCs and for EBikes, each one on a specific controller.

I found many EBike controllers with microcontrollers very limited, without documentation, dedicated for automobile industry - probably the developers program them in assembly.

I had luck to find one cheap and that is sold by the most famous Chinese website (BMSBattery) and with an STM microcontroller with a good documentation - but maybe 100x less available documentation than the STM32F103 from MicroWorks 30B4 board.

[lizardmech]

I don't understand the point. Those chinese ebike controllers are garbage, there's nothing you can learn from them. If you would work on anything with a modern MCU it would only take a short amount of time to code because you wouldn't be trying to come up with hacks to work around an ancient MCU being too slow. It's not like it's expensive to develop on a proper platform with fully documented software and hardware. 3 phase FOC capable add on board is $49 for that Ti c2000 dev board mouser.com/ProductDetail/Texas-Instruments/BOOSTXL-DRV8301 . That's only $80 USD for the devboard + motor driver, the chinese controllers probably won't even be cheaper after you pay for shipping.

Edited April 27, 2017 by lizardmech

[electric_vehicle_lover]

I found a bug on the firmware for the motor control, now the motor runs well on both directions. I tested with 3 different motors I have. I put the firmware running on the MicroWorks 30km/h motor. I measured the hall sensors signal and at 62V the motor did run at ~29km/h. At the battery max voltage, should be near the 32.7km/h I did measured with original firmware:

 

Edited May 2, 2017 by electric_vehicle_lover

[Tomek]

On 5/2/2017 at 7:19 PM, electric_vehicle_lover said:

I found a bug on the firmware for the motor control, now the motor runs well on both directions. I tested with 3 different motors I have. I put the firmware running on the MicroWorks 30km/h motor. I measured the hall sensors signal and at 62V the motor did run at ~29km/h. At the battery max voltage, should be near the 32.7km/h I did measured with original firmware:

on the video it seems to work perfectly... is it running at full torque as well?

[electric_vehicle_lover]

50 minutes ago, Tomek said:

on the video it seems to work perfectly... is it running at full torque as well?

The MicroWorks 500W 30km/h motor runs at 30km/h while the others I have run at about 22 or 24km/h. They also do a lot noise and vibrations, MicroWorks motor seems much better!!

It is not running at full torque, because that would mean at max current. It is running without load and so running at lowest current. And yes, at max efficiency. The power supply says 0.4A and 62V, motor running at max speed.

The motor code seems ok for now. It is good to start implementing the balance controller algorithm, that I tried just before and I could not make it working. If anyone have ideas for an algorithm.......

But I want to look better at the motor code, there is always a small noise at specific lower speed and now I think it may be something with my code. Anyway, it is not important for now. The balance algorithm should be the next task....

[Tomek]

On 5/3/2017 at 11:51 PM, electric_vehicle_lover said:

The balance algorithm should be the next task....

did you see this project?

https://github.com/spin7ion/Wheelee

http://spin7ion.ru/ru/blog/balancerBuildSteps

looks like a decent starting point with ready to use code

edit: it uses LQR instead of PID, which seems to be the way to go

Edited May 4, 2017 by Tomek

[electric_vehicle_lover]

Thanks!! If you can find something in EN, would be great.
On next days I will keep focus on the motor code, turns out that I have some bug on the angle interpolation and the code is working without it and finally I could see that the strange noise at a specific low speed was due to the bug. It is really hard to debug the motor code, as it runs fast (can't send variables over bluetooth) and I simple can't stop with the debug when the motor rotates at medium and high speed -- the motor/mosfets stays at short circuit on that condition. The STM32F103C6T8 don't have a DAC, with a DAC I could output some values and see with oscilloscope the voltage output... it is much harder to use only digital pins to try figure out how the code behaves.

[Tomek]

6 hours ago, electric_vehicle_lover said:

Thanks!! If you can find something in EN, would be great.

I don't speak russian either, but google translate does a good job

if you don't use chrome: https://translate.google.com/translate?hl=en&sl=ru&tl=en&u=http%3A%2F%2Fspin7ion.ru%2Fru%2Fblog%2FbalancerBuildSteps

[electric_vehicle_lover]

Thanks. After looking at google on the LQR, I found very good documents in EN. Thanks.

[electric_vehicle_lover]

FINALLY I found the bug on my code!! The angle interpolation was wrong... I had to try simulate some code and the hall sensors signal on the board, use bluetooth to get the data, etc, etc, took me a lot of time but I got it :-)

Here a screenshot of the wrong values at left side and just after at right side after being correct: motor_rotor_position going from 259º up to 0º, in loop:

Then I got the motor working the best until now and I really think is very robust!!!

On the next image, I accelerated a few time the motor, very fast, in both directions. Id is controlled to be 0 by FOC and it is, just one fast accelerations it is not but we can see the "correction_value" that is the output of the FOC controller that follows fast on the accelerations. Also we can see values of Iq current of max ~-+5 Amps (current firmware code do not limit the max current).

Motor speed also indicates the direction of the rotation. Positive in one and negative in the other. The duty_cycle is the value that I control with the potentiometer.

Now see the video I recorded on a similar test. Can you see how fast is the acceleration and changing rotation direction?
The power supply is suppling 62V, can you see when I decelerate fast that the power supply shows a max of about 90V?? -- that's the regen voltage, the energy that should flow to battery when we brake!!
And the motor asks for about 0.6 amps at max speed without any load, but when I tired to block with my hand, at some duty_cycle value, the motor asked for about 2.8 amps!!

The motor did run at max speed of 24km/h (voltage power supply = 62.2V). For a battery pack of 60V, 16S = 16*4.2 = 67.2V, motor should run at max speed of 26km/h.

Next, move to the balance controller algorithm!!

 

Edited May 5, 2017 by electric_vehicle_lover

[electric_vehicle_lover]

The firmware was feature yesterday on the popular news site HACKADAY: http://hackaday.com/2017/05/07/open-sou ... verboards/

 

Edited May 8, 2017 by electric_vehicle_lover

[electric_vehicle_lover]

So I found I could export the CherryTree notes file to HTML and put on Github pages. The idea is that google will index all this information and will be easy for anyone to read that. Being a XML file on github means that anyone will also be able to fork and contribute with a pull requests - XML file is ok for follow git diffs.
Turns out the the source file have now 220 MBytes and github have a limitation of 100MBytes per each file. Than I moved to BitBucket to avoid this limitation. I will keep the firmware on github and the documentation on bitbucket. I will probably delete the wiki and move all the information to the notes file / HTML page.

Here is the link for the documentation: http://eggelectricunicycle.bitbucket.io/

 

Edited May 8, 2017 by electric_vehicle_lover

[electric_vehicle_lover]

So now that motor is working very well, my focus is now on the balance controller.

Today I did put working scanf() to receive strings and variable values over bluetooth. I started with the PID for the balance controller and sending in real-time the P I D coefficients and see if I could get the balance -- and I could not... I don't think PID is the controller.
I went back to the algorithm that keep increasing the speed at a constant error angle -- to keep a constant Force to move the ride to vertical I need a constant acceleration --> F = m * a. This seems to work but not for balance when the error angle is near zero.... I also tried to change in real-time the coefficients for this algorithm.

The code for the balance controller I tested is here: https://github.com/EGG-electric-unicycle/firmware-gen2_boards/blob/modifiedFOC-motorMicroWorks30kmh/balance_controller.c

Can someone help on the algorithm??

[Hunka Hunka Burning Love]

Not sure if this might help as it is for a different processor, but here's some C source code from an MIT guy who made his own wheel...

https://gist.github.com/stepchowfun/2475495

https://www.stephanboyer.com/post/17/my-electric-unicycle

Other guy referenced:

http://tlb.org/#eunicycle

http://www.instructables.com/id/Self-Balancing-Unicycle/

Edited May 12, 2017 by Hunka Hunka Burning Love

[lizardmech]

How is sensor fusion being done? I didn't see a kalman filter.