Hi, so for a while now my team and I have tried to use Jerry Path to export path text files and use it in the lemlib chassis.follow(...) method. However, it’s always completely inaccurate and inconsistent. We have opted for using a PID and chassis.moveToPoint(...) etc but it’s much slower to implement, in our opinion. We would love if someone could point us to a solution, because it seems like we should just be able to make a path on Jerry Path, export it, save it to the static folder and follow it.
This would be a great opportunity for you and your team to demonstrate that your skill level matches that of the outside library and tools you are using. Debug the library, create a theory about why the robot moves unexpectedly, and fix the code while documenting your process.
To build on this, expect to be asked to demonstrate your ability to create similar code that is provided to you in the library and explain the implementation. Under G4 update, teams will be expected to be able to show how choices of code and iterations were made through documentation - a good opportunity to create a solid engineering notebook for your team, as they must be able to explain team choices in coding if the lead coder is not present at events.
Honestly from my experience and others, LemLib pure pursuit isn’t great, and some of it is how it is implemented and some of it is the nature of pure pursuit. Pure pursuit in my experience isn’t great with such short paths or accurate, as unlike PID it doesn’t exactly follow the path, it just guides itself using the points. In that particular path I have found a lot of success using a boomerang algorithm, even though PID is just fine.
Unfortunately, there isn’t really a way to get a really accurate auton fast, it really does take a long time and especially tuning. I would spend the time using PID or look into boomerang.
But at the very least, try running a large path and tune your lookahead distance to see some stuff of what’s up. But when you see those super accurate autons… most do not use basic pure pursuit, especially by itself.
Actually, I’m now seeing it, I think you put 0.3 inches as your lookahead distance??? That’s one thing messing up the algorithm, it isn’t designed to do that. Basic Pure Pursuit | Purdue SIGBots Wiki
I strongly believe Dubin’s Curves to generate paths is better for Pure Pursuit, even though LemLib doesn’t support it. Essentially it treats the robot like a car with a turn radius so that sharp points are now changed with smoother curves.
This allows the robot to keep moving with almost zero moments of point turns, and allows much quicker autonomous routines.
If this were done with Bezier curves, or a straight point to point, the robot would need to do a point turn first before moving which clunkier and wastes precious time. Instead, if you use Dubin’s Curves it auto generates a respectable curve so that the turning and the moving is one single, natural motion.
I have implemented my own pure pursuit algorithm that follows a Dubin’s Curves path in my own library if anyone is interested in looking under the hood at the source code:
One way to make Pure Pursuit reliable is to have it such that if the robot is within 1 inch from the target to just accept the sideways error, straigtehn out, and move forward/back to have no forward/back error and no rotational error. Otherwise the robot will actively back up and drive forward in an oscillating motion.