The part the other path libraries can't do
It runs entirely in OnBotJava.
Pedro Pathing's own docs say it does not work in OnBotJava. Road Runner is built for Android Studio. If your team codes in a browser on a school laptop, path following has effectively been closed to you — that is the specific problem this library exists to solve.
What you don't need
- ✕Android StudioA 10 GB install, on a laptop you may not be allowed to install on
- ✕Gradle, or any build toolsNothing to sync, nothing to fail on the school Wi-Fi
- ✕A .jar or .aar to uploadA missing dependency in one can crash the Robot Controller hours later, and only deleting the file on the device fixes it
- ✕A USB cable to push codeYou already type into the Robot Controller over Wi-Fi
What you actually do
- 1Paste the org/treadpathing folders into the OnBotJava editor, keeping the folder names
- 2Press Build Everything
- 3Your OpModes appear on the Driver Station, same as always
Every file is plain Java 7, so it compiles with OnBotJava's settings exactly as they ship. No lambdas anywhere — the Java 8 checkbox is off by default, and one stray arrow is a compile error nobody at a competition can diagnose. A lint check enforces that on every release.
Tuning happens through telemetry and log files, not a live dashboard. FTC Dashboard serves its screen out of Android assets, which OnBotJava cannot load — so instead, runs are logged to FIRST/java/src/Datalogs, which shows up in the OnBotJava file browser with a one-click download. Drop the file on the path planner and you get the plots.
It is 51 files, and your Control Hub compiles all of them. Nobody has published how long that takes. Time it on your hub before you rely on it, and if it drags, delete the odometry classes your robot does not have.
None of this stops you using Android Studio. Drop the same folder into TeamCode and it works unchanged.
The thing you already ran into
Your autonomous is a stopwatch.
Here is the same thirty seconds, written both ways. The one on the left is what almost every rookie team has in their code right now.
leftDrive.setPower(0.5);
rightDrive.setPower(0.5);
sleep(1500); // ~34 in? on a good battery
leftDrive.setPower(0.5);
rightDrive.setPower(-0.5);
sleep(700); // ~90 deg? on this carpet
leftDrive.setPower(0.0);
rightDrive.setPower(0.0);Every number is a stopwatch reading that was true once. A fresh battery overshoots. A worn one comes up short. Nothing in this code knows where the robot is, so nothing can notice it went wrong.
Route route = follower.route()
.splineTo(new Pose(34, 60, 0))
.stopAndHold(1.0)
.build();
follower.follow(route);
while (opModeIsActive() && follower.isBusy()) {
follower.update();
}Coordinates on the field, in inches, with a heading in degrees. The robot measures where it actually is sixty times a second and steers itself back onto the line when it drifts.
Read these three before you write a route
Three things that trip everyone up.
A tank drive cannot slide sideways. Everything strange about writing routes for one comes back to that.
Every pose you write is where the robot's nose points, which is what you see standing at the field. Not the direction the path happens to be going.
Driving gets the robot roughly there, fast. The pose hold is what gets it exactly there. Put one wherever you are about to score.
A tank robot cannot swap direction while moving. Asking it to go backwards ends the current path and starts a new one — so the robot comes to a stop. That is physics, not a bug.
Do these in order · about an hour
Your first hour, on your own robot.
Each step depends on the one before it. Skipping ahead is the single most common reason a route comes out wrong, because a follower tuned on a bad measurement cannot be tuned.
-
1
Paste the library in
Copy the
org/treadpathingfolders into OnBotJava, then Build Everything. Install → - 2 Check nothing is backwards Run LocalizationTest and drive around. Forward must raise x, left must raise y, counter-clockwise must raise heading. Rung 0 →
- 3 Measure ticks per inch Push the robot 96 inches along a wall. Do not calculate this from the motor spec sheet — measure it. Rung 1 →
- 4 Measure your track width Spin five times and read the number off. It will come out 2 to 4 inches wider than your tape measure says, and that is correct. Rung 2 →
- 5 Drive one line and come back Your first route. If it lands where you asked, everything after this is tuning rather than debugging. First route →
Documentation
Read next.
Grouped by when you will actually need them, not by how the code is organised.
Getting started
Installing in OnBotJava, the coordinate frame, and the one file you edit.
Before your first routeThe tuning ladder
Ten steps from motor directions to follower gains, each with the OpMode that measures it.
Writing an autoWriting routes
Waypoints, turns, holds, reversing, and firing your arm part-way along a path.
When you add dead wheelsOdometry options
Drive encoders, two pods, or a Pinpoint — what each costs you and what it buys.
When it drives wrongTroubleshooting
Symptom first: it cuts corners, it oscillates, it drifts during turns, it ends up sideways.
When you are curiousHow it works
Splines, velocity profiles, and why a tank drive needs a different follower from a mecanum one.
Before you spend an evening on it