Sinusoidal control of PMSM

[r2aiv]

Hi Niklas! What do you think about rework your project to sinusoidal control of PMSM? This may be enhance motor torque and speed, and motor will works better! I want to rework your project to this, but have some questions about scooter PCB and your code. Can you help me? How i can contact you over email?

[LeoDJ]

You can ask the questions here as well, or even better in the Telegram Group. That way, more people that knows about the details can help you as well.

[oskarlove]

Hi. Any progress in this?

I think sinusoidal commutation is necessary to get the same smooth drive as the original firmware. I get a "cogging" noise when driving with heavy load. And I get loud vibrations on some speeds.

[btsimonh]

yep; just competed implementation of original sensor drive; the hoverboard now works again as a 'hoverboard'; but it does 'grind' a bit.

[EFeru]

@btsimonh are you still active on this topic? I saw in your repository that you did something on sinusoidal control. Is that functional?

[btsimonh]

no, but looking for someone with a brain :). Repos at https://github.com/bipropellant I really want to have very slow control. Theory says that PID control should be able to achieve 6mm, but it's a lot more sloppy than that at the moment. Repos updated today....

[EFeru]

@btsimonh Ok. Because I am working on improving the motor control right now. It looks promising until now. I decided to do it, because I see the commutation method from Niklas vibrates a lot. I am a Control Engineer and that is not acceptable in my opinion. I hope in like about 2 weeks to have something that I can publish.

By the way, I also flashed your modification. I wanted to re-enable the hoverboard mode. However, I did not manage to make the motherboard read the child boards. Maybe I have a different board than you do... I admit, I did not spend time on debugging. At the moment I am using the repository from Niklas. After I finish with motor control I will have another look on your implementation. Do you know what is diferent in the Repo https://github.com/bipropellant compared to yours?

[btsimonh]

we moved my to bipropellant as the other two were doing more dev than me :) .... and split the repo to have a sub-repo for the protocol aspects (because we anticipate using it in the controllers as well...). Note this issue - @lalalandrus is also trying to get the sensor boards to talk to an STM based board. Seems he now has lights, but the sensor data interpretation or usart code is not yet functional on STM based boards. Checked mine last night with latest master branches, and it's fine, but I have a YST GD32 based board. (build with platformio and specifically build the hoverboard env). The BLDC does 'grind' a bit, and I also get some 'clicks' in use, worrying but they do not adversely affect operation as a hoverboard. Looking forward to your thoughts and implementation!

[EFeru]

Quick response :) thanks. Yes, I have an STM board (STM32F103RCT6 on the main board) and GD32 on the child boards I think (I don't have the board with me right now). Would be nice if @lalalandrus could fix the communication issue on STM32 boards. Then we could combine the new control with your implementation. I think it should be very close to the orginal firmware in terms of noise and performance but with much more flexibility.

[lalalandrus]

fine! just so happens i fixed it an hour ago though it is a sweeping change, ill upload it to my fork only and @btsimonh can have a look to see if he wants a pull, it fixes having to send the LED's twice too @EmanuelFeru can you implement the field weakening too i have a hoverkart and i want to reach at least 35km/h

[EFeru]

@lalalandrus Great! I would like to try it. Because do you know what I did to save the orginal firmware? I ordered few STM32 chips on ebay https://www.ebay.com/itm/1PCS-5PCS-STM32F103RCT6-LQFP-64-STM32F103RCT6TR-STM32F103RCT-MCU-ARM-ST-IC/183647636767?ssPageName=STRK%3AMEBIDX%3AIT&var=691112271463&_trksid=p2060353.m2749.l2649 Then I desoldered the original STM32 and resolder the empty one... actually it was a good idea because I can go revert the board whenever I want. Maybe I should make a video or something because it came out quite nice.

And yes, field weakening will be definitely there :) as I want to reach high speeds as well (if needed) because I might use these motors for other applications (as a motor to spin some other stuff). Let's keep in touch, I will come back to you with updates.

[lalalandrus]

btw i too am controls engineer

[EFeru]

Cool, then we can exchange some ideas if I get stuck somewhere

[btsimonh]

haha! 'desoldered the original STM32' - I took a software approach and tried to apply the hacks on the STM debug interface to extract it, but seems the GD32/STM32F103 are not susceptable :(.

[EFeru]

yeah, I went the hard way... haha, a bit of work and risk but luckly it worked. I read somewhere that code can be extracted, that whould be a more elegant solution. Is a pitty that it cannot be extracted :(

[lalalandrus]

ok check my repo now, grab the new config.h again to get the proper baud rate too

[p-h-a-i-l]

@EmanuelFeru Did you have a look at https://github.com/BobbyIndustries/hoverboard-firmware-hack for BLDC? When I made an overview of different branches some time ago, this was the one with most modifications in the BLDC part. Didn't have the time to look deeper, but you can see keywords like sonsorless in the code.

[EFeru]

► @lalalandrus Thanks. I will try it these days. My baud rate is a strange one 32100 bps. ► @p-h-a-i-l I have seen that repo but did not dive into it. Maybe they use better protection algorithms to protect the system. So, I think is worth having a look. However, I see they still use the commutation method (in bldc.c file), so I expect more or less similar griding noise. I will check it out.

[lalalandrus]

that is really odd , i know you likely checked but what is your pulse width

[EFeru]

hmm... if I rember correctly is was something around 31 us which leads to ~32100 bps I roughly measured it with an oscilloscope. But I am sure is working because I sent data with a blue Pill 9 bits at 32100 bps and the motors were spinnig (you know.. the old hack by serial... which I don't recommend because balancing controller is in the loop).

[lalalandrus]

3.1 doesnt seem right ~ 23000 is 38us

[EFeru]

31 us sorry. So 1/(31us) =~ 32100 bps somewhere there

[btsimonh]

@lalalandrus

ok check my repo now, grab the new config.h again to get the proper baud rate too

looking good. Surprised it ever worked with the bug in USART_sensor_addTXshort! pop in a PR and I'll test on mine this evening....

[lalalandrus]

Would be cool if we had vector control which would get field weakening and precise rpm control at the same time. We should also move the implementation discussion over to the other fork so we not spamming unrelated forks and reviving year old zombie threads 🤣

[EFeru]

@lalalandrus

Vector 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. About moving the discussion to other fork... Do you know how to do it? I am still new in github. I am more used to svn.

[btsimonh]

@EmanuelFeru - just continue it here: https://github.com/bipropellant/hoverboard-firmware/issues/10 or start a new issue about BLDC improvements by going to that repo and clicking 'new issue' :).

[EFeru]

Aa ok. Thanks!

[EFeru]

Sinusoidal control implemented here: https://github.com/EmanuelFeru/hoverboard-firmware-hack

FOC control implemented here: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC

Enjoy!