Firmware

[Tomek]

@electric_vehicle_lover could it be that at high speeds you need to entirely rely on bemf measurements instead of hall sensors? on the other hand at low speeds bemf would probably be less accurate, so hall sensors seem like a better choice then.

[electric_vehicle_lover]

I don't think that is the questionar here. Both hall and BEMF seems to work at medium speed. The way I drive the motor seems to work well at low speed but at medium speed the motor vibrates and make a lot of noise :-( 

The original firmware drive the motor at low and medium at a very different way and it works very well. I can't understand how it works and I already searched a lot on Google and there is no reference to such way of driving... :-(

[vezu4iy]

  

I recently had a similar problem . Because of the moisture in one of the voltage sensors subsided and at high speed it is vibrated , the controller did not notice the part of the pulse .

[vezu4iy]

 

 

[electric_vehicle_lover]

I got more time to see the signals and now they seem to make sense for me. I documented on the wiki: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers

I also had some shutdowns from the BMS and I decided to document on the wiki: https://github.com/generic-electric-unicycle/documentation/wiki/Battery

Here is the copy of wiki that I wrote:

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.

Yellow: phase 1, blue: phase 2. Motor stopped:

When the motor rotates, one phase keeps the duty-cycle at 50% and the other 2 phases have duty-cycle higher and lower than 50%. That 2 phases have inverted duty-cycle value, like if one have 25% duty-cycle, the other have 75%. The PWM signals seems to be center aligned. This signals seems to change, maybe using 6 steps by following the hall sensors signals.

Yellow: phase 1 signal with 10% duty-cycle, blue: phase 2 with 50% duty-cycle.

Yellow: phase 1 signal with 10% duty-cycle, blue: phase 2 with 90% duty-cycle.

Yellow: phase 1 signal with 25% duty-cycle, blue: phase 2 with 75% duty-cycle.

[lizardmech]

I managed to talk to someone who claimed they have worked on hoverboard software. They said the balance aspect consists of 4 PID loops, only the angle and rate of angle change as detected by the gyro were used. They also said none of them write their own motor control code, they all rely on a ST reference design which offers torque based control via current. Apparently it's quite complicated and different to what you will find in RC and drone 3 phase BLDC motor controllers.

[robca]

Probably this one: http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1734/PF257936?icmp=tt2849_gl_pron_sep2015&sc=stsw-stm32100-pr1  (There's also a physical eval board available, with processor and drivers)

[lizardmech]

1 hour ago, robca said:

Probably this one: http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1734/PF257936?icmp=tt2849_gl_pron_sep2015&sc=stsw-stm32100-pr1  (There's also a physical eval board available, with processor and drivers)

What's the license on the ST one? TI seemed to use creative commons for their motor control but I can't find it on the ST one.

[lizardmech]

I think I found the license in the installer, seems to be a strange custom one.

From what I can tell, as long as you use an opensource license you can reuse and redistribute the code, however it must only run on ST microprocessors. If you use a non opensource license only binary files may be distributed.

http://www.st.com/web/en/resource/legal/legal_agreement/license_agreement/ultimate-liberty-v2.txt?sc=software_license_agreement_liberty_v2

[electric_vehicle_lover]

Well, after many hours I were able to put the motor working as on 1st way (like original controller from low to medium speed: https://github.com/generic-electric-unicycle/documentation/wiki/Controllers)

I think I will gather more information from the original controller: hall sensors signal frequency/wheel speed when the controller changes from 1st to 2nd way. anyway, I don't think we need high speed for now.

Then I would like to start feeding the IMU signal to motor........

@jayjay23 any news of the IMU code??

[jayjay23]

@electric_vehicle_lover: Hi follow all your progress and that's really cool, actually I needed to clean up my workplace during christmas and have restored it only partially for soldering some stuff for our house which I'm currently still busy with. So sorry for my current break, but I need to solder some more items.

The latest state regarding IMU is unfortunately that there seems to be a instability when using float, the code seems to run a bit, but then stops and I could not figure out before christmas what it was. I'm also unsure about how to deal with the timing issues and debugging, my current debugging facilities are a bit limited with the aspect of real time, all debugging with the SWD slows stuff down and so can have any kind of side effect. So I already had the idea of using all the leds for showing various states of the code to not have something interrupting the real time behavior. If there are any other ideas I would appreciate it. I'm a bit far away from such a solution, but a serial transmission would also already help a lot as it does not involve break point handling (as all my current methods via SWD).

If there are any other ideas for this they are very welcome.

[electric_vehicle_lover]

Right now I am also trying to make float working (it is not working for me even with you makefile). I will keep working to make floats working.

Regarding serial port for debug and be able to develop this firmware, maybe we could jump to the boards with better hardware for motor control and Bluetooth... But on other side, if this cheap boards work, that means the system is also simple and small... And can be an advantage for not being an overwhelming project.

Next I plan to develop accel/decel code and keep using the pot to simulate a throttle. We also need to deal with current management and regen management/bettery max charging.

[vezu4iy]

Amazing

[electric_vehicle_lover]

Ok got floats working :-)

My flags on my makefile:

AFLAGS  = -Igeneric-electric-unicycle/firmware/src -Igeneric-electric-unicycle/firmware/src/spl/CMSIS -Igeneric-electric-unicycle/firmware/src/spl/inc -c -g -mcpu=cortex-m3 -mthumb
CFLAGS  = -Igeneric-electric-unicycle/firmware/src -Igeneric-electric-unicycle/firmware/src/spl/CMSIS -Igeneric-electric-unicycle/firmware/src/spl/CMSIS/inc -Igeneric-electric-unicycle/firmware/src/spl/inc -DSTM32F10X_MD -DUSE_STDPERIPH_DRIVER -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb
LFLAGS  = -Tgeneric-electric-unicycle/firmware/src/stm32_flash.ld -L/usr/lib/gcc/arm-none-eabi/4.9.3/armv7-m -lgcc -nostartfiles

The needed change is to point for armv7-m folder, which is the arm version of Cortex-M3 we are using (and not to thumb folder, that didn't worked for me @jayjay23).

[Berus]

@jayjay23

I don't know if openwheel was already mentioned here , but if no ..maybe that the code of openwheel (IMU section) could be usefull

https://www.wevolver.com/wevolver.staff/open-wheels/inertial-module/description/

[electric_vehicle_lover]

Happy to have the motor rotating to left/right and stop :-)
I coded a ramp increase/decrease of duty cycle. The input value comes from a potentiometer that is connected to PS_SIGNAL on the board. At middle of potentiometer the motor is stopped. Rotating to left it will increase the PWM duty cycle and rotate the motor left. Rotating to right, increase pwm duty cycle and rotate motor to right -- please see the video!!

The code is here: https://github.com/generic-electric-unicycle/firmware/commit/6481d09e4d7890b3f74437d706d6982e91d58689

Control the motor with:

motor_set_duty_cycle (int value)

"value" should be between -999 and 1000. -999 max speed rotating left; 0 motor stopped and 1000 rotating right at max speed.

 

[Tomek]

@electric_vehicle_lover awesome progress! found an interesting article that can help with understanding pwm control: http://www.embedded.com/design/mcus-processors-and-socs/4006777/Implementing-Embedded-Speed-Control-for-Brushless-DC-Motors-Part-2

[electric_vehicle_lover]

I updated the PWM/motor control code to be more inline with what is recommended on the STM32F103 datasheet. Before there were some random vibrations/shakes on the motor but now it is better.

I also found why the ADC interrupt for MAX current management is not working and I may work on it next. On actual code the motor uses to much current after "medium" speed and this is a good opportunity to develop and test the current control.

Next, maybe I will skip the battery overcharge with the brake/regen and move straight to get the IMU signal and control the motor speed with that input instead of the current potentiometer I am using.

Edited January 17, 2016 by electric_vehicle_lover

[lizardmech]

Can you implement current control rather than speed based duty cycle mode?

This video explains the difference quite well, torque mode is shown around 30 min. It also shows why EUCs spin their wheel when you lift them off the ground. They essentially have no control over rotation speed and just increase current/torque based on gyro data.

 

 

 

[jayjay23]

On 1/13/2016 at 5:28 PM, Berus said:

I don't know if openwheel was already mentioned here , but if no ..maybe that the code of openwheel (IMU section) could be usefull

I read through that and it's a good explanation of what has to be done, I didn't digged into any code as the stuff needed is already at our hands and I would say to look at something new only if it just doesn't work in general.

 

On 1/12/2016 at 9:25 AM, electric_vehicle_lover said:

The needed change is to point for armv7-m folder, which is the arm version of Cortex-M3 we are using

ok!! That's really great news as I took the thumbs version after reading some pages for exactly our chip that it should only work with that, so I was not focused on trying another variant or reading about it. As soon as my situation stabilized a bit more I will check if that did the thing.

[electric_vehicle_lover]

13 hours ago, lizardmech said:

Can you implement current control rather than speed based duty cycle mode?

This video explains the difference quite well, torque mode is shown around 30 min. It also shows why EUCs spin their wheel when you lift them off the ground. They essentially have no control over rotation speed and just increase current/torque based on gyro data.

@lizardmech, I didn't had time to see the full video.

On this cheap Generic EUCs, their boards seem to have a circuit very cheap and without ADC signal voltage resolution to read under like 2 amps and I think it just maybe possible to limit to max current - this motors of 350W should use about 6 amps. I would say that I need to code to disable the duty-cycle when the current is over 6 amps and turn it back on when the current is like 5 amps. This way, I already implemented in the past and works - the motor just stops doing more force/torque at the 6 amps but keeps the torque constant.

Idon't think is possible to implement variable current control on this boards (but fixed current control of 6 amps). The other boards for 30km/h and Bluetooth have specific ics to measure current at each phase and I believe that can be done on them.

This cheap boards have control over the speed, for instance, they change the motor control method when it runs from medium to high speed. Speed is measured on the hall sensors signals - very easy to do and is already implemented on our current code (at hall sensors interrupt code).

@lizardmech but you are correct - without fine current measurement, there is now way to understand if the motor is running doing to low or much force/torque - the case on when wheel spin a lot when lift from the ground.
I also did read something like we can calc the power like the battery voltage and duty-cycle instead of using the current value. I don't know if that could apply to EUCs...

Edited January 18, 2016 by electric_vehicle_lover

[lizardmech]

Isn't that two separate issues though? Using hall sensors for commutation becomes ineffective above certain RPM.

Direct torque control is a special control loop for controlling 3 phase motors, it's quite recent and involves a lot of complex math, I don't think many of the EUC companies could make changes to it and just rely on the ST reference software. So it's difficult to imagine them swapping control loops at different speeds.

It looks like direct torque control for BLDC became mainstream around 2010 or 2011, probably explains the sudden appearance of so many self balancing vehicles around then.

 

 It looks like there is a large difference in latency between DTC and older methods, if the others take 500ms to respond it's unlikely they are being used, you would crash before the unicycle could respond to bumps.

[electric_vehicle_lover]

I measured the wheel perimeter and also think I know the value for time that 1 rotation take, related to hall sensor signals timing. Wrote that on the wiki: https://github.com/generic-electric-unicycle/documentation/wiki/Motor

The wheel have a 14 inch diameter tire. The perimeter of the wheel is ~1.12 meters (measured with inflated tire and without anyone on top of the EUC).

The generic EUC motor have 51 coils and 46 magnets. It also have 3 hall sensors. For each full rotation, each hall sensor signal will have a transition state of 21.8ms (1s/46 = 0.02174).

@lizardmech, I must say that I feel I am behind your knowledge of BLDC motor control.

Edited January 19, 2016 by electric_vehicle_lover

[vezu4iy]

Its about 4km/h, the middle speed is about 12km/h

Edited January 20, 2016 by vezu4iy

[electric_vehicle_lover]

@vezu4iy I don't understand what you mean by its about 4km/h.