Top speed / BLDC Control optimization

[lalalandrus]

Is it possible to include the field weakening code from https://github.com/larsmm/hoverboard-firmware-hack-bbcar to increase the top speed of the hoverboard.

Because this projects re-integrates the sensors, it can be used in conjunction with the hoverboard carts and achieve a high top speed.

[btsimonh]

looks like weakl and weakr are already there; we'd just need the code to set them....
Then I guess you could use a sensor angle as an accelerator pedal!
Testing would be an issue; the three of us are 'low speed' applications. With a suitable build, it could be 'road tested' unmanned and wifi controlled, but would exceed the speed limit on my road :).
PRs welcome.

[p-h-a-i-l]

Pull requests are very welcome 😋

…

Am 11.05.2019 um 10:46 schrieb btsimonh ***@***.***>: looks like weakl and weakr are already there; we'd just need the code to set them.... Then I guess you could use a sensor angle as an accelerator pedal! Testing would be an issue; the three of us are 'low speed' applications. With a suitable build, it could be 'road tested' unmanned and wifi controlled, but would exceed the speed limit on my road :). PRs welcome. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[lalalandrus]

What if I told you I can help convert all your wheels into 10inch. I can write a tutorial and you can do balance at high speed :)

[lalalandrus]

What if I told you I can help convert all your wheels into 10inch. I can write a tutorial and you can do balance at high speed :)
https://imgur.com/a/8RkTix0

[btsimonh]

haha! I did think about if we could put something around the wheels - or fit 'snow chains' for operation on grass :).

[lalalandrus]

This widens the base and the stability increases substantially

[btsimonh]

I can see why you want to go faster that your standard hoverboard; with standard hoverboard control :). May need to upgrade the way the wheels are attached, and check the bearings occasionally. But also I guess that your weight is not necessarily directly over the wheels, so the bearings may be under a slightly lighter load.

[lalalandrus]

I tried compiling it through platformIO and programming firmware.bin but the board is now unresponsive. Is there anything special I need to do?

[btsimonh]

you are in hoverboard mode?
Is it a real STM32 or a GD32?
For my GD32 based board, the serial rates to the sensor boards did not match that reported by others...

  #define USART2_BAUD     52177    // control via usart from GD32 based sensor boards @52177 baud
  #define USART3_BAUD     52177    // control via usart from GD32 based sensor boards @52177 baud
//#define USART2_BAUD     26300    // reported baudrate for other sensor boards?
//#define USART3_BAUD     26300    // reported baudrate for other sensor boards?

To my knowledge, I am the only person who has run this with sensor boards (so they have only been tested with my GD32 based YST board setup).
Did you get a serial connection to it? - that's probably the place to start....
And get a 'scope on the serial out of the sensor boards and estimate the baud rate - i think they pump data out constantly from power on.

good luck!

[lalalandrus]

My main board is a real ST32 and the sensors are GD32. I will scope it and read the serial port. Right now it is just stuck always on doing nothing.

[btsimonh]

first time i programmed mine from the new repo, my flash played up; never got to the bottom of it, but now seems ok. if Hoverboard mode is disabled in flash, then it will not do hoverboard functions.
You have no lights, and no response to sensor foot pads? try 'double tap' on the footpads (two activations in one second).

[lalalandrus]

Abusing the power off pin I tracked it down to init flash. I haven't had a chance to test but I am suspecting that you are not really saving a flash area. It is not defined in the linker or the flash area.c. Also I don't understand how you got 0x8000000+62*2048 in flash access but you want 0x800c000 (but not declared) in flash area.

[btsimonh]

the flash was my imaginative from scratch implementation, just stole some code from elsewhere. :).
I think (a little time ago now) I intended it to beyond the end of any code, and if flash magic not matched, to re-write. Using the serial, you have to write the correct value to the flash magic to save to the flash.... but it seemed to work as i diagnosed it a few weeks ago.
The flash area should be a segment in the linker file: (but see below... this is irrelevant)...
https://github.com/bipropellant/hoverboard-firmware/blob/master/STM32F103RCTx_FLASH.ld

  /* create a section in flash which is aligned on a page boundary, don't really care where. */
  .myFlashSection :
  {
     . = ALIGN(2048);
     *(.myFlashSection)
     *(.myFlashSection*)
     . = ALIGN(2048);
  } >FLASH

the referenced:
const uint8_t __attribute__((section (".myFlashSection"))) flash_data_inimage[FLASH_LEN] __attribute__ ((aligned (2048))) = {

but.... you are right, in flash_access.c:
volatile uint8_t *flash_data = (uint8_t *) 0x08000000 + 62*2048;

... so we don't use the 'inimage' variable.... and we rely on 0x08000000 + 62*2048 being beyond the end of our code.
best double check you have this amount of flash in STM32?

s

[lalalandrus]

I found the issues and cleaned up the section defines + rearranged inits until I got the code working. I am now stuck with both "power" led's being red but at least it is not crashing. The hoverboard is turning off via button now.

[btsimonh]

power leds mean you have coms to sensor boards (i believe).
if HB mode is active, you should get dull green for one foot, bright green for two, and motors should try to make HB level in red.
If not, double tap should enable HB mode.
did you get serial to it yet?

[lalalandrus]

Serial is the correct baud. But I suspect there is a bug there sensor board uart died because I can't see any serial from the main board to the sensors when it should be constantly sending light info

[btsimonh]

you have software serial for diags?

[lalalandrus]

After the power on message nothing else pops up

[btsimonh]

did you send unlockASCII? - but it should tell you to do this on the serial.....
To get it to output debug you may need to enable Ascii and 'EC'.
then to dump flash 'Fa'.
To commit any changes to flash 'Fm1234'.

[lalalandrus]

while i have found a few quirks and optimizations i think the issue is that the type of sensor boards i have are sending the data immediately one after another and the mainboard code that i have is unable to find the SOF and the bit alignment is wrong. the 9 bit serial i am sending to the led is working

[btsimonh]

check the new 'combined' branches... I believe the 0x1xx is the first thing received in each message.
For lights, I had to move 'color' to the front.
For receive, I now wait for 0x1xx, and then put that and up to bytes into a buffer. on the 10th byte, I coy the buffer to the used structure, and process it.

[lalalandrus]

i already moved colour to the front in sensorcomms.h
i think your yst boards have more info, the standard sensor boards only have 6 bytes including the header mem copy would be dangerous in this instance and direct variable definition would yield better cross compatibility should your strut packing change

[lalalandrus]

i finally got my hoverboard working but it seems to go into some emergency stop mode once i hit 3km/h

any thoughts?

edit: hmm maybe i need to charge my batt

[btsimonh]

yes, you are right; I have 10 byte frames from the sensor board. Better not implement anything important based on Roll or acceleration!

A thought on baud rate:
1/ they want to have a constant FRAME RATE.
2/ My frames are 10 words (11 bits each?) at 52177 -> frame interval 2.1ms
3/ Your frames are 6 words (11 bits each?) at 26315 -> frame interval 2.5ms
4/ @EmanuelFeru is at ~32100 -> maybe he has 7 words?

ref stop mode. Does it bleep?
It could be batt, temp, or timeout. Power off timer should not activate if you have motion.
It could be voltage detect calibration, or temp calibration?
Let us know after a charge :).

[TomTinkering]

Hey guys, I saw this comment on the "NiklasFauth" thread for Sinusoidal control of PMSM;

"@lalalandrusVector control like FOC, indeed would be nice, however I think we will reach the STM32F1 Series computational limitations, since we need to run the algorithm at 100 kHz and plus some additional code for balancing controller or other calculations. STM32F4 series are much more capable but they are not in the hoverboard."

I just ordered this hoverboard control board, and it comes with an F4 by GigaDevices. It also includes Mosfet drivers rather than a custom discrete implementation with BJT's for the motor drives.

Looking on Ebay I see a lot of these boards around, so if you need more processing power it might be worth developing for this board. I could help out with the base firmware (ADC's, PWM outputs etc.), but I don't know much about FOC. I do have an updated schematic of the board.

[btsimonh]

it's probably the same as my YST board.... GD32 based, double the CPU power (not sure what clock I'm running with the firmware though).
there is some info on my board herE:
https://github.com/btsimonh/hoverboard-firmware-hack/tree/newprotocol/otherboards/YST-6.5-10-PCBA-10
and some pics in folder above.
If it is the same, it's got some nice spare pins, not too difficult to access....
Confirm?
Actually, maybe a generation on. I'm pretty sure mine is a GD32F103.

[TomTinkering]

Yes, it is an YST board, but I think the next generation, as it features a GD32F403 instead of 103.

I will be using this board in the coming weeks for a project, and was planning to port the NiklasFauth firmware for it. Of course it would be even better if FOC would also be possible.

[EFeru]

Will change the comment.. so you have 8 words? yes?

No, I used default, so 10 words as I see.

[btsimonh]

it would work regardless, just may be better to know the number. I thought you had acceleration but not roll? or was that someone else? or was it just what your were sending,not necessarily what you actually saw from the sensor boards? (i'll change the comment to 10, but if you find different, you can always issue a PR :) ).

[EFeru]

Ok. I don't know exactly the number of words since I do not have a logic analyzer. I just saw in other places, tried it and it worked.
Funny part is that without those 2 times "82" at the end the motors stopped listening. I was also puzzled why those numbers at the end. I still don't know why.

[EFeru]

@lalalandrus

@EmanuelFeru start with my repo unless you want to start from scratch. :( so many different baud rates....

ok. It is always good to start from something :) Link?

[btsimonh]

new measurements:
Main loop interval_us 5000; lates 1, processing_us 1341, interval by tick 5, bldc freq 16005
compare to prev:
Main loop interval_us 5001; lates 3, processing_us 1955, interval by tick 5, bldc freq 16020

1 line change:
#define static static inline
near top of BLDC_controller.c
Not a miracle, but a start..... (does not solve ticking.)

(pushed to https://github.com/bipropellant/bipropellant-hoverboard-firmware/tree/newbldc-btsimonh)

[lalalandrus]

@lalalandrus

@EmanuelFeru start with my repo unless you want to start from scratch. :( so many different baud rates....

ok. It is always good to start from something :) Link?

https://github.com/lalalandrus/hoverboard-firmware

according to @btsimonh it works more or less as is on the GD uC (motor directions reversed)

[EFeru]

@btsimonh I just tried with SENSOR_WORDS 6, 8, and 10. They all work. I confirm.

[AntumArk]

ped listening. I was also puzzled why those numbers at the end. I still don't know why.

Those are END bytes. Fairly ussual for communication protocols. You have Start bytes and End bytes . That is how you can detect a packet.

[btsimonh]

haha... @lalalandrus and I just moved to using them as start bytes ! it make little difference on receipt as the data is very regular and constant. On send, I just send twice, avoiding issues.

[lalalandrus]

UART comms like this x100 is start byte and 82 could be an end byte but no needed in our case. as a someone who makes fiber optic switches i would say start bytes are almost always present and endbytes are only sometimes present

[AntumArk]

Well for moving it is best for all packets to be correct. Health is at risk.

[lalalandrus]

it happens at high speed too :(. (pick up a wheel, and rotate board angle, ticks are quite sever, especially when changing speed.)
@lalalandrus - missing link? just worked first time after merging your repo - check the push for the (small) adjustments - but it's on top of another branch, not on top of main :(. but nothing which should affect this.

it seems your GD32F403 is M4 @ 168M with zero wait flash execution which would be much much faster than our STM32F104 M3 @ 72M with a one instruction wait state

Well for moving it is best for all packets to be correct. Health is at risk.

the packet decoding error is not due to the packets being decoded wrong, the bytes themselves are wrong. this leads me to believe maybe the baud rate is wrong, there is a bad interrupt, or the signal is being corrupted in someway

[btsimonh]

:) ref the 0x100, it's definately 0x1xx - the msg SENT to the sensor board uses the low 8 bits for colour.... in the msg received, I've never seen anything but 00 in the lower 8 bits of the word with the 9th bit set....
Just rode the board to the kitchen and back, and it's no worse than with the old BLDC in terms of the missed steps. Just a lot quieter at speed... :).

@EmanuelFeru - what variable was it you said controlled the expected interval? & what should I set it to for 16khz?

[EFeru]

@btsimonh According to my measurements, I was running the sinusoidal BLDC control at 16 kHz without problems and down to 8 kHz. So in this range 8kHz - 16 kHz should be fine. I did not test on higher frequencies than 16 kHz.

[btsimonh]

@lalalandrus - "the hall effect only gives you roughly 40 degree resolution which is pretty poor."

• look at the wheel construction, one tick of hall == ~6mm - there are many BLDC 'revolutions' per wheel revolution because there are lots of magnets. I counted 90 identifiable hall positions per rev on my motors....

[lalalandrus]

@lalalandrus - "the hall effect only gives you roughly 40 degree resolution which is pretty poor."

• look at the wheel construction, one tick of hall == ~6mm - there are many BLDC 'revolutions' per wheel revolution because there are lots of magnets. I counted 90 identifiable hall positions per rev on my motors....

lol order of magnitide off 4 degrees vs 40 my math is bad

[btsimonh]

@EmanuelFeru - so your position estimation does not depend on a time interval, as long as we're within a range?
We could easily test at 8khz on STM32 by only running the BLDC every 2nd interrupt? (please test?)
How fast do we NEED for how many RPM?

quick 'fag packet' calculation -
@lalalandrus wants 30kph -> 30000m/h =>500m/min -> 8.3m/s -> 8300 mm/s
we have a hall change every ~6mm => ~1380 hall clicks/s
So if we run at 8khz, we have ~6 interrupts per hall tick.
Is this enough for a rough sin wave? Probably?
At 40kph -> ~4 interrupts per hall tick -> probaly still good enough. Although at that speed, who's going to hear the noise?
:) :)

[lalalandrus]

@EmanuelFeru - so your position estimation does not depend on a time interval, as long as we're within a range?
We could easily test at 8khz on STM32 by only running the BLDC every 2nd interrupt? (please test?)
How fast do we NEED for how many RPM?

quick 'fag packet' calculation -
@lalalandrus wants 30kph -> 30000m/h =>500m/min -> 8.3m/s -> 8300 mm/s
we have a hall change every ~6mm => ~1380 hall clicks/s
So if we run at 8khz, we have ~6 interrupts per hall tick.
Is this enough for a rough sin wave? Probably?
At 40kph -> ~4 interrupts per hall tick -> probaly still good enough. Although at that speed, who's going to hear the noise?
:) :)

but your butt will feel it travel up your spine into your ear.... :D

[EFeru]

That should be still ok. Not as smooth and quiet as for 16kHz but still better than Commutation method.
And indeed, at 40kph speed I think the road noise will cover anyway the motor noise.

so your position estimation does not depend on a time interval, as long as we're within a range?

My position estimation does not depend on time interval. I mean, I do not measure the time. I use previous counter to estimate the next interval between Hall changes.
Ok, of course there is a relation between counter and time and some error depending on how fast are the accelerating phases and deceleration phases. But I tested during dynamics and still behaves well.

When you have some repo to share, I would like to try to see how motors are behaving... but you have a GD32 board.. hmm

[lalalandrus]

@EmanuelFeru if we cant get the STM32F103 to work we can migrate to STM32F405/415
https://www.digikey.com/product-detail/en/stmicroelectronics/STM32F415RGT6/497-11907-ND/2757675
https://www.digikey.com/product-detail/en/stmicroelectronics/STM32F405RGT7/497-17433-ND/5051343

[EFeru]

@lalalandrus yes, that can be. I have now much better skills in desoldering these types of SMD components :) The only issue is for other people that want to use the code and cannot desolder, not having the micro-controller, etc.

[btsimonh]

@ 8khz on GD32:
Main loop interval_us 5000; lates 2, processing_us 724, interval by tick 5, bldc freq 16035
last measurements (16khz):
Main loop interval_us 5000; lates 1, processing_us 1341, interval by tick 5, bldc freq 16005
first measurement (no inline):
Main loop interval_us 5001; lates 3, processing_us 1955, interval by tick 5, bldc freq 16020
Original firmware:
Main loop interval_us 5000; lates 3, processing_us 465, interval by tick 5, bldc freq 16055

I think 8khz should be good with STM32F1, it's not far off where we were.
I believe there is optimisation in @EmanuelFeru 's auto generated code to be had, but not something I fancy looking at tonight :).
8khz pushed in this repo on my newbldc-btsimonh branch.
(still want to instrument in CPU cycles, so we can measure the actual interrupt routines... but done for today!)

@EmanuelFeru - fantastic work! @lalalandrus - thanks for the first integration (well, the one i chose...).

I do want to think about how we can drive the sinusoidal waveforms statically at an angle and power for very slow speed use & slow start. It hurts my brain, so suggestion welcome. (I'd like to be able to specify posn (hall count from hall interrupts) fractional posn, and 'power', and for the system to set the wheels to this posn, maintaining the specified power (current) into the coils to keep it there.)

@lalalandrus - this repo must have options to work on the lowest power devices; basically you should be able to take any HB and use the firmware. Not saying we can't have extra features that depend on a more powerful platform.... :)

[btsimonh]

@EmanuelFeru - "When you have some repo to share, I would like to try to see how motors are behaving... but you have a GD32 board.. hmm"
it's here :). currently @8khz. should just build for STM32, no changes except performance.
https://github.com/bipropellant/bipropellant-hoverboard-firmware/tree/newbldc-btsimonh

would be good to see your output from the main timing diags....
on serial, type
\n
unlockASCII\n
s\n
(run the HB by double tapping a side)
then
s\n
a second time to check it's consistent.

[lalalandrus]

excited to test. it is amazing what we have accomplished in just over 2 weeks

[EFeru]

@btsimonh Thank you as well for your effort!

One remark, you mentioned some ticks, Do you use any sort of filter in your control algorithm before sending the commands to motor control?
Because I just tried with no filtering on Potentiometers and I do get ticks, and those I think are coming from very sudden commands.
I do get them also in the Commutation method but it feels less, because the motors already make quite some noise.

I will take a brake now, let's resume it soon. Nice Work!

[EFeru]

@btsimonh
https://github.com/bipropellant/bipropellant-hoverboard-firmware/tree/newbldc-btsimonh
is locked.. I think

[btsimonh]

hmm.. you should be able to get there by just selecting the branch dropdown from the main repo...
or add it as a remote you yours (if based on ours), and merge to a branch of your own.
or clone the base repo, do a full fetch, then checkout newbldc-btsimonh.
I use 'sourcetree' - not perfect but an OK git UI for windows....

[lalalandrus]

The code works and I hit 30km exactly under load. A couple things I observed were sounds from the motor when under load and when it starts phase advance. When underload it almost seems like it is skipping steps.

It almost seems like phase advance is happening based on PWML and PWMR rather than speed of the wheel. I notice that the grinding noise happens when pwm is over a certain value or if the wheel hits a disturbance and loses a lot of speed. Could this be a side effect of moving the loop to 8Khz?

[btsimonh]

it's very easy to reproduce close to or at zero velocity, but this is not unexpected.
An article on it
https://www.machinedesign.com/motorsdrives/why-open-loop-steppers-lose-steps-and-how-solve-problem
I should stress that I had the exact same ticking or missing with the original code, but it was less severe near zero speed, and less often generally. (I had put it down to sensor mireads, but now I have these producing a console log, they do not necessarily correlate, and I also ignore the data when they happen)

P.s. we should move to a new issue - else we'll break github by quantity of comments!
created one to continue on here:
#32