Apparent bugs in _ACCEL, _DECEL, _MAC and _MDEC

Moderator: I am posting this here rather than in the MicroBasic forum because my comments concern built-in Roboteq functions rather than any question about how to write a MicroBasic script. If you think it would be better posted elsewhere, feel free to move it.

In order to deal with a serious steering problem with mixing when accelerating or decelerating
dev.roboteq.com/dev1/index.php/forum/14-...leration-with-mixing
it was necessary to script on-the-fly changes in acceleration and deceleration rates. The commands for this, however, proved problematic.

First, as far as I can tell SetCommand (_ACCEL, motor, value) and SetCommand (_DECEL, motor, value) do absolutely nothing.
I am not the first to report a problem with these:
dev.roboteq.com/dev1/index.php/forum/11-...ons-remarks?start=10
The only thing that I can add to that thread, which ended before a solution was reported, is that the suggestion to use SetConfig (_ACCEL) is clearly incorrect. A glance at Constants.h is enough to see that invoking SetConfig (_ACCEL) will actually yield SetConfig (_CPRI) and typing SetConfig (_DECEL) will produce a call to SetConfig (_RWD).

Second, the alternative to using _ACCEL and _DECEL is to use _MAC and _MDEC, and these indeed do work, but not without problems. Problems that I suspect were introduced with the minor firmware update of 10/23/2013 that included:
- Increased absolute max motor acceleration from 100ms to 10ms to max RPM

If one enters an acceleration or deceleration value in the Configuration tab of Roborun, say 300, it will show in the edit box as 300.0 . If one then looks in the XML Profile file, you'll find that this is recorded there as 3000. If, in a script, however, one calls GetConfig (_MAC) or GetConfig (_MDEC) the number returned is neither of these – it is 300. Sending the value returned by GetConfig to the controller with SetConfig (_MAC) or SetConfig (_MDEC) results in an acceleration or deceleration rate only one-tenth of what's expected.

In case this is not clear, configure the controller for open loop operation, no mixing and with all acceleration and deceleration values set in Roborun as 300.0. Now write a simple script that leaves acceleration values for one motor alone and sets the other, using SetConfig [without writing to EEPROM], to the values returned by GetConfig. Follow this with SetCommand (_GO,1,1000) and SetCommand (_GO,2,1000). The motor that has been re-configured in the script will accelerate at 30, while the other accelerates at 300 "power units" per second. There is a ten-fold error! (also present during deceleration)

As I suggested above, I suspect that these functions worked correctly before the 10/23/2013 update and that there was a simple oversight: the factor of ten change in maximum value was taken account of in Roborun configuration and in the XML file, but the equivalent change was not introduced in the handling of _MAC and _MDEC. I have not checked whether the same problem is there if one gets and sets MAC and MDEC via serial, but I have a sneaking suspicion that it applies there as well.

Once discovered and verified, the workaround for this problem was quite obvious – multiply the desired values by 10 before invoking SetConfig. However, before others end up scratching their heads in confusion as I did, I do think that Roboteq should either fix this problem OR post an addendum to the user manual that explains what needs to be done.

HOWEVER, I want to add a cautionary note. If you should fix _MAC and _MDEC, please warn anyone who is using them in a script (with the 10/23/2013 firmware). If corrected _MAC and _MDEC functions are called in a script that is already multiplying by ten, one could have a rather unexpected, and potentially dangerous, result.

I want to add some comments about the difficult process involved in my finding and verifying this problem. I am in Siena, Italy and am helping two friends, one in England and the other in the U.S. with scripting the controllers that they are using in two quite-different high performance wheelchairs. I do not even own a Roboteq controller (though expect to have my very own by the end of August), so every bit of this requires sending scripts to them for testing after only the minimal verification provided by scripting simulation. For safety reasons, the field testing of each change is done in three stages; (1) with the wheelchair jacked up (generally meaning a wait until an able-bodied helper is available), (2) under RC control without a person aboard, and finally (3) in actual use. This experience leads me to suggest several changes in Roborun which I will cover in another posting that should allow more rigorous verification before undertaking physical testing. Our particular situation aside, even in less safety-critical uses, but of course involving powerful motors that can do a lot of damage (or we wouldn't be using an HDC2450 or HBL2360 in the first place), the more tools we have to clearly see what a script does before risking motors and controller the better.

Lenny Robbins (Siena, Italy)