Subject:
|
2-wheelers
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 31 Dec 2004 23:53:52 GMT
|
Original-From:
|
dan miller <danbmil99@yahoo#nomorespam#.com>
|
Viewed:
|
706 times
|
| |
|
|
I don't know if anyone cares about this, but -- I think I figured out something about Legway-type
bots and the software that drives them.
The puzzle is: why do some versions need a full PID controller (Proportional-Derivative Integral
feedback), where Steve H's original program is a very simple algorithm that sets the motor speed
value equal to the difference between the present light reading and an optimal, balanced reading?
Another question I had about legway.c is, why did he write his own PWM routine instead of using
the built-in motor_x_speed() functions? (he sets speed to 255 once at the top of the program).
Ok, here's my theory: in his PWM routine, Steve alternately sets the motors to full drive, and
brake. The PWM routines in the brickOS kernel, however, alternate between full voltage and float
(I'm 99% sure of this..). This is a crucial difference. By braking the motor between pulses,
Steve's code should have the effect of correlating motor setting to velocity. (The motors move a
bit, then stop; they don't have a chance to build up much momentum.) The brickOS PWM routines, on
the other hand, will tend to be setting *torque*, not speed, in the motors -- in other words,
acceleration. These correlations will be strongest at the lower settings, where the specifics of
the feedback routines are most important. (at lower speeds, the brake or float is a higher
proportion of the duty cycle.)
So the reason we need a derivative term in our controllers, and Hassenplug's version doesn't, is
because we are tweaking acceleration, which is the derivative of velocity, where his code is
tweaking velocity directly! So it makes sense that we would want to set acceleration to a
proportion of the error in velocity, which is the first derivative of the error in position -- the
difference between error in this time step and the previous one. Steve's code, by virtue of his
braking PWM routine, sets velocity to a proportion of the error in position, ie the raw light
reading.
Just thought this was an interesting observation. I think the practical effect is, his way is
more robust; but a full PID controller, while a bit harder to calibrate, should have a smoother,
more stable operation (due to the fact that we're not jerking the motors with braking all the
time).
Oh, and another thing -- Steve runs his loop at 1MS, and the code I'm using waits 20 ms between corrections!
|
|
Message has 1 Reply:
 | | Re: 2-wheelers
|
| (...) I think another huge difference (for me at least) is that Steve's code learns where the upright position is, while most of the others need to be put down in the correct position. (That is what the piece of code does in the 50ms if()). John (20 years ago, 1-Jan-05, to lugnet.robotics)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
