Acceleration/deceleration with mixing
8 years 11 months ago #29529471
by LROBBINS
Acceleration/deceleration with mixing was created by LROBBINS
I am helping two friends with scripting their Roboteq HDC2450 and HBL2360 controllers. In both cases they are using Throttle and Steering joystick outputs that are mixed by the controller to get Motor 1 and Motor 2 command values and both of them reported a serious controllability problem when decelerating from a forward-moving turn. Indeed, there is a problem and it applies to acceleration while turning as well as deceleration, though it was first noticed during deceleration. It derives from the fact that although the motor commands are the result of mixing the Throttle and Steering values, the mixing algorithm is not in any way applied to acceleration and deceleration rates.
It is easier to see this graphically than to explain it with words, so I have attached several graphs. The first illustrates the "normal" result of centering the stick after being in a steady forward turn. The graph contains four curves; two correspond to Motor 1(red) and Motor 2 (yellow) power as one would see them in the Roborun Run tab, and two show what the vehicle does as the result of these - these are just the result of un-mixing the motor power values to get fore/aft (green) and left/right (blue) motion. (BTW, These graphs were made in a spreadsheet, but I think it would be very useful, and rather trivial, to add the fore/aft and left/right curves to the Roborun graph choices as they give a fairly intuitive picture of the effective results under mixing.)
At the start of this graph, we are in an 18% turn with M2 power less than M1 power. When the stick is centered, both power curves decline at the same rate, and forward motion decays in parallel. Notice, however, what happens to turning motion. Turning does not stop, nor decay at all, until M2 power has gone to zero - when forward motion has already largely ceased, and fore/aft deceleration rate is halved because one motor is already stopped. If this were an automobile, I think I'd describe this as severe torque oversteer during deceleration. As these are actually high-performance wheelchairs, the result is busted doorways and perhaps busted legs.
The converse occurs if you accelerate into a turn. The vehicle will move straight forward (or back) until the inside wheel reaches its set power and only then will it start to turn. Imagine trying to go around an obstacle with this kind of behavior!
The second graph shows that, if instead of just applying constant deceleration values to both motors, we use the un-mixed fore/aft and left/right results to bias the deceleration rates, we can get rid of this problem. Here, deceleration rate of the inside wheel is reduced and that of the outside wheel is increased, but because the turn rate decays over time, so does this bias.
Now, the power curves are not parallel straight lines but converge, and fore/aft motion declines linearly even at the end. Most importantly, instead of continuing to turn at a constant rate until forward motion has nearly stopped, the vehicle also straightens out.
As shown in the next two graphs, we can get an even snappier steering response by over-weighting the biasing of deceleration rates.
In both of these, initial fore/aft deceleration is not linear, because the deceleration rate of the inside wheel cannot be less than 0, but the net result is that turning stops quickly while fore/aft motion decays in a nicely controllable fashion.
Although I have been able to get this desirable behavior by scripting biased, variable, acceleration and deceleration rates (some apparent bugs in _ACEL, _DECEL, _MAC and _MDEC will be covered in another post), I think that this is really something that should be "built in" to Roboteq's mixing algorithms.
Lenny Robbins (Siena, Italy)
It is easier to see this graphically than to explain it with words, so I have attached several graphs. The first illustrates the "normal" result of centering the stick after being in a steady forward turn. The graph contains four curves; two correspond to Motor 1(red) and Motor 2 (yellow) power as one would see them in the Roborun Run tab, and two show what the vehicle does as the result of these - these are just the result of un-mixing the motor power values to get fore/aft (green) and left/right (blue) motion. (BTW, These graphs were made in a spreadsheet, but I think it would be very useful, and rather trivial, to add the fore/aft and left/right curves to the Roborun graph choices as they give a fairly intuitive picture of the effective results under mixing.)
At the start of this graph, we are in an 18% turn with M2 power less than M1 power. When the stick is centered, both power curves decline at the same rate, and forward motion decays in parallel. Notice, however, what happens to turning motion. Turning does not stop, nor decay at all, until M2 power has gone to zero - when forward motion has already largely ceased, and fore/aft deceleration rate is halved because one motor is already stopped. If this were an automobile, I think I'd describe this as severe torque oversteer during deceleration. As these are actually high-performance wheelchairs, the result is busted doorways and perhaps busted legs.
The converse occurs if you accelerate into a turn. The vehicle will move straight forward (or back) until the inside wheel reaches its set power and only then will it start to turn. Imagine trying to go around an obstacle with this kind of behavior!
The second graph shows that, if instead of just applying constant deceleration values to both motors, we use the un-mixed fore/aft and left/right results to bias the deceleration rates, we can get rid of this problem. Here, deceleration rate of the inside wheel is reduced and that of the outside wheel is increased, but because the turn rate decays over time, so does this bias.
Now, the power curves are not parallel straight lines but converge, and fore/aft motion declines linearly even at the end. Most importantly, instead of continuing to turn at a constant rate until forward motion has nearly stopped, the vehicle also straightens out.
As shown in the next two graphs, we can get an even snappier steering response by over-weighting the biasing of deceleration rates.
In both of these, initial fore/aft deceleration is not linear, because the deceleration rate of the inside wheel cannot be less than 0, but the net result is that turning stops quickly while fore/aft motion decays in a nicely controllable fashion.
Although I have been able to get this desirable behavior by scripting biased, variable, acceleration and deceleration rates (some apparent bugs in _ACEL, _DECEL, _MAC and _MDEC will be covered in another post), I think that this is really something that should be "built in" to Roboteq's mixing algorithms.
Lenny Robbins (Siena, Italy)
Please Log in or Create an account to join the conversation.
Moderators: tonysantoni
Time to create page: 0.137 seconds
