FIRST Robotics Competition C++ Programming Overview [Resources] [Mind Map]

Hey all,

Been working on this for a couple hours now, it contains a whole bunch of C++ tips and resources for new teams in mind map form (everything’s in one place). I will continue to update and add to it.

http://mmrambotics.ca/static/FIRST_Robotics_Competition_C++_Programming.pdf

Nice. Can you comment on why you prefer to implement your own PID classes. What are the disadvantages of the WPILib PIDController class in your opinion? What are the advantages of the classes you have come up with?

Writing your own allows students to learn PID concepts vs. plopping in an object and just fiddling with constants. Plus it offers more flexibility and integration with your program without re-compiling the WPI library.

Ok, good to know there are any serious problems since we are using the built-in objects. And plopping them in and fiddling was still plenty of work for us to get it working nicely but I can respect rolling your own. I do have one possible issue with the WPILib implementation however. It does not take into account the dt (loop interval time) when calculating integral and deriviative errors. You can get around it by adjusting your calculated (if you calculated them) Ki and Kd values according to your loop rate but since the PIDController object already knows the dt you set I think it probably should take it into account. Below is some pseudocode from wikipedia http://en.wikipedia.org/wiki/PID_controller that illustrates how the dt could be taken into account. I would be interested in the experts opinion on this and I’ve been thinking it might be worth submitting an issue on the FirstForge page.

previous_error = 0
integral = 0
start:
  error = setpoint - actual_position
  integral = integral + (error*dt)
  derivative = (error - previous_error)/dt
  output = (Kp*error) + (Ki*integral) + (Kd*derivative)
  previous_error = error
  wait(dt)
  goto start

We have our own PID library as well. In our case, aside from the benefits you mentioned, our PID library allows multiple PID controllers to interact. In particular, we defined a PIDDrive object where it takes two PID controllers, one for driving straight and one for turning. Each PID controller can have their own sensors (e.g. driving straight can use the wheel encoders or sonar sensors etc., turning can use the gyro, the compass or the camera etc). Imagine if you can tell the PIDDrive object to “drive forward 20 ft while maintaining heading to the goal seen by the camera”. The drive PID controller will calculate the motor values to drive forward 20 ft while the turn PID controller will calculate the motor differential for maintaining the heading. The result from these PID controllers can be combined to generate the final motor values. The PID drive object is extremely flexible, you can tell it to follow a moving object and maintain distance. For example, drive forward and maintain 30-inch distance from the object in front. It can use the sonar sensor for the driving PID controller for setting the 30-inch target while using the camera as the sensor for the turning PID controller to follow the object in front. At first, we were trying to implement this with the WPI PID controller but found that it doesn’t have the flexibility. So we wrote our own replacement.