OCCRA
Go to Post I think being successful in FIRST is creating an environment where people can grow, learn, change, and recreate... It's about making an environment where kids feel they can be successful... in whatever discipline they choose. - ColleenShaver [more]
Home
Go Back   Chief Delphi > ChiefDelphi.com Website > Extra Discussion
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 08-11-2018, 11:07 AM
edf42001 edf42001 is offline
Registered User
FRC #1712 (DAWGMA)
 
Join Date: Dec 2016
Rookie Year: 2016
Location: Philadelphia, PA
Posts: 8
edf42001 will become famous soon enough
paper: Implementation of the Adaptive Pure Pursuit Controller

Thread created automatically to discuss a document in CD-Media.

Implementation of the Adaptive Pure Pursuit Controller by edf42001
Reply With Quote
  #2   Spotlight this post!  
Unread 08-11-2018, 11:26 AM
AriMB's Avatar
AriMB AriMB is offline
The Philadelphian emigrant
AKA: Ari Meles-Braverman
FRC #5987 (Galaxia)
Team Role: Mentor
 
Join Date: Mar 2015
Rookie Year: 2012
Location: Haifa, Israel
Posts: 1,663
AriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond repute
Re: paper: Implementation of the Adaptive Pure Pursuit Controller

Very interesting algorithm, and the paper was written very understandably. Definitely something I'll be sharing with my programming team. Kudos!

A few questions:
• Why did you take away the initial acceleration for the target velocity calculations and then add in the rate limiter to compensate instead of just starting with a small positive target velocity (so the robot will start to move) and limiting the acceleration via the target velocity motion profile?
• How well does this method handle 180 turns? Can it drive backwards or only forwards?
• Did you play around with the difference between increasing path smoothness (from 2168's algorithm) and increasing lookahead distance? It seems like the two would do the same thing, possibly to the point where smoothing the path might not be necessary.
• Did you ever see the robot get far enough off the path that it couldn't recover (i.e. further than the lookahead distance away). If so, what did you have the robot do?
• How much of these calculations was done pre-match and what was done in "real time"?
__________________
Studying MechE at the Technion - Israel Institute of Technology
2017-present: FIRST Israel CSA/FTAA
2017-present: FRC 5987 Technical Mentor 18isr2 18isr4 18isrcmp 18carv
2012-2016: FRC 423 Member 15njtab 15padre 16paphi
Reply With Quote
  #3   Spotlight this post!  
Unread 08-12-2018, 08:57 AM
edf42001 edf42001 is offline
Registered User
FRC #1712 (DAWGMA)
 
Join Date: Dec 2016
Rookie Year: 2016
Location: Philadelphia, PA
Posts: 8
edf42001 will become famous soon enough
Re: paper: Implementation of the Adaptive Pure Pursuit Controller

Thanks for reading! Fair warning, I enjoy delving into a lot of detail, so here goes!

Quote:
Why did you take away the initial acceleration for the target velocity calculations and then add in the rate limiter to compensate instead of just starting with a small positive target velocity (so the robot will start to move) and limiting the acceleration via the target velocity motion profile?
Because there is no interpolation between points when finding the target velocity, it jumps between values, especially at low speeds. Removing the acceleration from the velocity profile and adding in the rate limiter makes the robot follow a more smooth acceleration curve at the beginning of the path.

Otherwise, both methods should work, you just need to make another pass through the target velocities in the forward direction to apply the acceleration limits. One possible disadvantage of using a rate limiter is that if your robot is traveling faster then it should, it will drive through deceleration points faster then the rate limiter allows it to decelerate and could overshoot the end of the path. This hasn't been an issue for us.

Quote:
How well does this method handle 180 turns? Can it drive backwards or only forwards?
We have never tried a path that goes straight forwards then straight backwards, but we did do a small U-turn once in testing, which worked pretty well because the robot slows down around sharp turns. If the turn is too small the robot could turn too early and not slow down because the closest point would never be the one with the sharp curvature and slow target velocity. This is where it could be helpful to adjust the lookahead distance based on robot speed or path curvature, so it follows the sharp turn more precisely. I suggest experimenting with the simulator, which I would love to do to help answer your question but I have to go on this thing called "vacation". Sigh.

Amazingly, to make the robot drive backwards all you have to do is negate the target velocity before sending it to the left/right wheel speed calculations. We haven't tried this on the real robot yet, only in the simulator.

Quote:
Did you play around with the difference between increasing path smoothness (from 2168's algorithm) and increasing lookahead distance? It seems like the two would do the same thing, possibly to the point where smoothing the path might not be necessary.
We haven't really played with this, but here's why I think smooth paths are better:
1. When you increase the lookahead distance to try to follow an unsmoothed path smoothly, the robot cuts corners, making it difficult to make small, precise turns.
2. Smoothing the path and using a smaller lookahead distance to precisely follow it means that when you graph the path you see precisely where the robot will be driving ahead of time.

So for best results, we smooth the path, use a smaller lookahead distance so we can go around sharp turns, and if we want sharp and less sharp turns in the same path we truncate the corner of the less sharp turn (so one 90 angle turns into two 45s).

Quote:
Did you ever see the robot get far enough off the path that it couldn't recover (i.e. further than the lookahead distance away). If so, what did you have the robot do?
While this has never happened to us, if the robot can't find a lookahead point it will use the value of the last one and steer back onto the path. However, it might be better instead to use a point a bit farther down the path than the closest point, because:
1. This point will travel with the robot as the robot continues forward, unlike the last lookahead point, so the robot won't have to do a u-turn to get back to the point.
2. There might be a reason for starting the robot off of the path, in which case there is no last lookahead point.
3. Another place the robot can't find the lookahead point is at the end of the path, and using a point a few ahead of the closest point will make the robot aim for the end of the path, like it should.

Quote:
How much of these calculations was done pre-match and what was done in "real time"?
The smoothed paths are calculated pre-match and loaded into files, because for large smoothing amounts the smoothing algorithm can take a decent amount of time to work. Once autonomous starts, the path data is read and the path curvature and velocity setpoints are calculated. Then odometry, finding the lookahead point, curvature, closest point, left/right wheel speeds, etc., is done in real time.
__________________
Autonomous Enabling... Dang it!
Reply With Quote
  #4   Spotlight this post!  
Unread 08-24-2018, 09:37 AM
AriMB's Avatar
AriMB AriMB is offline
The Philadelphian emigrant
AKA: Ari Meles-Braverman
FRC #5987 (Galaxia)
Team Role: Mentor
 
Join Date: Mar 2015
Rookie Year: 2012
Location: Haifa, Israel
Posts: 1,663
AriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond reputeAriMB has a reputation beyond repute
Re: paper: Implementation of the Adaptive Pure Pursuit Controller

I've been meaning to get into autonomous path-following algorithms, and this white paper seemed like an intuitive place to start. Using the steps as explained here with a few minor changes, I rewrote the code from scratch in Python (here). The white paper was very easy to follow, and the whole thing came together pretty smoothly. I could definitely see my team using something like this in the future for autonomous path-following.

Thank you again for this resource!
__________________
Studying MechE at the Technion - Israel Institute of Technology
2017-present: FIRST Israel CSA/FTAA
2017-present: FRC 5987 Technical Mentor 18isr2 18isr4 18isrcmp 18carv
2012-2016: FRC 423 Member 15njtab 15padre 16paphi
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 07:29 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi