Is there any way to do curved turns without Pure Pursuit?
Just to clarify, the main benefit of pure pursuit is being able to do curved turns, right? what else does pure pursuit help with?
4 Likes
Sure a bunch.
Generate a motion profile that contains target velocities for each wheel at each time step and “just run it” using velocity PID. (Okapilib way)
Tune a drive straight PID controller that normally tries to drive your angle change to 0 so that it takes in desired final angle and it achieves the exact arc you want when you specify “drive straight 12 inches while rotating 45 degrees”. (Team BNS used to do this)
Implement a different algorithm that like pure pursuit takes in a path and tries to follow it. The other one people like talking about is ramsete controller (which is a terrible name).
11 Likes
Could anyone clarify some more? We have a 3 wheel Odom position tracking, and in our self correcting algorithms, we have we have a linear form of correction. Basically if the robot gets pushed off path, it does a stationary turn, drives straight, and does another stationary turn till it’s back in the position it should be in.
I want to improve the Odom algorithms so that it can do the following things:
- correct the position in real time in a drive straight PID or some sort of odom motion algorithm to keep the robot always driving straight
- Do curved turns - we are starting Pure Pursuit soon (can this solve both #1 and #2?)
- Be able to drive fast during the autonomous while still mainting precision and accuracy (can Pure Pursuit help with this?)
We looked at Semi colon’s programming skills here from tipping point and noticed their Pure Pursuit - https://www.youtube.com/watch?v=eysHlvHFTFw
What coding algorithms do you think they had in total throughout their robot that allowed them to be this accurate? (Please give examples like turn PID, distance error PID, drive straight PID, Pure Pursuit, Ramsete, etc).
Right now our ideal robot would have - turn PID, distance error PID, drive straight PID, Pure Pursuit Odometry. What else should we add?
I mainly don’t understand the purpose of Odom motion algorithms? How should they work? Our linear ones are not ideal I do not think so. How do most teams do it? Please help.
2 Likes
We have a pretty smooth auton with just drive and turn PIDs. We use two-wheel odometry with a gyro for turning, and we correct for deviation between our robot’s heading and the line to the desired point with a turn pid while driving. This lets you do curved motions with just a drive PID function. You don’t need pure pursuit and you don’t need motion profiling. Careful tuning of your PID constants and functions will take you quite far.
(This run uses only two pid functions)
11 Likes
Ya that is the method team BNS used in the past. It is interesting for its simplicity and people have used it successfully in the past.
As a roboticist I don’t love it because its not very predictable. It might be consistent but you could never predict what will happen with a set of drive and rotate commands without running them.
Back to the consistency question, couple years ago on discord when talking about this approach I made this plot. It shows 100 trials where it drives the same distance and turns the same amount but where every time step there is some random noise on how successfully you turn. Like if the field traction was ever so slightly different or didn’t have a perfectly consistent tuned PID loop, or your weight distribution was weird. How well you deal with these factors the tighter the grouping is at the end, I did arbitrarily set the random noise to make the point.
So you achieve the same total distance and total angle change but unless those distances and angles were synced perfectly every trial would take you somewhere a bit different.
And to @Bb3456 I am going to answer your question. I just had the answer for @2775Josh handy.
8 Likes
Not saying anyone should read this but here is a well known paper talking about how the shape of points created by my plots above(the so called Banana-shaped distribution) can be modeled. They say the shape comes from gaussian noise on wheel positions when doing odometry. (odometry and this curved trajectory problem being closely linked)
You can see when they try to compute where a robot must have ended up giving a distance traveled and an angle change with noise on the measurements they get the robot could have ended up at any of those blue points. The plots are them trying to fit a distribution to the data so they can say with what probability you are in a specific region. Specifically the insight of the paper is not to consider the noise on the final position but the noise on the specific wheel motions and how that change in heading changes the final position. (Exp better than XY)
@nickmertin @Andrew_Strauss Did you guys end up looking at anything like this in your odometry research in the past? The standard equations effectively do the optimal thing, which is find the mean of the distribution, and this paper is more about how you can think about how uncertain you are about the position.
9 Likes
OkapiLib’s motion profiling lets you do curved turns with no odom at all. If you tune the constants correctly it works very nicely.
This sounds like a great start.
This is exactly what Pure Pursuit lets you do. You define a path from A to B and then it takes your current position and angle and computes what robot velocity (straight + rotation) gets you back on the path and following it. So its actually reactive using your current measured position, using odom or GPS. Ramsete works similarly.
Here is a random video of Pure Pursuit running. The red path is the desired and we see the car that can only go straight/turn follow it.
Alternatively the algorithms used by people to generate motion profiles to go from A to B(like those provided by Okapi) and could be adapted so that if you ever drift off your path to recalculate to go from Current to B. As opposed to Pure Pursuit which tries to get you back on your original path even if you got pushed way off of it, recalculating a motion profile would result in finding the new shortest path to your goal. The issue is that new path is one you have not tested, so it might have obstacles in your way…
I am cheating a little bit because this is a cooler video but here is an example of people generating new motion profiles on the fly as they end up not quite where they expected to be. Just skip to the robot bits I don’t actually think there is a lot to be added to the discussion here from the actual algorithm they are using. (they have an idea of how the vehicle moves with noise, and use that to find the best control to get to goal, replan constantly as they move)
Speed is sorta complicated. Any well tuned solution will beat a poorly tuned solution. So historically teams have won worlds programming skills with simple turn and drive straight maneuvers, teams have won worlds programming skills with tuning drive straight arcs well (BNS). Curves should be faster but not so much faster to make up for just tuning simple stuff better.
Here is a great time to revisit the discussion about replanning the trajectory to drive constantly, remember that cool RC car drifting video here is me effectively doing the same thing. Notice how slow it is because none of it is tuned nearly as well. If you replan poorly you can get behavior where you jerk between new plans like you can see in this video.
To the best of my knowledge semi colons are using pure pursuit. As to Ramsete vs Pure Pursuit my only contradictory arguments are
- FRC teams who have done this a lot longer say Ramsete is easier to work with and compete at a high level with
- Ramsete is not a well known or well respected algorithm like Pure Pursuit is. It doesn’t even have a proper name “ramsete controller” is something FRC teams slapped on the algorithm
I have not worked with either personally so take both arguments seriously but I don’t have a recommendation.
Those sound like great goals. My only critique is how your breaking things up, Odom is a goal all on its own and doesn’t need to be attached to Pure Pursuit. I would also remind you Pure Pursuit follows a path given your current position, so there are a few steps.
- Get an estimate of current position (Odom/GPS)
- Create a path to your goal using a different algorithm or some sort of waypoints you interpolate between
- Use Pure Pursuit to purely pursue your desired path
1 and 2 being required for 3 but 1 and 2 being solvable independently.
14 Likes
I agree with Tabor regarding this issue - abt having speed and precision at the same time.
I always say this to my students - uncertainty principle applies in tuning of robots as well.
You just can’t have high speed and high precision at the same time.
High speed will generally leads to greater momentum, and the greater the momentum, the greater the uncertainty in bringing the robot to a sudden stop.
And the reason why the tried and trusted stop and turn approach will still do well is because the “stop” will kill away the momentum, and hence making the subsequent turns more precise.
So it is about getting the balance right - how fast can you go while still within the tolerance range of the precision required.
So even if you are using pure pursuit, there is still a limit to how fast you can go.
I might be wrong here, but I do think most teams made use of motion profiling in tandem with pure pursuit, to allow them to know when to speed up or slow down.
5 Likes
Question about this - how much effect does the time to recalculate a new motion profile, while currently moving, play?
1 Like
Thanks for the ping on this. We have not, but that is something I’d be interested in looking into in the future. Thanks for that paper reference, I’ll take a look.
It is worth noting that modelling of uncertainty is definitely useful not just for getting an idea of how well your algorithm is working, but also for performing sensor fusion (e.g., with an extended Kalman filter). The uncertainty in individual components of your measurements (in the form of an autocovariance matrix) is a key input to the fusion algorithm which makes it effective at predicting the true position based on noisy measurements.
8 Likes
Excellent question. So it definitely plays an important role. You want to tune your trajectory generator and controller to minimize how often you need to replan.
If its really quick you make a motion profile (which will include your currently velocity) and you just seamlessly switch into executing it right away.
If it is <1 second you could do stuff like, take your current velocity figure out where you will be in 0.5 seconds and start planning from that position at your current velocity. This sorta relies on your current velocity not being in the complete wrong direction of your goal but I think that is probably a reasonable assumption.
Lastly the most extreme thing would be fully stop, and wait for you to make a new plan from 0 velocity to the goal.
4 Likes
Does OkapiLib’s motion profiling require a special PID like arc PID or something like that?
also, does anyone have any tutorials or anything like that for it?
You can include PID, but it is not necessary.
https://okapilib.github.io/OkapiLib/md_docs_tutorials_concepts_twodmotionprofiling.html
What would the PID be for?
how difficult/complex is it would you say?
Also sorry for bombarding with questions and too many messages, this shouldve been all in one -
Can motion profiling work with a 6M tank drive with all the motors on each side connected?
No pid needed. It just precomputes the voltage needed and sends the voltage. So it can be a tad inaccurate but it’s still crazy good for the how little effort it requires.