Closed loop is jerky, motor is stopped when drive re-enabled

What is the timeline for the next release?

I respect your cautiousness while introducing new changes, but at the time see this as a hopeless situation. Unsubscribing and ditching the hardware. Too bad you will not accept it back...

Disregarding the little bad taste of the sentence:

"It has not been implemented yet. Its priority will rise since you require it."

... as we asked for the feature a long time ago, I think velometro also will come to the conclusion that the controller is not yet recommended for an application where you have to reengage the drive during freewheeling securely.

(We left a "boneyard" of about 10 "barbecued" controllers by trying to find a solution for the problem.)

comment removed.

Hello velometro!

As formerly written we found a better controller for our purpose. To find a controller like the roboteq was hard and to find an alternative was even harder.

As I don´t want to harm roboteq I wouldn´t post names of other manufacturer(s) here in the forum. Also I don´t know how to write you a personal message.

Is velometro also the name of your homepage? If it is I will write you a email.

yep, info at velometro dot com works.

Turning off the MOSFETs is a no-brainer. The challenge is to know when it is safe to turn them back on, how to turn them on, with what PWM level. This is not as simple as it sounds.

If when turning back on, BEMF > Vbat*PWM, there will be a braking effect that will be proportional to the difference between the two sides of the >. If BEMF < Vbat*PWM, there will be a jolt of acceleration.

We faced this question some years ago when working with a customer on a hybrid scooter. The ride was uncomfortable and a couple of controllers ended up as BBQ then, until we came up with the controlled regenerative braking method that we describe here dev.roboteq.com/dev1/index.php/component...-sensing?Itemid=1208

It works like a charm and is still the most elegant method to smoothly transit from progressing traction to progressive braking.

The other method that we experimented with during the scooter work is to disable the synchronous rectification. When synchronous rectification is enabled (it is always enabled in our controllers), on the motor phase that is PWMing, the wire is pulled to ground by the bottom mosfet when PWM is on, and is pulled to Vbattery by the top mosfet when PWM is off. When synchronous rectification is disabled, the bottom mosfet is on when PWM is on, but the top mosfet is always off.

The effect or disabling the synchronous rectification is to eliminate the regenerative braking altogether. So throttling down makes the motor coast. Throttling back up, no traction is felt until the PWM*Vbat > BEMF. Incidentally this is how the ebike controllers work on the models where the dynamic braking can be disabled. This method was inadequate for the hybrid scooter but it may be working well enough for other type of ebikes. We can produce a firmware to test upon request.

Note that this will only work for trapezoidal switching. In sinusoidal switching the top and bottom mosfets MUST switch in a complementary manner.

Regarding the discussion of this thread, we were about to implement a command that was going to have the same effect as the forced overvoltage conditions, ie. immediatel float the MOSFETs. It looked simple enough that we could do in to include it in the release candidate we are currently validating. But as we began to work on it, the question came about which channel(s) should go off (one or both?), what to do while off (cutting PWM, keeping it at the command level?) and more importantly what to do when back on (restore last PWM, ramping back up, ...?). This felt like deja vu and we figured that this needed to be thought through carefully and discused with our users.

Sounds easy enough.
1. Since this should be part of motor control and not battery-related protection, switch off should be per motor/channel.
2. Gradual ramp up is definitely a bad idea, unless you would ramp it up in asynchronous mode and then switch to synchronous when value reached. But that can be hard to document. Also could be feasible in true torque mode, but your controllers are not up to task (at least MBL1660). So no ramp up, immediately switch to required duty cycle.
3. Receiving and using throttle commands should be independent of state of power stage. When power stage is switched back on, it should output duty cycle from last throttle command. Even if that command was received while power stage was off. This is probably the most critical part that I was expecting to be implemented already. But it was not.

These changes look very simple. Of course nothing is as simple and there is always risk of breaking something else. I've worked on large firmware projects just like this and do understand it well. But these changes seem really easy. Just introduce new command, if not sure about compatibility.


By the way, I want to report a strange behavior on MBL1660... Your suggested torque control script was implemented and tuned a little to suit our requirements. All is well, it works most of the time. However thing start to go south when current limiting is reached: throttle starts to lag a lot. For example the vehicle is going 5km/h and suddenly you twist the throttle all the way to 100%. Vehicle accelerates nicely, as expected. However, if throttle is released while it is still doing current limiting, acceleration lags for at least one second. Same goes with regenerative breaking: if current limiting is reached, it regenerates much longer than commanded via analogue input.
At the time testing took place, it was a nightmare, we could not find where the issue is, rewfrote the script several times.
But now, when we moved on and no long care, I believe it is something to do with throttle ramp up filter. It is some kind of weird filtering delay I guess... Whatever it is, it's dangerous, a lot of nasty things could happen in that one second.

BTW my MBL1660 is for sell, if someone needs it in EU (no taxes).