The basic idea for PID is that it corrects for errors. if you make a PID loop based on position, it will move your motors such that the position is what you want. you can replace the word position with the words velocity, angle, and even acceleration or motor current. you can also loop multiple parts of your motion. (i.e. Loop position and velocity), but for FIRST, you usually only need to put a loop around one thing.

Let’s use position for discussion, which is easiest to visualize. First, you need a way to measure your position (an encoder can be used for position or velocity, the gyro or an accelerometer can measure angular data.). The difference between the position you are in, and the position you want to be in, is your error. PID acts on this error to try and make it 0.

In a typical machine tool (like a CNC machine (Hey look, FIRST applies to the real world )), you want to position an axis. Say the axis is currently at zero, and you want to move it a meter. Your commanded position is 1m, and your actual is 0m, making your error +1m. (The sign is important!). Proportional Gain is a number we multiply by the error to get a motor command. Sometimes this is a speed (engineering unis such as m/s), or in our case, it is a motor command in the range of -1 to +1. Let’s say our proportional gain is 0.5. 0.5(gain)*1m(error) = 0.5(command), which moves our motor towards where it is supposed to go.

For the sake of discussion, let’s say our motor is geared such that a command of 1 means the mechanism in question is moving at 1m/s. That is also the top speed of the motion, since the command cannot be greater than 1.

PID loops execute repeatedly in your Periodic tasks, so they occur with a fixed time base. To demonstrate, I’ve put this together as an excel worksheet, and posted it to here -> PID worksheet. The sheet lets you play with some different PID settings, and lets you look at how the mechanism will move based on the commanded velocity. It’s not taking friction or even acceleration into account, but it gives the basic idea of how PID works.

The D (derivative) gain is applied to the difference between the error last cycle, and this cycle. It can be used to slow down the movement if it is approaching the target to quickly.

Integral Gain (I) is applied to the total sum of all errors. It is common to not accumulate errors if the error is too large, or to limit the accumulation to a certain value, or to clear out the accumulator when you are in position. The job of I is to take care of small position errors that occur when the P gain alone is not enough to overcome friction or some other limiting mechanical feature.

The sum of the P I and D values are added together to create the motor command. The gains have to be tuned to get the response you want. If P I or D are too large, the system will oscillate. If the signs are wrong, the system will run away. If I is not controlled a bit, it can overshoot significantly. Most FIRST mechanisms work just fine using P, PI, or PD modes. P mode means that I and D gains are 0. PD means I is 0, and PI means that D is 0.

PID does not always need to be reactive. In general terms, there is a further thing you can add called FeedForward, which you can apply to either velocity or acceleration, as the case may be. The basic idea with Feedforward is that you know you’ll be moving in a certain direction anyway, so give a little boost to your velocity or acceleration, then let the rest of PID react once you get going. You can see this on the second sheet of the workbook.

If you have any questions, please post a comment!

I also noticed that the macro section assumed the ball launched from 36″ off the floor (set on the third sheet), so I changed it to take the h_0 setting from the top of the first page, so all charts assume the same launch height.

Here’s the updated spreadsheet:shot simulation (macro)

The biggest thing to keep in mind is that there is still no Drag (Air resistance) or Magnus effect (increased range due to backspin). I’m hoping the two effects somewhat cancel each other out, but they will both be significant in the real world.

I made a spreadsheet to help with planning a shooting mechanism, and to help with testing or writing code.

The spreadsheet is broken up into different sections. The first section has the basic parameters to calculate what velocity is needed for a given set of shot parameters. Set the cells that are green to your values, and the first orange boxes will show the velocity needed for each of the three hoop levels. If the angle of the ball entering the hoop is too shallow, the box will turn red. The h0 (robot shooter height) parameter is used for all the sections, so make sure you set this accurately before going down to the other sections.

The next section calculates a the velocity needed for a variety of shooting angles for a given range. This does not check to see if the shot is too shallow. The first section can be used to look at any individual shot to see if it passes the shallowness test. There is an inverted chart off to the right that swaps the X and Y axes, which gives a different view of the data. The left chart can be used to find a desired velocity for a given range and angle, where the right chart can help you choose an angle to go with your known velocity.

The next section is useful for robots with a fixed shooting angle. It calculates the velocity needed to make baskets at a variety of ranges. There is an inverted chart off to the right that swaps the X and Y axes, which gives a different view of the data. The left chart can be used to find a desired velocity, while the right chart can be used to see what range you’d get out of your current velocity.

The last section is only in the macro version of the spreadsheet. It is designed for robots with a fixed firing velocity (such as a pneumatic launcher). It calculates (using an iteration macro) the needed angle of launch for a fixed velocity and a variety of ranges.

The most useful part of this is for estimating a formula to use in the robot code. The math itself is non-trivial to rearrange.

Hopefully this spreadsheet is useful to other teams, so I am posting them here. shot simulation (macro)

shot simulation (no macro)

Please let me know what you think below

UPDATE (10AM): I added some trendlines to the last graph in the macro version. Now you can specify what range to look at and it will give you a cubic formula for a trendline for each hoop. The trendline will get messed up if you don’t have enough velocity to make the range (blank results in the orange boxes). if you ever get an error message (if the macro fails to find a result), you may have to go to sheet 3 and change cells in the B10 to D22 range to 89 to get it working again. Basically, if the GoalSeek Function can’t find a result, it can make an error pop up. I try to prevent the most common errors, but asking for longer ranges is more likely to have issues.

Be sure to check results back up in the first section to make sure the angles are still valid. The first section can also be used for checking the human player parameters needed to make a shot. set the range to 54 or 56 feet, set the angle high enough to clear the 8 foot alliance wall, and then see what sorts of velocities are needed to make the shot.

UPDATE (10:10AM): I fixed a bug with the entry angle lookup code.
UPDATE (10:40AM): I added the height of the apex of the curve to section 1.