How To Implement Path Following With Roadrunner 1.0

[jdbott]

Hey @rbrott,

Recently, my FTC team has begun using roadrunner 1.0 on our robot, and we have very quickly seen enormous benefits. However, we were wondering if there was a way to push the robot to its limits more, while still keeping the useful features of roadrunner. We discovered Path Following on your website, and it does seem like a good solution, as it keeps the benefits of roadrunner while adding some of those from pure pursuit. Before implementing it, we do have some questions though:

1. Are there any cons to this method that may discourage teams from choosing it?
2. Does this method have any termination criteria, like the stopwatch with normal trajectories?
3. Do normal trajectory functions, like .splineTo(), etc. still work with Path Following? Do actions still work?

After that, we were wondering about the actual implementation of Path Following. After looking through the webpage on it many times, we still are a bit confused!

• @jdbott

[rbrott]

1. Are there any cons to this method that may discourage teams from choosing it?

The time taken to follow paths will vary depending on external disturbances, voltages, and other factors. That variation can make it difficult to structure an autonomous as a series of fixed steps that always execute.

2. Does this method have any termination criteria, like the stopwatch with normal trajectories?

You will need to come up with your own termination criteria probably based on position/velocity error.

3. Do normal trajectory functions, like .splineTo(), etc. still work with Path Following?

Trajectory functions like splineTo() also come as path functions with the same name. Everything you need should be available under one of the path builders.

Do actions still work?

Yes, actions work with path following. One could write a path following action that composes like normal with other actions. There is no path action builder to match TrajectoryActionBuilder though, and you may have to think about how to synchronize execution of actions with path progress.

After that, we were wondering about the actual implementation of Path Following. After looking through the webpage on it many times, we still are a bit confused!

It would help if you could identify specific points of confusion (like the questions above).

[jdbott]

Thank you so much for your feedback. We can see that while Path Following can provide advantages, it also definitely has some work that must be done to ensure that it works similarly to normal trajectories.

Firstly, we were wondering if there was a way to use the normal trajectory building/following logic while increasing the speed of the robot. This way, we could keep the benefits of the tried-and-true normal method (easier structuring, path visualization, actions, etc.) while gaining speed. The first thing we tried with this method was increasing the path profile parameters, as below:

// path profile parameters (in inches)
public double maxWheelVel = 70;
public double minProfileAccel = -35;
public double maxProfileAccel = 70;

// turn profile parameters (in radians)
public double maxAngVel = 1.5 * Math.PI; // shared with path
public double maxAngAccel = 1.5 * Math.PI;

With this approach, we also ensured powers set to the motors were scaled proportionally to be within the acceptable power range (-1, 1). However, this didn't seem to increase speed in all situations, and sometimes affected following accuracy negatively. The logic behind this was that by increasing the parameters, the robot would spend more time at higher powers, leading to faster following.

To identify specific points of confusion like our previous questions, here is the following:

1. Do you have any idea why the approach illustrated above doesn't seem to work as expected in all situations?
2. Like above, do you have any other ideas about how we could increase speed while staying within the default trajectory builders?
3. Do you think this is a viable option to increase efficiency within our programs?

Sorry for the lack of specificity with our questions - at this point we are trying to gather as much information and insight into the problem as possible! Thank you so much for your reply though!

• @jdbott

[rbrott]

1. Do you have any idea why the approach illustrated above doesn't seem to work as expected in all situations?

Trying to follow an infeasible trajectory is bound to fail. Slowing down the commanded velocity dynamically preserves direction, but it doesn't slow down time to compensate for the slower speed. The more the robot falls behind in the trajectory, the more out of sync the commands will become (and feedback will also be driving the robot to increasingly unrealistic setpoints).

2. Like above, do you have any other ideas about how we could increase speed while staying within the default trajectory builders?

You could try developing a system for slowing down time, but that loses the predictability of trajectory following and is in effect a more convoluted path follower.

3. Do you think this is a viable option to increase efficiency within our programs?

Not really