Drivetrain PID tuning

[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.

[Ether]

Originally Posted by Jaci

float gyro_heading = ... your gyro code ...
float desired_heading = get_heading(time, profile);
float delta_angle = desired_heading - gyro_heading; // This is our error in alignment
float turn_power = 0.8 * (-1/80) * delta_angle;   // Change these coefficients as required...

It might be helpful to slightly modify one line of code:

float delta_angle = desired_heading - gyro_heading; // This is our error in alignment

float delta_angle = MATH.IEEEremainder(desired_heading - gyro_heading,360); // This is our error in alignment


https://www.chiefdelphi.com/forums/s...3&postcount=36
https://msdn.microsoft.com/en-us/lib...vs.110%29.aspx
http://en.cppreference.com/w/cpp/numeric/math/remainder

[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