Pedro Pathing

Pedro Pathing turns a route made from field poses into drivetrain commands. A pose means “where the robot is, and which way it faces.” Pedro updates that estimate through a localizer while its follower tries to move along the path.

This lesson uses one short, straight route. It explains each piece before combining them, so you can check the coordinates and understand what each call asks Pedro to do.

Pedro version

This page follows the current Pedro 3 API. Pedro 2 tutorials use different packages and path classes; do not mix their code with Pedro 3. The official Quickstart provides the drive motors, localizer, tuning constants, and project setup that a follower needs. Complete that setup for your drivetrain before using the path examples below.

1. Start from the official Pedro Quickstart or follow the current setup guide.
2. Complete its tuning steps for your actual drive base and localizer.
3. Confirm the project compiles and the localizer reports believable motion before you ask the robot to follow a path.

Start and end poses

Pedro's field coordinates use inches: X increases to the right, Y increases up, and a heading of 0° points along +X. Positive heading turns counterclockwise. These conventions differ from FTC's usual field coordinate convention, so do not copy FTC field coordinates directly into Pedro without converting them.

For a first test, keep both poses on the same horizontal line. The robot starts at (24, 24) facing right, then travels to (48, 24) and keeps facing right:

PoseFactory poseFactory = PoseFactory.degrees();
Pose start = poseFactory.of(24, 24, 0);
Pose park = poseFactory.of(48, 24, 0);

val poseFactory = PoseFactory.degrees()
val start = poseFactory.of(24.0, 24.0, 0.0)
val park = poseFactory.of(48.0, 24.0, 0.0)

PoseFactory.degrees() means the heading values you pass in are degrees. Pedro's live pose reports heading in radians, so convert it with Math.toDegrees() when you display it to a person.

Before you write the path, point at each mark on the diagram and say its X, Y, and heading. If the start pose does not match where you physically place the robot, the follower begins with the wrong answer about where it is.

Follower setup

The follower needs your project's hardware configuration, localizer, and Pedro constants. In the official Quickstart, its Constants helper builds that robot-specific follower. Constants is a class in the Quickstart project—not a method you get automatically by importing Pedro.

Create it in your autonomous OpMode's initialization code, then tell it where you placed the robot:

Follower follower = Constants.create(hardwareMap);
follower.setPose(start);

val follower = Constants.create(hardwareMap)
follower.setPose(start)

setPose(start) initializes Pedro's estimate; it does not move the robot to that spot. Place the robot at the matching location and heading on the field. Then test localization by pushing or turning the robot by hand and watching Pedro's reported pose change in the expected direction.

Path construction

Now that both ends are defined, ask Pedro for a straight line. The .linear(start, park) part tells Pedro to interpolate the robot's heading from the first pose's heading to the last pose's heading while it travels:

Path firstPath = line(start, park)
    .linear(start, park);

val firstPath = line(start, park)
    .linear(start, park)

Both headings in this example are 0°, so the robot travels along the drawn line while continuing to face right. A curved path needs control points and different geometry; learn this straight path before adding those parts.

Follower updates

For a LinearOpMode, start only after checking the robot's placement. Once the match starts, give Pedro repeated updates while the path is active. Each update reads localization and calculates the next drive output:

telemetry.addLine("Check that the robot is at the marked start pose.");
telemetry.update();
waitForStart();
if (!opModeIsActive()) return;

try {
    long pathStart = System.nanoTime();
    follower.follow(firstPath);
    while (opModeIsActive() && follower.isBusy()
            && (System.nanoTime() - pathStart) / 1e9 < 6.0) {
        follower.update();
        telemetry.addData("X", "%.1f", follower.pose().x());
        telemetry.addData("Y", "%.1f", follower.pose().y());
        telemetry.addData("Heading (deg)", "%.1f",
            Math.toDegrees(follower.pose().heading()));
        telemetry.update();
        idle();
    }
} finally {
    follower.stop();
    follower.update();
}

telemetry.addLine("Check that the robot is at the marked start pose.")
telemetry.update()
waitForStart()
if (!opModeIsActive()) return

try {
    val pathStart = System.nanoTime()
    follower.follow(firstPath)
    while (opModeIsActive() && follower.isBusy() &&
        (System.nanoTime() - pathStart) / 1e9 < 6.0) {
        follower.update()
        telemetry.addData("X", "%.1f", follower.pose().x())
        telemetry.addData("Y", "%.1f", follower.pose().y())
        telemetry.addData("Heading (deg)", "%.1f",
            Math.toDegrees(follower.pose().heading()))
        telemetry.update()
        idle()
    }
} finally {
    follower.stop()
    follower.update()
}

These fragments use Pedro 3.0.1. Complete the Quickstart hardware and localizer setup first: its initial Constants.create() skeleton must return a configured follower, not null. Imports for the path fragments are com.pedropathing.api.PoseFactory, com.pedropathing.follower.Follower, com.pedropathing.math.Pose, com.pedropathing.paths.Path, your project’s pedro.Constants, and Java’s static com.pedropathing.api.Paths.line (Kotlin imports com.pedropathing.api.Paths.line).

The six-second timeout is an example test bound. Measure an appropriate deadline and configure low drivetrain limits using your installed Quickstart. In Pedro 3.0.1, stop() switches to IDLE and the following update() writes zero drive output. isBusy() becoming false alone does not guarantee zero power because a path may hold its endpoint.

follow() starts the path. isBusy() is the follower's “still working?” check. update() must run repeatedly; calling follow() once without updates does not make the robot complete the route. The loop also checks the OpMode state so it stops when the Driver Station requests a stop.

Path testing

1. Run the first test with the robot lifted or with the drive output disabled, and confirm the localizer moves in the right direction.
2. Put the robot on a clear practice floor and use a short, slow path.
3. Compare Pedro's X/Y telemetry with where the robot actually ended.
4. If it misses, check the start pose, motor directions, localizer setup, and Pedro tuning before changing the destination coordinates.
5. Only after the first path is repeatable should you add a second path, a curve, or a mechanism action.

Pedro does not automatically know the real position if the wheels slip or the localizer is misconfigured. A smooth-looking path on screen is not proof that the real robot will travel safely or accurately. Keep a clear test area and a stop plan.

Next steps

• Motion planning explains how to choose and sequence autonomous goals before implementing them.