OCCRA
Go to Post This brings back childhood memories of playing with erector sets... Wait. I still do. :D - Whippet [more]
Home
Go Back   Chief Delphi > ChiefDelphi.com Website > Extra Discussion
CD-Media  
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, 12:07 PM
edf42001 edf42001 is offline
Registered User
FRC #1712 (DAWGMA)
 
Join Date: Dec 2016
Rookie Year: 2016
Location: Philadelphia, PA
Posts: 9
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, 12:26 PM
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,764
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, 09:57 AM
edf42001 edf42001 is offline
Registered User
FRC #1712 (DAWGMA)
 
Join Date: Dec 2016
Rookie Year: 2016
Location: Philadelphia, PA
Posts: 9
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, 10: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,764
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
  #5   Spotlight this post!  
Unread 10-12-2018, 02:58 AM
Dan Katzuv Dan Katzuv is offline
Registered User
FRC #5987 (Galaxia in memory of David Zohar)
Team Role: Programmer
 
Join Date: Feb 2018
Rookie Year: 2017
Location: Haifa, Israel
Posts: 31
Dan Katzuv is an unknown quantity at this point
Re: paper: Implementation of the Adaptive Pure Pursuit Controller

What are the meanings of "adaptive" and "pure" in this algorithm?
Reply With Quote
  #6   Spotlight this post!  
Unread 10-12-2018, 10:20 AM
edf42001 edf42001 is offline
Registered User
FRC #1712 (DAWGMA)
 
Join Date: Dec 2016
Rookie Year: 2016
Location: Philadelphia, PA
Posts: 9
edf42001 will become famous soon enough
Re: paper: Implementation of the Adaptive Pure Pursuit Controller

Quote:
Originally Posted by Dan Katzuv View Post
What are the meanings of "adaptive" and "pure" in this algorithm?
Great question! I believe “pure” refers to how the path following algorithm is based purely on pursuing the lookahead point. “Adaptive” refers to modifications of the basic pure pursuit algorithm. For example, since larger lookahead distances are more stable, one adaption could be to scale the lookahead distance proportionally with tracking error, so that if your robot accidentally gets far off the path it won’t break itself while vigorously trying to swerve back onto the path.

I’ll admit I just borrowed the name from Team 254's code, who may have gotten it from this paper: https://www.ri.cmu.edu/pub_files/pub...nzo_1994_4.pdf
So thanks for making me think about it!
__________________
Autonomous Enabling... Dang it!
Reply With Quote
  #7   Spotlight this post!  
Unread 11-01-2018, 08:31 AM
Galen Galen is offline
Registered User
no team
 
Join Date: Nov 2018
Location: Paraguay
Posts: 1
Galen is an unknown quantity at this point
Re: paper: Implementation of the Adaptive Pure Pursuit Controller

Hello ! I have a question and I need an answer as soon as possible, please!

How did you run your VI's in parallel in a myRIO, or in your case in a robotRIO ?
If you didn't do that, what method did you use to acquire and process data in real time ?
Reply With Quote
  #8   Spotlight this post!  
Unread 11-01-2018, 09:32 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,764
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

Quote:
Originally Posted by Galen View Post
Hello ! I have a question and I need an answer as soon as possible, please!

How did you run your VI's in parallel in a myRIO, or in your case in a robotRIO ?
If you didn't do that, what method did you use to acquire and process data in real time ?
In LabVIEW you can run two loops in parallel by putting them both in the main VI without any wires connecting them.

This is not really the place to ask these questions, since this thread is for discussion of the Pure Pursuit implementation. If you have any further questions you can PM me, or post your own thread. You should know though that this forum is specifically for the FIRST robotics competition, so if you are not affiliated with the program you may finding people are less inclined to answer your questions.
__________________
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 11:14 PM.

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


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