Drivetrain PID tuning

[thatprogrammer]

Originally Posted by AustinSchuh

Jared probably has a slightly different way of looking at this, but I think there's a more fundamental change needed first to make sure you go straight. The encoder vs gyro problem becomes much easier to try. Instead of left, right profiles, I rewrite it as a distance, angle profile, and then use a distance PID loop and an angle PID loop.

angle = (right_distance - left_distance) / width
distance = (left_distance + right_distance) / 2

You can do a similar transform for your powers (pardon any sign errors) to get back to actual outputs you physically have.

left_voltage = distance_voltage - turn_voltage
right_voltage = distance_voltage + turn_voltage

This then lets you control what you care about.

In the presence of tire slip and tire wear, you won't always go straight with just encoders. A gyro has a different set of issues (noise), but isn't affected by those problems. So, we use the gyro for the angle of the robot instead of computing the angle as above.

Just re-phrasing your loops to be an angle, distance pair of loops has huge benefit. Unless your robot has all it's mass perfectly centered over the two drive wheels, your left, right PID loop won't be able to do good distance control and turn control without compromises. I tend to find that good distance control results in a small amount of turn chatter and oscillation. (You can work out the physics to show that the two sides are coupled in left, right, but not in angle, distance) A angle, distance loop doesn't make that assumption.

If you really want to do left, right with a gyro, you can reverse the equations above.

This post is very useful, but I had a few questions based on it.

1. Assuming that you use your gyro to calculate your angular offset rather than "angle = (right_distance - left_distance) / width." How would you calculate the turn voltage part of the bottom equation?

"left_voltage = distance_voltage - turn_voltage"

Would you just use a full PID loop to calculate a voltage (and tune it) and then just add the result of that to your distance PID loop?

2. Do you have any tips for tuning PID loops in cases with lots of friction like turning PID loops? Jared (very kindly!) sent me some tips on tuning PID loops before, but I'm curious to see if there are other viewpoints on this in situations with lots of friction.

[AustinSchuh]

Originally Posted by thatprogrammer

This post is very useful, but I had a few questions based on it.

1. Assuming that you use your gyro to calculate your angular offset rather than "angle = (right_distance - left_distance) / width." How would you calculate the turn voltage part of the bottom equation?
Would you just use a full PID loop to calculate a voltage (and tune it) and then just add the result of that to your distance PID loop?

Pick your favorite controller. P, PD, PID, LQR, Lead/Lag, MPC, YMMV I try to start with what boils down to a PD loop before I pull out I or any other terms. The input to your controller is the angle, and the output is the voltage.

Originally Posted by thatprogrammer

2. Do you have any tips for tuning PID loops in cases with lots of friction like turning PID loops? Jared (very kindly!) sent me some tips on tuning PID loops before, but I'm curious to see if there are other viewpoints on this in situations with lots of friction.

I've got a bit of a random pile of advice, but hopefully some of it is useful when the robot isn't working right. Sometimes you just need to try different things to figure out what's going wrong.

If you've got a bunch of friction, you end up needing to slow things down a bit. Friction is a pain to deal with. You also need to ask yourself really how accurate you need to be. If you can tolerate moderate steady state error, leave it as a PD loop. As the robot goes faster, it takes less energy to get it to steer, which works in your favor. If you really need good tracking, you are going to have to work at tuning I correctly.

Consider running in low gear if you have a transmission so friction is a smaller portion of your overall torque. The most annoying steering loop I tuned was 254's 2011 robot, geared for crazy speeds. We needed to run auto in high gear too, which meant we were close to saturation all the time.

The most annoying issue I've had tuning heading PID loops was where there was lag in the gyro angle reading. That phase lag meant I couldn't push the bandwidth of the loop up to anything useful. I had to fix that before I could get it to stabilize well. I debugged that by plotting the gyro and encoder headings.

Run your loops at 100 - 200 hz. You want to run your loops at 10x the frequency of the highest frequency you want to control. So, if you want to control at 10 hz, you need a 100 hz loop. The more reliable you can get your loop timing, the better. We go to great lengths to hit a 5 ms +- 5% loop timing, and it helps a lot.

The most important part here is to plot everything. Plot your error vs time, and watch it evolve. Plot the power due to P, I, D, FF. Plot the encoder based heading and the gyro based heading. It's possible but hard to tune these things by eye. Honestly, sometimes I think it's easier to rough tune them by listening to them and listening for the overshoot, and then reaching for the plots when I'm stuck. I also like to grab it and feel the loop, though you have to be very careful since robots can cause lots of damage fast.

We use more complicated controllers, which means I have less recent relevant robot experience than I'd like here. I should probably go grab a robot and tune a PID heading loop again just to have some more guidance.

[SamcFuchs]

Originally Posted by AustinSchuh

The most important part here is to plot everything. Plot your error vs time, and watch it evolve. Plot the power due to P, I, D, FF. Plot the encoder based heading and the gyro based heading. It's possible but hard to tune these things by eye. Honestly, sometimes I think it's easier to rough tune them by listening to them and listening for the overshoot, and then reaching for the plots when I'm stuck. I also like to grab it and feel the loop, though you have to be very careful since robots can cause lots of damage fast.

This is a good point, and I feel it would probably solve a lot of out problems. However, I haven't found a good way to get real time plots from the robot. Do you just use the smartdashboard?

[sspoldi]

Originally Posted by SamcFuchs

This is a good point, and I feel it would probably solve a lot of out problems. However, I haven't found a good way to get real time plots from the robot. Do you just use the smartdashboard?

We like to print to the console and either dump to an excel file or Octave script and do system ID on that.

We've gone almost exclusively to a PI controller for yaw rate for stabilization, since in teleop we're generally commanding yaw rate anyway. In autonomous we just program rate*time for heading changes, the integrator in the controller almost always gets us close enough. We've done heading control with feed forward for more bandwidth, but it was overkill for the particular application we tried it with. One of the first things we do in our gyro service function is to calculate (if necessary) and provide robot heading, and heading rate so that we don't need to derive it in a controller.

BTW, we generally run at 50 Hz, and target around 10 rad/sec for rate bandwith (a little less that 2 Hz). Our recent setups have been giving us around 30 millicesonds of delay between command and robot response, and 10 rad/s is about the point where we have to start to get more creative with a controller. We may try 100 Hz this year, depending on what we need to do.

Cheers,
Steve.

[AustinSchuh]

Originally Posted by SamcFuchs

This is a good point, and I feel it would probably solve a lot of out problems. However, I haven't found a good way to get real time plots from the robot. Do you just use the smartdashboard?

This stuff happens so fast that it's not worth doing it in realtime. Each test is like 2 seconds, so we end up writing scripts to copy the data back and plot it.

This is almost a whole new thread, but it's actually hard to write code that is hard real-time on the roboRIO. Hard real-time means that 100% of the time, your code will finish in X us. That means all your algorithms need to run in constant bounded time, and they can't use any system calls which don't run in constant bounded time either.

This means you need to avoid
- Allocating memory (new, malloc, etc).
- file IO. (It can take an unbounded amount of time for your write system call to complete).
- algorithms which don't take constant execution time.
- Any other operations which aren't constant time.

https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO has some good info on what real-time means. If you are interested in debugging real-time issues, I'm happy to post some more detailed information. I should really do a CD post some time on one of the ones I've found.

For us for logging, this means that we don't log data from our controls thread. We queue it up with a real-time bounded length queue, and write it to a USB stick mounted on the roboRIO from another process. This is a pain, but well worth it.

Another hack I'll use for debugging is to monitor the execution time of the syscalls I care about, (for example, the control loop execution time including logging), and re-run the test if there was a timing violation. This won't be real-time for running during a match where you can't replay if there was a timing violation, but lets you debug something quickly and know when you've affected your test results.

[thatprogrammer]

Originally Posted by AustinSchuh

If you've got a bunch of friction, you end up needing to slow things down a bit. Friction is a pain to deal with. You also need to ask yourself really how accurate you need to be. If you can tolerate moderate steady state error, leave it as a PD loop. As the robot goes faster, it takes less energy to get it to steer, which works in your favor. If you really need good tracking, you are going to have to work at tuning I correctly.

Consider running in low gear if you have a transmission so friction is a smaller portion of your overall torque. The most annoying steering loop I tuned was 254's 2011 robot, geared for crazy speeds. We needed to run auto in high gear too, which meant we were close to saturation all the time

Thanks for this advice! I'll make sure to look into running robots in low gear for turning in auto if needed

Run your loops at 100 - 200 hz. You want to run your loops at 10x the frequency of the highest frequency you want to control. So, if you want to control at 10 hz, you need a 100 hz loop. The more reliable you can get your loop timing, the better. We go to great lengths to hit a 5 ms +- 5% loop timing, and it helps a lot.

On my old team, we used 254's looper code to run every loop we wanted to use closed control on at 5ms. We found this made our intake PD tuning much simpler (we originally couldn't get it to work at 20ms).

The most important part here is to plot everything. Plot your error vs time, and watch it evolve. Plot the power due to P, I, D, FF. Plot the encoder based heading and the gyro based heading. It's possible but hard to tune these things by eye. Honestly, sometimes I think it's easier to rough tune them by listening to them and listening for the overshoot, and then reaching for the plots when I'm stuck. I also like to grab it and feel the loop, though you have to be very careful since robots can cause lots of damage fast.

Considering how fast 971's robots and their mechanism tend to be geared, I hope you lower your gains a lot before you do that