OK, I see I have my terminology wrong. Guess then my question is how should I be thinking about this.

I have a simple 2D map, with a path planner which works out the steps that need to be taken from A to B via n Way Points (As required). I do calculate two vectors, one for the Robots current position and on and the next Way Point and use those two to determine the angles of error for the desired path.

Then the missing link in the chain to so get the robot to calculate some value, based upon to far it is from a Way Point to decrease it's turning angle the closer it gets to the way point (It tends to get confused if it over corrects).

I guess just simple trig...

If someone could clarify that would be great. I think I been thinking I could make use of a Vector where no such thing exists?

Thanks

Mark

PS chronozphere's help gives a value with increases as the robots moves closer to the target...

Quote:Original post by Ezbez

Quote:Original post by Rockoon1
A vector is not a point, nor is a vector 2 points.

Agreed, but a vector has a start point and an endpoint.

No. A vector can be expressed in that way, but thats not what a vector is.

Quote:Original post by Ezbez
It also doesn't make sense to subtract points

Yes it does. This gives you the direction and magnitude (called a vector) between them.

The idea that a vector is two points presupposes that you will be subtracting them from each other. Such a preposition should assure you that these two points themselves are not a vector, that you actualy need to calculate a vector from them.

Quote:Original post by Ezbez
If a mathematician gave me an angle when I asked for a distance, I would have scoffed.

An angle is a distance, typically measured in radians or degrees, so you would have scoffed in error.

The distance between two vectors is always an angle.

I'll try and make it clearer.

Given this:

2 cartesian points on a grid(Map): (1,1) and (9,9).

The robot is at (1,1) and the Way Point is (9,9). From these I calculate 2 vectors for these points. From that I can work out the angle and direction required to turn to get to (9,9). So inially that would be 45 degrees.

As the robot progresses along the path the heading may change (Drifts off the path +5 degrees here -10 degree there to say in line with point (9,9)). Problems happen as it approachs the point (9,9) on the grid. Say it's at (8,8). Then the correction angle would be 45 degrees. Whilst correct, in relaity the chances are the robot will over swing and start to thrash about.

So what I wanted to get to is something that I can use which will reqduce the correction angle as the target is approached - which is how I came to thinking about vector lengths. But I doubt that's going to work very well.

Regards

Mark

If your angle prediction is correct, you shouldn't have to adapt the robot's course all the time, unless there are obstacles involved. Having the length will help you stop moving once you reach 0.0, less than 0.0 or close-to-zero (given threshold).

There is little to no point in having a robot stop every N seconds (or whatever) just to blindly guess where its going at and accelerate like a chimp just to end up in a place where it'll have to correct again, and again...

Aren't you over thinking this? handle your way-points as if they were the final destination point. Although the only time when that's true is when there are no way-points left to visit.

Gather destination data
Calculate angle required
Move until the distance from your current endpoint and the destination endpoint is equal or less than 0.0
If there are any other points to visit, repeat. else, we're there.

Calculating the distance between two endpoints is very easy:
distance = sqr((x1-x2)^2 + (y1-y2)^2)
(x1|y1 is point A and x2|y2 is point B)

That is the way I think of it. The Path planner has to be called regularly as you can't be sure that the robot is still following the path (Drift, slightly different wheel speeds etc etc). The Map changes over time also - obstacles come and go. So it needs to ensure it's going where it thinks it's going in the context of it's current environement.

Quote:Original post by markgame66


Given this:
2 cartesian points on a grid(Map): (1,1) and (9,9).

As the robot progresses along the path the heading may change (Drifts off the path +5 degrees here -10 degree there to say in line with point (9,9)). Problems happen as it approachs ... on the grid. ... at (8,8). Then the correction angle would be 45 degrees.

So what I wanted ... will reqduce the correction angle as the ... approached -...

Mark

Hi Mark,
I think you have the right idea you just need to think that computers do exactly what their told to do. Try to use a approximation. actual grid(3.2,5.4) robot travels with (3,5) the detail of the end result is the min for correction, its close enough thought. This should stop some of the thrashing when it approaches the destination.

If your trying to calculate the mag. angle for correction path (from what I have read) you need a base degree from the robot to state that it is traveling at zero or 90 degree's while in motion. Using approximation the travel error must be corrected every so often (your drift); over correction is in play cut the correction then by half or 3/4, over time traveled. The closer to the target the less you should have to correct due to base and relative grid.

When you have reached your destination then the new exact coordinates are then required for calculation and new destination, traveling is used on whole integers calculation are floating points integers it depends what you use for grids?

Hope this helps for you idea what your looking for.

Not to feed the fire... but what's wrong with his use of vector? I'm not nearly as mathematically inclined as many who have defined it here... but I know that a vector can be a list of numbers/1 dimensional array (thus, I assume, the idea behind the naming of std::vector), a mangitude and direction (commonly represented by a line segment), or even just a direction sometimes (and I'm sure there are more mathematical "vectors").

It just depends on the usage, and they are all still related in a sense. I can agree that most definitions that were given were right... but why try to say the other ones are wrong (unless of course I am wrong)?

[edit] Most programmers use things like Vector3 and Vector2 and Vector4 with special operations defined to operate on these... but they usually turn out to be a list of 2, 3, or 4 numbers... so why not use them as points when it makes sense and vectors (the direction/magnitude kind) when it makes sense? I think the biggest issue is the fact that vectors can be many things, and unlike most other words with mulitple definitions, those many things are pretty closely related.

------------------------------

makegame: interesting problem. The problem with your solution I think is the same though. You're trying to compensate for overshooting, but what if you undershoot? You can't really control the drift of things like your wheels in software right? Maybe it would help to sort of log how much the robot is "off" when you recalculate, and use these to help determine how much to turn, the closer it gets to the destination. I think just using the distance by itself won't be enough.

Cheers
-Scott

I allow the robot to be out + or - 5 degrees (Quite a lot really) before the path planner re-calculates the heading. So for a heading of 45 deg then anything between 40 and 50 is "okay". An it is as the path planner corrects the heading. Problem is tuning that correction angle as it gets closer to the way point.

I tried the the vector length last night (Well the decimal proportion of). Whilst technically it decreases the value, it's too harsh.

What I want is something to scale that correction angle. A potential function method (the Bellman value function) was mentioned by Emergent on a previous post. But I've no idea where to start with this. Not much I've found of use on the web....

Mark

Hmmm....

If there are uncontrolled variables... I can't imagine how you'll ever get it "right". Why not, instead, correct towards that point, but allow the robot a certain radius to the point where it will be "correct". In other words, when you calculate and recalculate your heading, don't adjust what you find out... just always shoot for the destination point. I think the problem is that it never arrives exactly at that destination point so it starts freaking out. Give it a small radius so that when it's within that distance from the destination point, it considers itself to be where it needs to be...

In fact... the closer it gets, I would think the more you would allow the angle to vary. From the farthest away, perhaps it can deviate by 5 degrees. But once it's 1 unit away from the destination (the distance of the 2 vectors or points), it should be allowed to deviate by, say, 20 degrees or something. This will keep it from freaking out, and with having a little room (just a little) to determine that it has reached the destination... it will be ready to go the next step.