Back in Control

Friday, November 6th, ©2009 Marcus Brooks

Some time ago I mentioned that my wheelchair’s Robot Power Sidewinder speed controller died, and that I’ve been using a simple bang-bang controller instead. I have finally remedied the situation, but it took far longer than I hoped.

My first try was simply to order a new controller. This time I ordered the Roboteq AX1500. I’d heard some negatives about Roboteq quality, but the AX1500 was in stock, and I was in a hurry.

Roboteq AX1500 Screw Clearance Issue

Roboteq AX1500 Screw Clearance Issue

A quick inspection of the Roboteq wasn’t encouraging. It’s FETs are placed somewhat haphazardly; this is not unusual or necessarily harmful for surface-mount parts, but the layout didn’t allow for it. As a result, the heat sink screws’ nylon washers don’t clear the FET tabs, so the screws exert only a tenuous hold on the heat sink. I could trim the washers to fit, but that might allow the metal screw heads to short the tabs. I can only hope the washers don’t deform and slip over time, loosening the  heat sink.

This issue is moot so far because the FETs have never turned on. I hoped the AX1500’s default R/C mode would make it a direct replacement for the Sidewinder, but when I installed the AX1500, I got nothing. The status light indicated the board was “alive” and in the RC mode, but its outputs were just as dead as the Sidewinder’s. Also I had no luck using the AX1500’s serial connection, either at the documented setting or any other setting I’ve tried.

I’m not ready to declare the AX1500 DOA yet. It might have ignored my joystick because my joystick firmware restricted its R/C pulse output to one third of the standard range. (At full range, the Sidewinder was a bit hard to control.) And the serial communication problem might be caused by my serial to USB adapter. I won’t give up on the AX1500 until I’ve checked its serial output on a scope.

In the meantime, I decided to try getting the Sidewinder fixed after all. I had initially thought a new controller would be the fastest fix (it would have been, if it had worked). Now I went ahead and sent the Sidewinder to Rob Purdy, a tech recommended by Robot Power for their products. He found the fussy-to-replace FETs were undamaged, so the repair cost was minimal (well under $100), and I got the repaired board back in just a little over a week. (If only… oh well.)

The Sidewinder’s calibration changed, so I had to reprogram my joystick after all. I hadn’t tried that for the Roboteq because my microcontroller programmer wasn’t working. This time I had fresh eyes, I guess, because I found the faulty jumper on my joystick board and was able to re-flash it as needed to get the Sidewinder calibrated.

While I was in the code, I fixed something that’s been bothering me for a while. The method I used to reduce the speed range cut my top speed to about half its potential, an unhurried 3 MPH or less.

I’ve tried exponential or logarithmic control curves to enhance maneuverability while increasing top speed, but they didn’t really help because they actually vary deflection. I think this affects control rates in aircraft because roll and pitch rates are proportional to surface deflection. But for a speed controller, speed changes (or slews) at the same rate for both small and large deflections.

It would help to change the actual slew rate as the stick moves away from center. For example, if you increase forward speed from zero to 20%, the change would occur almost instantly. But if you increase speed from 80% to 100%, the change would occur only gradually, perhaps taking a second or so to complete. Unfortunately, making the slew rate variable would involve a pretty hefty rewrite of my current joystick firmware.

Fortunately, I have thought of something much easier that’s almost as good. My joystick movement includes a button switch under the stick. I’ve been using this to toggle a “parking brake” mode that zeroes the control output but keeps the motors engaged for dynamic braking. I also have a separate key switch wired to the speed controller’s “disable” input. Disabling the speed controller disconnects the motors so they can “coast” more or less freely. More to the point, disabling the speed controller also powers off the joystick microcontroller.

To fix my speed range problem, I’ve added code to check the joystick button when the controller is enabled. If you switch on normally, the firmware divides all stick inputs by three to improve control in confined spaces. If you hold the button while turning on the controller, the forward speed divisor is set to 1, and forward inputs have full effect. This gives me an unrestricted speed control mode to use outside, where abrupt changes are more manageable.

I’ve checked my new firmware’s behavior with a voltmeter, but I haven’t tried it outside yet. Based on previous experience I’m confident it will be controllable, and it’s sure to make runs to and from the bus stop much less tedious!

Tags: , , , , , , , ,

Leave a Reply