This is part of a series of posts called
Drinking From The Firehose on getting Dr Joe back up to speed on All Things FIRST.
Which led to this post:
Jags v. Vics
Which led to this post:
We eat what we CAN, and what we can't, we CAN...
Which led to today's topic:
Closing the loop on Wheel Velocity...
I have never done this in a FIRST robot, but my background in controls, everything I have read, and my gut tells me that wheels should be driven in closed loop mode (not open loop mode, i.e. set a PWM value) AND that the closed loop should be based on velocity not position (well, I lied. It should use position but only in autonomous mode and even then a fast acting velocity loop should be then wrapped in a relatively slow acting position loop).
Drivers should command wheel velocities not motor voltages.
So... ...has anyone done this?
Barello.net has some great info on the subject (read
here)
Here are my questions:
If you read the reference Barello likes (
Mobile Robots, from Inspiration to Implementation) they basically only have a P (Proportional) control on velocity. They use an I (Integral) term but it is only integrating (i.e. adding up) the relative error between the right and left sides. Which I think is probably better implemented using a gyro (i.e. an angular rate sensor).
Comments welcome.
Has anyone used a Jaguar to close the velocity loop? The standard PID modes do not support this which is a shame (you can input an encoder but the PID loop is then based on position of the encoders not speed). This should be a relatively easy code change to implement but I don't think we are allowed to muck with the firmware for the Jaguars and still be FIRST legal so...
...I have another idea. I think that the performance of the velocity control would be much enhanced by a fast PID such as the 1000hz loop time that I have heard that the Jaguars use in PID mode. So... here is my scheme....
What if I had an Arduino (or any micro, pick your favorite) monitor encoders from the RH & LH wheels and then generated with an ADC corresponding RH and LH voltages for each side that ranged between 0-3V (top speed in rev = 0 volts, top speed in fwd = 3 volts). THEN we fed these voltages to the analog input of the RH and LH Jaguars. THEN we put the Jaguar in PID mode.
In effect, as long as the Arduino provided fast enough and faithful enough updates to the Jaguars, we would be able to take advantage of that 1000hz update rate -- this is a big if because we would need velocity updates at over 1000hz which rule out encoders I think because at slow robot speeds (<1 fps), you would still need over 1000 pulses per second or more than 100 pulses per inch. Not impossible but tough. I think it may be better to use a continuous rotation magnetic encoder. I think it would be possible to get updates fast enough.
The next problem I worry about if I tried this is that the Jaguars would fight each other. If each Jaguar is doing its own PID loop internal, then I can envision a world in which the Jaguars are fighting each other (imagine if the integral error terms start going in different directions - cancelling each other out in the net, but wasting energy and heating my motors all the while).
So... ...after all that, I don't really think independent PIDs are a viable solution for multimotor drive systems. Unless you can go with a PD control (leaving out the I, which has the most potential to get you into trouble -- and really to we care about driving steady state error
in velocity to zero? Maybe not. We would want to make corrections to go straight but that could be done by mucking with the set points without having to have an integral term... )
Thoughts?
The other option is to do things the old fashion way, inside the cRio. With one coordinated output to multiple Jaguars (or Victors) the fighting problem is solved, but not I don't have my 1000hz feedback loop.
From what I hear, you can get a 200hz update rate via PWMs using the cRio.
Is that fast enough? I don't know. Do you?
Joe J.