Step 4: Creating and Following a Trajectory¶
With our drive subsystem written, it is now time to generate a trajectory and write an autonomous command to follow it.
As per the standard command-based project structure, we will do this in the
getAutonomousCommand method of the
RobotContainer class. The full method from the RamseteCommand Example Project (Java, C++) can be seen below. The rest of the article will break down the different parts of the method in more detail.
Configuring the Trajectory Constraints¶
First, we must set some configuration parameters for the trajectory which will ensure that the generated trajectory is followable.
Creating a Voltage Constraint¶
The first piece of configuration we will need is a voltage constraint. This will ensure that the generated trajectory never commands the robot to go faster than it is capable of achieving with the given voltage supply:
Notice that we set the maximum voltage to 10V, rather than the nominal battery voltage of 12V. This gives us some “headroom” to deal with “voltage sag” during operation.
Creating the Configuration¶
Now that we have our voltage constraint, we can create our
TrajectoryConfig instance, which wraps together all of our path constraints:
Generating the Trajectory¶
With our trajectory configuration in hand, we are now ready to generate our trajectory. For this example, we will be generating a “clamped cubic” trajectory - this means we will specify full robot poses at the endpoints, and positions only for interior waypoints (also known as “knot points”). As elsewhere, all distances are in meters.
Instead of generating the trajectory on the roboRIO as outlined above, one can also import a PathWeaver JSON.
Creating the RamseteCommand¶
It is very important that the initial robot pose match the first pose in the trajectory. For the purposes of our example, the robot will be reliably starting at a position of
(0,0) with a heading of
0. In actual use, however, it is probably not desirable to base your coordinate system on the robot position, and so the starting position for both the robot and the trajectory should be set to some other value. If you wish to use a trajectory that has been defined in robot-centric coordinates in such a situation, you can transform it to be relative to the robot’s current pose using the
For more information about transforming trajectories, see here.
This declaration is fairly substantial, so we’ll go through it argument-by-argument:
The trajectory: This is the trajectory to be followed; accordingly, we pass the command the trajectory we just constructed in our earlier steps.
The pose supplier: This is a method reference (or lambda) to the drive subsystem method that returns the pose. The RAMSETE controller needs the current pose measurement to determine the required wheel outputs.
The RAMSETE controller: This is the
RamseteControllerobject (Java, C++) that will perform the path-following computation that translates the current measured pose and trajectory state into a chassis speed setpoint.
The drive feedforward: This is a
SimpleMotorFeedforwardobject (Java, C++) that will automatically perform the correct feedforward calculation with the feedforward gains (
kA) that we obtained from the drive characterization tool.
The wheel speed supplier: This is a method reference (or lambda) to the drive subsystem method that returns the wheel speeds
The output consumer: This is a method reference (or lambda) to the drive subsystem method that passes the voltage outputs to the drive motors.
The robot drive: This is the drive subsystem itself, included to ensure the command does not operate on the drive at the same time as any other command that uses the drive.
Finally, note that we append a final “stop” command in sequence after the path-following command, to ensure that the robot stops moving at the end of the trajectory.
If all has gone well, your robot’s autonomous routine should look something like this: