For the past few weeks, I’ve been working feverishly to get PID drive (Joystick-commanded velocity) to work with our given hall-effect sensors. I’m proud to say that we’ve got our first working prototype.
It required a complete rewrite of the algorithm… I expanded the generic PID algorithm, and got an expression for delta-output based on the current error and the last error (Proportional+Integral only). I did get another equation for the derivative band, but it required too many multiplications – saturating processor time for no good reason.
I also got rid of the whole structure’s / OOP’ness of the NASA code (sorry guys!)… At one point, I seemed to get a bit of memory corruption (printf started spitting out RANDOM garbage, then code error). As a result, the code is much lighter now!
To stabilize the system, I added PWM sloping protection. This forces the controller to only change the PWM output from cycle-to-cycle by +/- 1. Sort of like a dampener, but with much less calculation. The hall-effect sensors that we mounted could only get ~ 35 ticks/loop, so the resolution was quite low, causing major overshooting/undershooting from loop to loop. The PWM sloping seemed to have corrected this.
Problems:
Still need to test. Haven’t tested under all conditions yet.
Direction. Assuming direction based on commanded PWM direction seems quite effective, but I’m still seeing if there’s a weakness.
After I send this through some internal testing, I plan to GPL and release our Default_Routine() function.
Seems only natural for you to put in Jim Zondag’s (Killer Bees, Team #33) auto shifting alorithm. Once you take the human out of the throttle control business, it seems a natural to have the velocity control figure out what gear is best.
It is a pretty simple calculation to figure out if you would be more power efficient to be in another gear.
Knowing speed and voltage, you can calculate torque on the motor and the efficiency of the motor at that speed, voltage and torque at converting VI power into Tw power
Knowing this, you can calculate the voltage and associated effieciency that would be needed in the other possible gears at that same tire speed and tire torque load point
If it is more efficient to be in another gear and you have not shifted too recently, then shift to the more efficient gear
Anyway, thanks for what you have done so far. I applaud your efforts.
I prefer BSD for my stuff, but LGPL works as well for this purpose.
With the LGPL, if somebody changes your library and gives it to somebody else, they must also give the changed code. If it’s BSD, they can make any changes, and distribute or not distribute, but your name will always stay with it.
I prefer BSD as it is more free, but others prefer to force people to release changes, in that case, LGPL is what you want.
Sorry for the delays, ran into a few snags the past two weeks.
The balance between stability at low speeds and fast responses at high errors is extremely frustrating and time-consuming to find.
Right now, I’ve broken the algorithm into Low, High, and Overdrive modes.
Low uses small Kp/Ki (1 or 2), with a PWM limit of +/- 1 per loop. High uses a higher constant with a larger slope. Overdrive is engaged if the joy is pushed past a certain point, and switches to max PWM output.
I plan on releasing this code next week, likely under the BSD license.