Fundamentals of Autos

In autonomous routines, the robot is driving by itself and running different tasks without any teleoperated control. Often times in games, you’ll be given different objectives that you need to complete in both teleop and auto. For example, in this year’s game (Crescendo), robots are given the task of shooting notes (orange discs) into a speaker (an elevated opening above the field) and the amp (a flat chute).

This means that during autonomous routines, you have to control the superstructure of the robot (different parts of the robot, like the wrist on this year’s robot to get it to the right setpoint so it can accurately shoot the note into the speaker) and command it to drive to different parts of the field.

Trajectories

One word that you’ll see come up a lot when working with autonomous routines are trajectories. Lots of tools exist already to generate trajectories for the robot to follow, and trajectories are a higher-level way of understanding the path that the robot has to follow during the autonomous routine.

    Example of a trajectory in PathPlanner

When generating trajectories, you’ll usually see splines generated which are sets of curves that interpolate between points (which are chosen by the programmers). Splines are great for trajectories because their change in curvature is continuous, meaning that the trajectories won’t be jerky and suddenly change headings to the point that the robots aren’t able to reach those targets in time.

Some tools that are often used to generate these trajectories are:

• WPILIB’s native trajectory generator
  • Pros: Easy to access since it’s native to WPILIB, great for on-the-fly paths since it’s onboard the robot
  • Cons: Relatively ancient (made for tank robots, though most robots are swerve nowadays) and hard to create autos based off the trajectory generator since you need some sort of GUI to determine what waypoints you want the robot to hit.
• Pathplanner
  • Pros: Accessible GUI that lets you see what waypoints you want the robot to hit, lets you control the specifics of the path (like changing the curvature of the path to avoid obstacles)
  • Cons: Requires you to enter metrics like the maximum angular velocity of your robot which is susceptible to human error, can generate paths that are impossible for your robot to actually reach.
• Choreo
  • Pros: Takes in different metrics of your robot (like moment of inertia, weight, the gear ratios that your swerve modules use) to calculate the physical limitations of your robot and generates the most optimal trajectory for your robot based on those physical limitations.
  • Cons: Not as easily accessible as the other two tools

Applying These Trajectories

Now that you know the tools used to generate trajectories that the robot is expected to follow and what trajectories actually are, you might be wondering how you convert these trajectories into actual instructions that the robot is expected to follow.

All of the tools that generate these trajectories also process these trajectories into individual “states” or sequential steps that the robot is given to follow the path. These states are sampled from the trajectory at a certain point in time (like 0.5 seconds after the robot starts following the trajectory) to determine the expected state at that point in time in the calculated trajectory that the robot is expected to be at. Then, the state is processed into a closed loop request which is then sent to the drivetrain to convert the chassis speeds and accelerations into instructions for the swerve modules to follow.

If you want to see the code for this process of converting the time elapsed since the trajectory following started to states for the robot to follow, check out the code for it in DrivePathCommand.kt in our codebase.

Example of making a closed loop request to drivetrain from the current time elapsed since the robot started following the trajectory