Whether this is your first coding experience, or you've already founded four hot tech startups this year, this tutorial is here to help you dive into the fundamentals of programming for the Menlo-Atherton robotics team. This page is intended to guide rookies in the present and in the future (unless no one updates it, of course). However, this page will not go over any of the specific logic implemented in previous years' code bases.
I'd love to start off with some kind of witticism or nugget of wisdom about what robotics is, but the truth is that we tell motors to run to make wheels turn. That's it. Of course, some years may see us add arms or other mechanisms to the robot, but they're all run by motors as well. The complexity comes when we use sensor data to make decisions on how to make those motors run. This might not be up your alley, and that's OK. You could always join one of the mechanical teams, if that sounds more interesting. But take it from a person who spent an entire 6 months trying to make a robot drive in an arc: robotics programming is a very intellectually demanding yet rewarding experience. You would be hard pressed to find a better place for that in high school.
Each year has a new challenge (game) that we have to build a robot for. The general format is an autonomous period in which the drivers are prohibited from directing the robot and it must rely on its own sensors and programming, followed by a longer period where the drivers have control of the robot. Throughout the game, two teams of three robots each attempt to complete tasks to gain score. Below is the explanation of last year's game.
Meetings begin around when school does usually. However, as the game for the year hasn't been released yet, we aren't particularly focused. Between the beginning of the year and kickoff (usually around the start of January), we might design a game for rookies to build a robot for, or simply put them through exercises to build their skills. Meetings are more relaxed and less frequent during this time. Once the year starts, though, it kicks up a notch. Meetings are multiple times a week and require more dedication and focus. As programmers, we get all the basic drive code in place, then start more game-specific projects. These could include making some custom driving method for the drivers, or making autonomous programs. Day to day, we might write some code or work through some problems in old programs, then take the robot out to test and refine them. The specific projects one might work on will vary heavily from year to year, depending on whether we were able to keep the code from the previous year.
As I said, we get sensor data and make the robot take actions based off of that. During the autonomous period, we use cameras, encoders (which track how many times the wheels have rotated), and a gyroscope. During the teleoperated period, we use the driver's inputs in addition to those sensors. The question is, how do we drive the wheels? There are two levels to this. First, how do we make sure that the wheels are outputting an accurate speed when we tell them to (and keep it linear)? Second, how do we make it so the robot drives/moves its appendage to the correct position? After we get those basics down, we then move on to the actual logic to play the game. If the basic drive code does exist, and you don't care about the specifics, then move on to "Getting ready to do work". Otherwise, it's time to learn about PID.
At its most basic, PID is a method to reduce change a number to a setpoint. It is employed in systems that have irregular output that is imperfect in some way. For example, a thermostat told to heat until a certain number of degrees cannot account for the leftover heat in the heating mechanism, which will cause the room to heat slightly further. A PID system would use the error from the setpoint (target temperature - current temperature) and produce an output for the thermostat to act upon. There is an excellent paper explaining the topic in depth here.
The PID controller uses three parts, the proportional, the integral, and the derivative, each of which are a function of the error. It calculates its output by adding up the result of each.
Proportional: The proportional is the main power behind the output. P is proportional to the error. The result is P times error. As you near your target, the error begins to decrease, and so does the proportional value. Essentially, the output lowers as it nears the target.
Integral: Integral takes the total amount of error over time. The result is I times total error. It acts as a booster so the measured error can get to its target faster. It is most important for countering steady-state error, which is essentially when the system is putting out power but it isn't making progress towards the target. (Such as friction holding the robot back).
Derivative: D takes the derivative of the proportional. The result is D times difference in error over difference in time. As P decreases as it nears the target, the derivative has a negative value. This is means that D will be subtracting from P and reducing the overall output. If error is dropping at a very high rate (i.e. the robot is nearing the target at significant speed), D is like "oh no, you're gonna overshoot" and subtracts the output so the robot doesn't put in too much power. The higher P, the higher D, so D is an effective "dampener" for the robot.
Finally, PID outputs all three results added together. When tuning, you want to start with just a P value to see how much power the robot needs to make it to the target quickly. Then, you should add D in order to make sure the robot doesn't overshoot and oscillate too much. Since we want our robot to be fast and efficient, we want P to be as high as possible so the robot gets to its target in the smallest amount of time (WITHOUT BREAKING THE ROBOT)! Make sure to increase D as you increase P so that it reaches the target smoothly. Then, add I (should be a small value!) just in case there is steady-state error. This will make the robot put in even more power, so be ready for that. The document linked above also contains a more precise guide for tuning PID.
An excellent video that explains the concept behind PID, and another good video that explains PID with cars.
We use PID to maintain a constant output from our motors as the input voltage varies, and to maintain a set heading when the wheels or the ground may be uneven, both of which are critical when you need to have precision in the low centimeters.
If you want a consistent and usable development experience, it's best to bring your own computer. Otherwise, you might have to use the fifteen year old laptops that barely work and are incredibly slow. (We're looking into replacing these, but bring your own laptop in the meanwhile. Also, Chromebooks are not acceptable development machines, as they are incapable of installing the necessary software.)
*note: this should be the computer you plan on using for the rest of the year.
What is VSCode? VScode is a code editor. It is where you write and organize the code. Previously, the team used Eclipse, but FRC is switching to VSCode. There is no significant difference.
What is WPILib? The WPI Robotics library (WPILib) is a set of software classes that interfaces with the hardware and software in your FRC robot's control system. There are classes to handle sensors, motor speed controllers, the driver station, and a number of other utility functions such as timing and field management. In simple speak, WPILib defines things for us, such as encoders, gyros, actuators, feedback and anything robotics related so the team doesn't have to waste time defining all those things. Because of the WPILib, we can be like "Make the encoders do X" instead of "you see this? this is an encoder and you make it do X".
What is GitHub Desktop? In theory, we don't really need Github Desktop, but it'll make our lives a lot easier. Essentially, whenever you added/changed something to the code, you'll want to add it to the official 2019 code and you'll do this easily through the Git desktop. This is also how we will make sure we aren't pushing flawed code onto the official 2019 code directly.
Resources: