EFeru / hoverboard-firmware-hack-FOC

With Field Oriented Control (FOC)
GNU General Public License v3.0
1.17k stars 968 forks source link

Speed shortly overshoots maximum rpm value during acceleration phase #132

Open elektroluki opened 3 years ago

elektroluki commented 3 years ago

Hello!

First of all: Thank you for all your hard work on this software. The motor FOC control works absolutely terrific. I have built a small E-Kart for my kids, and for now have limited the maximum speed and motor current (torque mode) to somewhat low values (7 Amps, 150 rpm). I am operating in Hovercar mode.

The observation is that while speeding up, the set maximum rpm seems to overshoot, which leads to something like a "breaking action" after the acceleration phase. Once the cart is slowing down to the set maximum rpm, it keeps the speed constant and everything is fine. It is still a somewhat strange driving experience.

I wanted to ask, if this issue can be solved by some regulator settings (I guess at some point a speed regulator has to take over the torque regulation, and that point seems to happen a little too late). If you have an idea, just give me a hint and I will play with the settings. If you see no option, with the existing code, I'm willing to add some code to the project. I have some experience with Motor controls myself... https://closed-loop-bldc.blogspot.com/

My kids have so much fun with the E-Kart, thanks again for helping to make that possible!

With kind regards Lukas

Candas1 commented 3 years ago

Hi,

Actually I saw that behavior in the past but I didn't question it. Using torque mode, 7Amps and 150 rpm as limits I could reproduce it.

image

Emanuel might be able to explain why it behaves like that in that particular case.

EFeru commented 3 years ago

Interesting finding. I will double check the code. I think it has to do something with the speed limitation. I will have a look to see if it can be fixed.

EFeru commented 3 years ago

@elektroluki @Candas1 I had a quick look on the behavior and how to fix it or mitigate it.

It does overshoot because either the Speed limitations is too slow or the Speed increase is too fast and the limitation does not have enough time to detect it. I think of 2 approaches:

  1. We make the input target from the pedals slower, by reducing the RATE. Then the acceleration will be slower, but it will give time to the Speed limitation to take action and possibly to avoid the behavior we see. I expect this to be needed only for light vehicle because for heavy vehicles or karts is not needed because the acceleration will be slow anyway due to increased weight. https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/63276132a7f97457a2bd19a29451e88569920985/Inc/config.h#L181-L182

  2. We increase the parameter below. The risk here is that we can overshoot on the other side if we increase it too much, because it can overreact. https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/63276132a7f97457a2bd19a29451e88569920985/Src/BLDC_controller_data.c#L335-L340

I don't know how much are you willing to test these options.

Candas1 commented 3 years ago

I tried option 1 with those values, decreasing the rate and using filter and speed_coefficient from nunchuk variant: image

It's still overshooting up to 371 rpm.

elektroluki commented 3 years ago

Hello again!

Thanks for your efforts. I have tried a few things. The most success I had with changing the parameter cf_nKiLimProt. When increasing it, the overshoot is still there, but it is compensated for quickly. I hope that with the mass of the kart, the overshoot should be less irritating. When driving, the kart speeds up and then suddenly breaks to return to the maximum speed – I can see my kids struggle with the behaviour – they get confused and release the throttle which amplifies the behaviour even more.

My suspicion is, that the actual problem is a windup in the current regulator, which only starts to reduce after the speed actually overshot. Trials with n_ki and n_kp showed that the speed regulator is not in operation at all. When I change them to zero, everything behaves the same.

Some experiments with the current regulator parameters (e.g. reducing Ki) didn’t have an effect at all. I changed the values in rtp_Left as suggested, but some changes do not show an effect. Are they overwritten later?

I had a similar problem once, and I think I solved it by having the current and speed regulators active all the time, but then using either one or the other output depending on which of the two requires the smaller actuation. It made a very smooth transition between modes, but I remember that it was not just as simple as it sounds here.

For me the code is hard to read. I find it hard to identify the blocks for the regulators, but I will keep at it.

The most recent observation is that as my kids are getting more confident, I increased the maximum speed and that also decreased the effect.

Thanks again for the effort! My kids have an absolute ball with the E-Kart!

Lukas

From: Candas1 notifications@github.com<mailto:notifications@github.com> Sent: 27 January, 2021 23:54 To: EmanuelFeru/hoverboard-firmware-hack-FOC hoverboard-firmware-hack-FOC@noreply.github.com<mailto:hoverboard-firmware-hack-FOC@noreply.github.com> Cc: Mayer, Lukas W. lukasw.mayer@lwm-research.at<mailto:lukasw.mayer@lwm-research.at>; Mention mention@noreply.github.com<mailto:mention@noreply.github.com> Subject: Re: [EmanuelFeru/hoverboard-firmware-hack-FOC] Speed shortly overshoots maximum rpm value during acceleration phase (#132)

I tried option 1 with those values, decreasing the rate and using filter and speed_coefficient from nunchuk variant: [image]https://user-images.githubusercontent.com/20670049/106064566-5f2ff100-60fa-11eb-866f-0fc142c494bd.png

It's still overshooting up to 371 rpm.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/issues/132#issuecomment-768632061, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASG22MEWGE52GHNG7VUBISLS4CKRNANCNFSM4WQU4ACQ.

GigiBoot commented 3 years ago

I do not know if it helps you but I had the same problem at low RPM. For me it works by increasing Max Input to 6000

define PRI_INPUT2 1, 1070, 0, 6000, 50 // Pedal Accel

and I_MOT_MAX 8
I_DC_MAX 10
N_MOT_MAX 150

It was just trial and error until throttle was smooth enough for my kid.

elektroluki commented 2 years ago

I have tried with some success another strategy: The behaviour can be reduced by not using the full range of the throttle: Set the maximum current (torque) to a value slightly above what you need, or set it to the possible maximum. Then set the ADC value which defines maximum throttle (INPUTx_MAX) to a value that is higher than what the ADC output for the throttle can reach. The torque limitation is then done by not being able to max out the throttle. With this, the regulator has seems to have some room to "play with the current", and the respnse around maximum speed gets smoother. It also leads to a stronger breaking force than acceleration, which is something I desired as well. I hope this helps someone with similar problems.

juancargarcia84 commented 2 years ago

Hello. First of all thanks for the work. As a novice user, I find it incredible what you have achieved here. I have built a trike for my 2 year old son based on Hovercar, and it works great. I limited the rpm to reach a maximum speed of 7km/h, but I have the problem that the rpm is exceeded and then brakes slightly in excess, and then it regulates the speed correctly.

Currently I have configured with I_MOT_MAX 7A, I_DC_MAX 9A N_MOT_MAX 153rpm.

I've tried reducing default_rate, default_filter and default_speed _coefficien, but no improvement in speed throttling. Setting nKiLimProt on 400 seems to improve, with the wheels off the ground, the speed overshoot lasts half a second or less and regulates quickly, but with my son riding the overshoot last longer.

Can you think of what parameters to adjust to solve or limit this behavior?