How does the robot know where it starts with pathplanner?

Hey yall, just had a quick question about the path planner as my team is considering using it this year, how will the robot figure out where it is on the field so it can decide where to go for autonomous? I was thinking maybe scan for apriltags and decide where it is based on that or if you just program one path and try to get your robot in that space when the game starts. Thanks!

1 Like

In past years, we have used our dashboard application to select a certain auto. We place the robot in very specific locations on the field, and these known points are where we start the auto from in pathplanner.

This year, it may be possible to use the apriltags to infer the starting location of the robot and to pick an auto based on that. For consistency, I would personally prefer using known locations on the field, but you could try the apriltag method.

3 Likes

IMO, using AprilTags to zero the localization will be more accurate, because then you don’t have to be very precise with the robot placement at the start of every match.

1 Like

We are currently using the apriltags to supplement our pose estimator, but planning a path on-the-fly for the auto seems unnecessary when we can use specific locations. It would be cool to just put down the robot anywhere and have it figure everything out though.

do you have any examples of how this works? i haven’t found anything like this yet and this sounds a lot easier :laughing:

Sure, we currently do it in our code, and I like to think it’s a pretty simple implementation.

FRC2539/javabot-2023: Team 2539’s robot code for the 2023 season: Charged Up. (github.com)

See the AutonomousManager.java file, and feel free to look around for anything else related to autos.

Also, if you use one of the built-in dashboards, you may find SendableChooser more intuitive, which is documented on the WPILib Java docs. We have a custom dashboard, so just using NT makes the most sense for us.

Edit: if you want an example of choosing a path automatically using apriltags, I’m not sure that anyone has publicly released code for that. One team did recently post an on-the-fly path generation system on chiefdelphi.

2 Likes

For this years game, I think the very first thing you want to do is eject a game piece in the correct location. I think this means you need 3-4 starting locations so you can choose the right autonomous before the game starts.

The simple way the path planner trajectories can work is you feed the initial waypoint into your odometry to tell your robot “Hey, this is my starting position”. So if you feed the correct A into your robot, path planner will get you from A to B with ease.

Edit: didn’t mean for this to be a reply to GoldMonster.

2 Likes

If you did not get the answer yet - we’re also going with PathPlanner. The main idea -
if you use their Ramsete controller (or PPSwerveControllerCommand - whichever drive type you have), the odometry (odometry set in your command) will tell the PathPlanner where it THINKS the robot is right now.
For instance, in Ramsete (the tank drive robot chassis), you see

this.resetOdometry(traj.getInitialPose());

That basically gets a first pose from a trajectory in a file and sets your current robot position to it.

However, you can create your own Pose2D object and feed it into the resetOdometry (which is ultimately the odometry of your field/DriveSubsystem or whatever you call it). For Swerve, of course if would be Holonomic Pose object, but the idea is exactly the same.

You’re required to update the field odometry in your drive subsystem based on the encoders/IMU on a regular basis, so the robot knows where it is as it drives. For that it uses a pose supplier (second parameter of your command controller). Ultimately it does not care where the pose information is coming from.

1 Like

so, will I need to have encoders on my drivetrain wheels? Also, we are using a dashboard selection system to tell the robot which auto to do. Thanks!

Trajectory driving needs ongoing updates on a Pose2D.

That means it uses both encoders from the wheels and the IMU to detect/process robot’s rotation.

The encoders will be used not only to track movement distance, but also determine the speed (which is usually also available directly from the motor controllers).

In fact, trajectory driving based on software PID (e.g. Ramsete, PathPlanner etc) usually ends not on proximity to the final destination (which is something you can add if you wish, but on timer (in other words, trajectory controller’s understanding where you should be at). That behavior can be overwritten, of course, but if your characterization (e.g. via SysID - which I find reasonably easy to use) is more-or-less correct, your estimated timing will be good as well.

That’s actually why the speed tracking (along with the distance and rotation) is important.
In Ramsete (or PathPlanner) configuration for a trajectory there is a parameter that basically indicates what should be a voltage increase to increase the speed of your robot by 1m/s. That is also determined by characterization.

The robot knows where it is at all times. It knows this because it knows where it isn’t. By subtracting where it is from where it isn’t, or where it isn’t from where it is (whichever is greater), it obtains a difference, or deviation.

3 Likes

yeah that sums it up perfectly lol

so pathplanner wouldnt work with CIM motors? or am I just confused

(Just joking around)

6 Likes

The missle will need to know where it isn’t and where it might be

(i.e. CIMS will work with external encoders)

1 Like

well, time to buy some CIM encoders :rofl:

Yeah most gearboxes will have support for an optical quadrature encoder, a magnetic one, or a 1:1 stage with encoder in the case of planetary.

Of course it does! But if you use CIM, you need them to be driven by a controller like TalonSRX, which supports connectivity to an encoder, like MagEncoder, Cancoder etc. Those encoders will need to be mounted on some shaft (either the wheel axel - which will make it easier to program) or the motor shaft (which will make it a bit more difficult for programming, since you would need to account for the reduction from the gearbox).
For CIM specifically you can use CIMCoder from Andymark. They’re very inexpensive, though their resolution is not that high. But it’s usually sufficient for the drive motors and trajectory estimates. Main advantage - they do not take much space and can be easily added to an existing setup that does not have encoders. For more “fancy” ones, look into the MagEncoder or Cancoder (they’re essentially the same thing, though the Cancoder can be directly connected to CAN, but you will need TalonSRX to connect MagEncoder to.
For IMU you have a choice of Pigeon and NavX. You can even use RoboRIO-integrated IMU, though I would say its precision is not that great, and it tends to drift more over time.

Also as others indicated already, if you use off-the-shelf gearbox (e.g the one from AndyMark), they usually have special places to mount MagEncoder on the drive shaft. One big advantage of the MagEncoder and similar over simpler encoders - they combine both absolute and relative encoders, which may help you if you need to track a “starting point” of some kind that persists over the robot powering on and off. We successfully used absolute encoders, for instance, to make the wheels parallel properly in our test swerve setup. That way we do not need to have them parallel mechanically when we set the robot on the field. The robot will auto-straighten them oon startup.

1 Like

I’m glad that we had the exact same thought.

Edit: just to remove any confusion, all references to something “knowing where it isn’t” are references to the viral Navy training video posted by @Skyehawk. I am sorry for derailing this thread.

3 Likes

all good, i had a good laugh :joy:

1 Like