PID Control

[gnormhurst]

I spent a lot of time tweaking that code. I wanted to use it in manual drive mode, but it wasn't responsive enough (when you let go of the stick it kept going, for example). Our manual drive is back to open loop.

For auton, there is a fundamental problem with the code as is, and I have written about it elsewhere. The S_DRIVE thing sets the position target at the final goal and lets the PID system chase it. This leads to the motor drive values being pegged at their max, so small hanges can't get to the motors, so the loop is not closed -- it's open.

This means that both motors will push as hard as they can, but if one goes faster than the other, there is nothing the PID system can do about it until it gets closer to the goal, so it tends to turn in a circle.

I modified this so that I increment the PID target position a little bit each cycle, and not so much that the system ever pegs (clips). This keeps the loop closed and the robot driving straight. Well, sort of. To get it to really drive straight you need to have an integration term on the error, but that always made it unstable.

I ended up calculating the heading error (difference between wheel counts) and running an outer loop to maintain a zero heading error. I used an integrator on this outer loop, and I got it to be fairly stable.


Related subject: We have an arm that is driven by the van door motor, and a pot to measure its absolute position. I had hoped to just run the motor until the arm got to the desired position, but even though it is geared down twice from the output of the motor, when the arm is loaded it can still back drive the motor, even with the Victor set to "brake" mode.

My solution was to make an always-on arm servo. It sagged when we loaded the arm up so I tried to add integration to that loop to compensate, but it always oscillated. I decided that I was measuring position and controlling the motor's speed, which are an integration apart (position is the speed integrated). Integration carries with it a 90 degree phase shift at all frequencies (integ(cos) = sin, for example). My additional integration added another 90 degrees for a total of 180 degrees which reverses the feedback at all frequencies: guaranteed oscillation.

I got rid of the integrator and just increased the loop gain until the arm didn't sag as much. Works good!

There was also an issue of stiction in the arm drive train: applying increasing amounts of voltage to the motor did not move the motor until the static friction (stiction) in the drive train was overcome, but then the voltage was too high for what we wanted. I thought about popping the motor with big, short pulses to break the stiction, but I never tried it.

-norm

[Tom Saxton]

Originally Posted by gnormhurst

For auton, there is a fundamental problem with the code as is, and I have written about it elsewhere. The S_DRIVE thing sets the position target at the final goal and lets the PID system chase it. This leads to the motor drive values being pegged at their max, so small hanges can't get to the motors, so the loop is not closed -- it's open.

This means that both motors will push as hard as they can, but if one goes faster than the other, there is nothing the PID system can do about it until it gets closer to the goal, so it tends to turn in a circle.

For autonomous, what you want to do is run it in velocity mode to drive both sides at the same speed, then manually monitor encoder ticks until one or both sides reach the target.

We had really good results using the PID code in position mode to control arm segments. We can command a position and have it hold pretty well even when adding or removing a tetra. It would sag a little, but not enough to drop the tetra if it started with some backwards tilt. The only problem we had was integration wind-up when we requested a large movement. I've since read about that issue - there are easy solutions like zeroing the integration term until the arm gets close to the target position.

[dm0ney]

We used the 'kit' pid code for the first regional. Since then, we have migrated back to pid code written last year by our team. The switch is very easy as we have macroed 'KIT_PID.'

We only used the position loop during autonomous and we also split gains and max/min for rotate and drive.

The pid code was quite easy to tune for linear distances but until we split gains, we had a heck of a time getting spins with the same gains.

The reason we abandoned the kit pid code was eventually a robot will not drive straight (assuming it drove straight to begin with). Last year we had implemented 'go straight' code that would compensate for mechanical imperfections by engaging encoder counts and running it through pid. We tried implementing this into the new code but decided that since we already had code that works, it wasnt worth rewriting it and inserted the macros instead.