by LROBBINS » 07 Mar 2014, 10:46
Here's an idea for dealing with poor motor current estimation at low currents. WARNING: I have no way of testing/tweaking this, so use at your own risk (and report the results please).
The problem Williamclark77 seems to be having is too little boost when starting out, yet too much as soon as he starts moving. I am guessing that at least part of this is because motor current is being underestimated at startup. It is possible, in the script, to have different compensation for low and higher current draws. Say, 1.5 times basic compensation if current is less than tot, and 1 if greater or equal to tot. Or, with a bit more arithmetic even to have a curved response; more compensation at low current tapering (linearly or following a curve) at higher currents, perhaps even zero compensation as you approach max amps (at max amps compensation is in any case effectively 0 as current can't be boosted anyway at that point).
I'm coming to like this idea despite the complexity, as it would be a way to allow strong compensation at low speed without risk of runaway, and this might be useful even if using accurate motor current sensors. BUT it will take a good bit of trial and error, and it would be helpful to measure and record motor current and boost amount and graph the relationship to get a picture of how these settings interact with feel. When I get to the point of writing a Roboteq script to go along with the CANbus controller I'll try to remember to include this possibility. As I do have current sensors on my prototype, I can also record Roboteq's estimated motor current and real motor current to get a picture of just how good or bad the estimated value is in wheelchair use. Can probably record the data on the SD card I'm using to store images for the display and log files, so I wouldn't have to lug a PC along (and wouldn't be distracted by watching the PC and driving at the same time).
Another possibility, though I don't know if it actually can be programmed, would be to have torque mode at very slow speeds (just for startup really) and transition to motor compensation mode as speed increases. Constant torque really is what one wants when turning from a dead stop - then the motors can't speed up after the casters start to swivel, but constant torque is absolutely not what one wants in order to move at a constant speed over varying terrain. I'll not work on this now, the plate's too full, but will keep it in mind.
Williamclark77 also mentioned something that I hadn't thought of, but think is actually useful. He's using different curving on the throttle and steering axes - in fact, a purely linear response for steering. In writing the CANbus master I included 4 levels, from none to strong, of exponential curving, but used the same parameter in both axes (as, I think, does Dynamic DX2). Williamclark77's setup is probably much better - a gentler response in throttle than in steering. So, last night I did a little re-write of CANbus master to have separate curving settings for the two axes, but haven't tested my code yet as I have things demounted from the breadboard in order to start packaging things in proper boxes.
Indeed, at low turn stick you might even want steering to be relatively stronger as one has to overcome lots of mechanical hysteresis to get the casters to turn and the drive tires to scrub.I'll leave the notion of stronger steering response at small joystick displacements for later, but if I decide to add that I'll just add selectable logarithmic curving so instead of a choice of 4 curves, there'll be say 7 - three with stronger response near center, then linear, then stronger response at big stick displacements. Won't add much to the code, but I will have to puzzle a bit to find a reasonable discrete-arithmetic way to mimic smooth logarithmic curves - doing real number arithmetic is just too, too slow (and not possible on the Roboteq at all - actually a good choice on their part, keeps people from complaining about non-responsive controllers if they've introduced the molasses of real number arithmetic).
Ciao,
Lenny
P.S. The Roboteq I will eventually buy will, unless new ones come along before then, be the HDC2450, the same one John is using. For it's physical layout, Rachi's present chair is stuck with its MicroMotor in-line brushed motors - very expensive, but compact and pretty efficient for PMDC geared motors. Don't really need anywhere near 150A capability, but that's the one Roboteq has with lots of IO pins and CAN capability (and the price difference from other models isn't all that great given the overall, growing, cost of this project).