Robot Tracking on the field

[NoMercy]

For next year our team is looking into how to track the robot on the field/and moving it to a specific point on the field for better accuracy and precision. I have seen various sources talking about PID, Odometry, and Encoders, for tracking a robot and sending it to a particular location, all of this super confusing. So can anybody clarify how can we track our robot on the field and send it to precise locations

— Edit Totally forgot to mention that we are an FTC team, so does that change any of your answers or can we still apply the concepts you metioned

[gerthworm]

In a very high-level mental model of the world, There’s three main components:

1. Calculating where you think you’re at
2. Calculating where you want to be at
3. Figuring out how to power motors to get you from where you’re at, to where you want to be.

Each can be done in a variety of simple and complex ways. Many of the techniques you mentioned do multiple simultaneously, hence probably part of your confusion.

Where You Are

As there is no sensor that directly measures your X/Y position on the field, #1 is done by taking readings from encoders and gyroscopes, along with some assumptions about the physical dimensions and behavior of the robot, and applies math to derive an estimate of the X/Y position. Buzzwords in this field include “Odometry”, “Pose”, “Twist”, “Kinematics”, “Kalman FIlter”, and many others.

Where You Want to Be

#2 involves writing code that can, at any given time, tell you where you want the robot to be at. Often this involves inputting a series of timestamped X, Y, and angle samples. In-between values are usually calculated by interpolation. Additional constraints on the maximum speed and acceleration of your drive-train may also be used. Calculus is used to determine the velocities and accelerations experienced by different parts of the robot throughout the maneuver. “Pathplanning” is the most common buzzword in this area.

Gettin’ There

#3 is also very math-heavy. Basically, you have to design some logic that takes the number from #2, and calculates how to power the motors to achieve the position (using #1 as additional input). “Ramaste”, “PID”, “Control Theory” are some of the buzzwords here.

The Honest Truth

With very few exception, not many FRC teams dig into much depth here. You don’t need to understand things fully to get to the end result.

On our team, we shortcut by not bothering calculating X/Y position from #1. Instead, we modify #2 to produce velocity commands for each side of the drivetrain. Then, we use PID features in motor controllers to cause each side of the drivetrain to move at that commanded velocity. We cross our fingers that it works “good enough”. Also, we try to design in mechanical alignment points (fancy way to say “drive into the wall”).

For the next level up, and what I hope we can do next year, the WPI libraries this year had a quantum leap forward in supporting the important parts of all of #1, #2, and #3 together internally, and with a tutorial if you’re starting from scratch, start there. Google words you don’t know and ask here if you’re confused. @Oblarg is remarkably responsive usually.

[aprxlycalculus]

The simplest way to find your position on the field is odometry, like you said. The basic gist of it is that every cycle of the robot’s code, you update your position given changes in encoder values. For example, your encoders report that you moved 2 centimeters, you can update the estimated position by 2 centimeters in the direction reported by your IMU or gyroscope. WPI has some great and intuitive Odometry classes for different types of drive trains. It does require precisely knowing your initial position on the field. Any error will accumulate over time.

If you don’t know it very precisely, there are other things you can do. For example, you can use a solvePnP with camera data to find the robot’s position relative to a target. You can also use a LIDAR and extrapolate your position on the field given its point cloud. There’s also a really fancy algorithm for finding the robot’s position called the Kalman Filter that can take all the data you provide it with, along with descriptions of how reliable the sensors are, to figure out the robot’s position. But if you’re getting started with localization, odometry is by far the simplest and most reliable, at least for a 15 second auto assuming your drive team can place the robot accurately on the field with respect to where you’re expecting it to be.

Once you know your position, you can use that to help correct the robot to where you want it to be. Again, WPI has some great documentation on trajectories and RAMSETE controllers. RAMSETE is a way to correct for errors while your robot is driving in a trajectory. It outputs velocities for your motors, which you use PID for in order to command