Okapi Motion Profiling with Odometry?

#1

Last year, I got odometry working on my robot using tracking wheels, and this year, I am getting into using the 2D Motion Profiling on okapi with Pathfinder, so far without odometry. I noticed on the “Async Motion Profile Controller” page of the okapi documentation a method called “getError” with the following description:

Returns the last error of the controller. This implementation always returns zero since the robot is assumed to perfectly follow the path. Subclasses can override this to be more accurate using odometry information.

From this, I have two questions, with which I would greatly appreciate some help:

  1. Why would I need a subclass?
  2. How would I go about overriding the error?
#2

To your first point, you need a subclass because you can’t modify the existing class. The subclass would override that method.

To your second point, the implementation would be something like “get the current odom state and subtract it from the current point on the path”. Following the path perfectly means the odom state and the current path point are equal. Any divergence is your error. You would also have to override the path following algorithm (another method in that class) to account for this error.

1 Like
#3

OkapiLib uses Pathfinder, an external motion profile library.
This library takes input waypoints, generates a path between the waypoints, and then calculates ahead of time the velocities for each wheel to follow.
Then, when you tell it to execute the path, it blindly runs the target motor velocities, without using any positional feedback.

With this implementation, you can see that any odometry error can’t be accounted for, because Pathfinder does not support on-the-fly adjustments.

You can do as Ryan says and calculate the error using odometry information, but it would be a whole other deal to replace the motion algorithm to actually do something with that error.

2 Likes
#4

Thanks, @rbenasutti, I think I see how I could do that now.

Couldn’t I just stop executing the path, then recalculate a new path if the error starts getting to big? Would this make sense, or should I just try to make my own motion algorithms?

#5

Recalculating the path takes a nontrivial amount of time. I recommend that you just use pathfinder to calculate the trajectory, and then write your own code to generate wheel velocities which account for the trajectory and the error.

#6

By trajectory, I assume you mean the line path the robot should follow. Should I use generatePath to do that? Do you have any tips for how I could write code for the wheels to follow that path?

#7

Actually, I don’t remember if the trajectory is available in generatePath. You might need to just call pathfinder yourself.

As for how to follow the path, the ramsete controller seems to be popular right now. Read this https://file.tavsys.net/control/controls-engineering-in-frc.pdf

1 Like