View Single Post
  #1   Spotlight this post!  
Unread 07-11-2014, 09:02
Ty Tremblay's Avatar
Ty Tremblay Ty Tremblay is offline
Robotics Engineer
FRC #0319 (Big Bad Bob)
Team Role: Mentor
 
Join Date: Feb 2006
Rookie Year: 2004
Location: Alton NH
Posts: 847
Ty Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond reputeTy Tremblay has a reputation beyond repute
Re: Dijkstra's(?) Algorithm help

Quote:
Originally Posted by Sparkyshires View Post
Okay, I think I get it. Just a couple questions:
  • 1. How would this correlate into a map of line segments?
  • 2. How would you go about putting something else in there for the time it may take to turn?
  • 3. And what exactly is the a*?
1. I used squares because it was easy to generate the examples with ppt that way. Use intersections of your line segments. Since you're following a magnetic line, I'm assuming you can only turn at intersections, so call those intersections your nodes.

2. Dijkstra's Algorithm explanations use the term "distance" because that's the easiest term to understand when beginning to learn path planning. However, it's important to realize that physical distance is often not the only factor when navigating from point to point. A better term to use is "cost" instead of "distance." This would let you factor in time for turning and even things like energy conservation and a risk factor for getting stuck.

3. hzheng_449 hit the nail on the head. If your algorithm is a bike on training wheels, Dijkstra is without training wheels, and A* is a motorcycle. It's best to learn to ride without training wheels before jumping on a motorcycle.
__________________
Reply With Quote