ansaurus

Question

Answer 1

A:

Have your tried a* (a-star)? it is also nice when you provide it a terrain map. You can assign weights to different portions of terrain which will result in a different path. I believe the algorithm by default does not provide diagonal directions, but you can add that in pretty easily.

Also it does not by default deal with "turning" but a-star will give the full path. What you could do is calculate the turn radius based on 2 points. The current position and the next calculated position, OR the last position and the current position. You can then add or subtract the facing direction with the change in angle. You may need to tweak this some.

Parris 2010-10-27 18:34:04

Sorry, I said grid, which implies I'm talking about a graph with discreet nodes. This is in a continuous coordinate system. Thanks!

loneboat 2010-10-27 18:37:19

Well they aren't different. There is no way to not have a grid. Your grid might contain extremely small "points" and as a result not seem grid like. Think about pixels on a screen. Consider that in 3d games positions are defined using floating point values; however, a grid is overlayed to calculate path, oct-trees, etccc

Parris 2010-10-27 18:41:16

You're answering a different problem and too many problems.

Platinum Azure 2010-10-27 18:56:43

Parris: I understand that I _could_ quantize the grid into one giant graph with nodes (hence enabling me to use A*), but I think doing it to the degree of precision which I need would make it computationally prohibitive on my platform. Thanks, though!

loneboat 2010-10-27 19:27:41

Answer 2

+3 A:

The way you problem is described, the algorithm is straightforward and requires only two simple steps: 1) move forward while turning (left or right) until the car is pointed directly at B, 2) move straight forward until you hit B. Done.

The only relatively tricky part is the first step. If B lies to the left from the longitudinal axis of the car in its initial position, the natural approach would be to start by turning left. This will work, unless point B lies inside the circular trajectory produced by such a left turn (of radius turningRadius). In the latter case the car will run in circles, but will never be able to aim directly at B. In such cases the proper strategy is actually to start with a right turn and keep turning until you aim the car at B.

So, if you don't have any optimality requirements for your trajectory, the simplest algorithm for the first step would be to unconditionally turn "away" from the point: turn right if B lies to the left of the longitudinal axis of the car, and turn left if B lies to the right. Keep turning until the car is aimed directly at B. This sounds a bit unnatural, but it always works, i.e. you will always be able to eventually aim the car.

If you care for a more optimal (shorter) trajectory, then you need to analyze the location of B with respect to the initial position/orientation of the car ("Is B inside the turning circle or outside?") and choose the direction of the first turn accordingly.

AndreyT 2010-10-27 18:45:32

but that does not account for terrain or roads

Parris 2010-10-27 18:48:14

@Parris: What terrain? What roads? There's no mention of any "terrain" or "roads" in the statement of the problem. The problem, as stated, is getting from point A to point B specified by their cartesian coordinates on continuous and infinite flat plane.

AndreyT 2010-10-27 18:50:06

Ahh true, I assumed the problem was more difficult. When I read RC car, I assumed game or real RC car. The problem statement does not say infinite or flat plane by the way. This method would work fine if that were truly the case, or is a simple animation. However, how often is a system completely flat, with no obstacles, and infinite.

Parris 2010-10-27 19:00:31

Excellent description - thanks so much! The case where the destination was what had me stuck until now (or rather, "going in circles" - har-har). Thanks!

loneboat 2010-10-27 19:14:57

What if B is perpendicular and relatively close to A (Similar to a parking maneuver)? I think that hen your algorithm will fail.

Alejandro 2010-10-27 19:51:33

@Alejandro Weinstein: I don't see any problem in this case. If it is too close on the left, my algorithm says that the car has to turn right. Easy. Where do you see the problem?

AndreyT 2010-10-27 20:25:43

Answer 3

A:

Sounds like an interesting and fun project! To get a specific algorithm recommendation, you should probably provide more detail… Like are you expecting to literally run this on some sort of embedded controller attached to an RC car? Or is the algorithm to run on a workstation and control the car remotely? (Or is this purely an abstract exercise and there is no car… awwww.)

My generic recommendation for getting a handle on where to start would be Building Problem Solvers, which is a great intro to the world of "AI" problem solving techniques. It might be a bit dated these days… but wait, what am I saying! Probably not. :-)

[Okay I should explain that last comment: Most "modern" AI techniques that I've seen in practice actually date back to ideas many years old… They've just become practical now thanks to the relentless advance of Moore's Law. So a book written in 1993 is still discussing fairly state-of-the-art techniques, from what I have personally seen. I'd love to be pointed at a counter-example!]

Kaelin Colclasure 2010-10-27 18:47:31

Yes, I'm really attaching an embedded system to an RC car. It'll be fun! Thanks for the book recommendation.

loneboat 2010-10-27 19:25:14

Answer 4

A:

In general this is not an easy problem. It falls under the category of "Planning under differential constrains". The last three chapters of LaValle's book (available online here) deal with this. In particular, look at section 14.4.2., that deals with a "Dubins car", which is like your RC car, except that it doesn't move backwards.

Also search for "Dubins car path planning". You will find a lot of papers.

Alejandro 2010-10-27 18:57:19

ansaurus

tags:

views:

answers:

Algorithm for RC car...

related questions