Open-source CANbus wheelchair controller

I have just uploaded a draft builder's and user's guide for my CANbus wheelchair controller system and I would appreciate your comments and criticisms. It can be retrieved at:
drive.google.com/open?id=0B3svXvyPGRgreXFKSlZDVThWSTg

Of particular interest to the Roboteq community is the description of the controller script. This system has been in daily use for over a year, and some non-CANbus elements, particularly the Roboteq script, are also being used, with both brushed-motor and brushless-motor controllers, on wheelchairs in Italy, the U.K. and the U.S. as well as on a small, lawn-mower robot.

If you would like copies of any of the program or electronics design files, please contact me directly by PM or e-mail.

Ciao,
Lenny

Good job!
Can you show the program?
Thank you.
This email address is being protected from spambots. You need JavaScript enabled to view it.

I've just uploaded a revised version of the complete system, hardware and software, to GoogleDrive. This revision includes my latest attempts at getting good motor compensation without the use of motor current sensors. I've also included an analog version of the Roboteq script for those who might want to try it (but, warning, the non-CAN version is mostly untested so do be cautious). The files are at:



Something to think about for those using, or considering using, brushless motors. You may have a better alternative available instead of IR motor compensation (which you must do without current sensors in any case). Your Hall sensors provide RPM information and that means that you can hold steady speed by using closed-loop control. Things to consider:

(1) Usually, closed loop PID is tuned to come as close as possible to no undershoot, no overshoot and no oscillation. "Ideal" tuning, however, also means loss of road feel - or what in flying is called "seat of the pants" feel. But you don't need to tune the PID that way - tuning it so there's some undershoot (but, of course, avoiding any oscillation) would give back that seat of the pants feel when, for example, hitting a bump.

(2) The Roboteq provides two different closed loop speed algorithms. (1) straight speed where the feedback "error" is the difference between intended RPM and measured RPM, or (2) speed/position where the controller predicts every 1 msec what should be the next position of the motor at the commanded speed and uses the difference between predicted and actual position for the feedback. The reason for the second algorithm is that the straight RPM measure is not very accurate at very low RPM. The "speed" algorithm might actually be accurate enough for the "loose" closed loop I'm thinking of, but it may be worth experimenting with both algorithms, or even switching on the fly between speed/position feedback at low speeds and RPM feedback at higher speeds.

(3) At the script level, all this would involve, if you don't need to use both closed loop algorithms, is commenting out the call to GoSub MotorCompensation. Setting the closed loop parameters in the configuration profile, however, will take some experimenting and, having neither brushless motors nor a brushless controller I can't help you with that. The current Roboteq user's manual does seem to have a fairly good description of both the speed and speed/position algorithms along with suggestions for how to start the PID tuning for each (and it's very different for the two). I really do suspect that this will be a better route to go for brushless motors than conventional compensation.

Ooops, I managed to post the above without the link: drive.google.com/open?id=0B3svXvyPGRgral9FU2lJZlpHdFU

Hi Lenny,

I would like to see the small lawnmowing robot, do you have pictures of it or maybe a video?
Can it really work as a robot (automatic)?

The mobot is not mine - it was built by John Williamson, and you can find information about it at WheelchairDriver.com.

The latest update is now available at:

Wheelchair CANbus

Having found a situation in which even the best-tuned (I think) motor compensation using estimated motor current is less than satisfactory and having figured out how to detect current sensor failures, this revision re-introduces the possibility of using Allegro current sensors.

The situation in which I've not been able to get estimated motor current-based compensation to work well is with relatively high-impedance motors on a device with a very high power to weight ratio. On my daughter's wheelchair, and I suspect on most any wheelchair, I am hard pressed to feel any difference between compensation with estimated vs. measured motor current. A device with lot's of power for its weight, however, can reach significant speed before there's measurable battery current, and until then there's no compensation for varying loads.

The script now tests for current sensor faults in two ways: (1) when not moving, it declares a fault if the sensor says that >1 Amp (for 100 Amp sensors, >0.1 A for 10 Amp sensors) is flowing, (2) when moving, it back-calculates battery current from motor current and declares a fault if this differs from measured battery current by >= twice the minimum battery current measurable by the controller. A fault at startup, before entering the loop, NOT SensorOK causes MotorCompenstion to be bypassed. This gives a quite obvious change in driving behavior, so that you know there's been a fault, but it still lets you get home. In the CANbus system, as opposed to the standalone script, there's also a SensorFault message sent to Display where it is shown on screen and logged. If a fault occurs after the main loop has been entered, SensorFault causes the script to revert to using estimated motor current (and reverts back if the fault clears).