I had a couple of questions regarding how you would apply these to pathfinding. I have seen a bunch of teams throwing around “pure pursuit” and looked into it and seems like a good solution. However, I noticed that Pathfinder just uses motion profiling to follow a path.
So my first question is: Why use just one or the other? I think one actually follows a path using odometry and the other is just wheel velocities?
And my second question is: I have seen on threads that you can combine the two for a more robust solution but I am not sure how. You generate a path and follow it… but how would you combine the two?
I could be wrong, but I don’t think you can use both at the same time because they are different techniques altogether. Motion Profiles are (as far as I know) pre-generated drivetrain velocities based on a pre-defined path. that does not adapt to any external forces. Pure pursuit, on the other hand, uses odometry to dynamically drive towards a future point on a pre-defined path, which allows it to correct for error in some cases.
So basically, motion profiling is pre-defined path following and pure pursuit is dynamic path following.
Again, not sure if you can combine them at all but I could be wrong. I do not believe you can currently use pure pursuit with Pathfinder (at least v1). you’ll probably have to make your own path generator for now. If you want to do something like this, I would recommend taking a look at 254’s 2018 code or 5499’s frc2018Kotlin repo(a couple commits back as we’ve changed some stuff in later commits). We have a pure pursuit algorithm from the document below and generate our paths with quintic Hermite splines based off of 254’s code base.
Motion Profiling is using a preplanned set of instructions, which usually match or are close to the update rate of your control loop. This means that every step of your control loop is accounted for in terms of where it should be, meaning it’s planned down to every little detail. This is great for fitting to a model of your system, but is bad at adjusting to outside changes, since you now have to recalculate your trajectory.
Pure Pursuit is more like drawing a curve in space, and getting as close to it as you can while following a point projected ahead. This is kind of like how grayhounds chase the rabbit: the rabbit follows the path, and the grayhounds are using pure pursuit to follow the path. It’s great at correcting disturbances, but for following tight turns, it’s pretty often that it will skip over some sections which may or may not be critical, depending on your lookahead quantity, robot position and path.
You can actually combine the two, and its important to do so for more aggressive driving.
This is my understanding of what 254 did in their 2017 code which used pure pursuit:
Wheel Odometry + Gyro tracks (x,y,theta) of the Robot, which is fed into a pure pursuit controller on a planned curve. But, Pure Pursuit only tells you what curvature to drive along; it doesn’t tell you how fast to drive. This is partially handled with things like adaptive pure pursuit or feed forward pure pursuit, mostly vis a vis stability.
What they actually did, if I read their code correctly two years ago, is run a single motion profile along the path they are driving (that takes into account things like how turning lowers your max speed), and then also dynamically update a profile on the arc they drive to return to the path. This second profile links in to the first at the look-ahead point. That’s how they get their velocity commands.
The difference is that with “normal” Pathfinder-style motion profiling, you generate commands for each wheel side and then execute them. With the 254-style approach, you generate a profile for the velocity of the robot that gets updated with the tracking error, and use that velocity with the Pure Pursuit curvature command to generate wheel commands on the fly. That doesn’t necessarily make Pure Pursuit more accurate, especially with drift in Odometry integration. You may also find that re-running the same commands is perhaps more reliable than integrating Odometry when moving over an incline (think of the HAB); but I can’t say either way there.
Of course, I didn’t write their code, so my reading could be wrong.
I guess my question is then, how much is odometry drift a problem over 15 seconds? I have been reading different threads and the consensus is that it doesn’t matter. We were planning in running NEOs on a WCD design. And were wondering if the built in NEO encoders would be good enough. We are putting mag encoders on the output shafts just in case.
That depends a lot on your robot and its sensors. With some effort, you should be able to get generally reliable odometry over a short course of time using just encoders, but of course fusing a bunch of sensors together (encoders, gyro, etc) will improve it over longer periods of time. 15 seconds should be fine with just encoders.
The NEO motors are generally pretty low-resolution, but I haven’t done any extensive testing using them for odometry applications, so my advice here is to test and see