Distance Between Two Vectors?

It's (v1 - v2).length

We just covered this in linear algebra and here are the forumlas for vectors in any dimension:

Euclidean distance
In mathematics, the Euclidean distance or Euclidean metric is the "ordinary" distance between two points that one would measure with a ruler, which can be proven by repeated application of the Pythagorean theorem. By using this formula as distance, Euclidean space becomes a metric space (even a Hilbert space). The associated norm is called the Euclidean norm.

Incorrect , that is the lenght of a vector .
Without specifing the metrix used , your question is vague.
I suppose you want to compute the distance beetween two oriented vectors don't you ?
There are 2 ways
the first is to compute the distance using the application point of these 2 vectors, the other is finding the closest point on segments using the direction vectors.
Its up to you to use this methods to your benefit.
Elaborate more deeply yout problem if you want a correct answer

Hi thanks for you replies,

Basically I have two vectors. 1) Is the current location of my robot, the other is it's way point. I want to work out the distance between the two.

So that I can work out hoe close the robot is to it's Way Point. I'm trying to find a solution to a problem where the steering command makes the robot thrash about as it approaches the way point. So I thought if I knew the distance between them then I'd have something to tune the steering cmd with

Thanks

Mark

You should do it the way Erik Rufelt mentioned:

Subtract the second vector from the first, and then compute the length of the resulting vector:

float calcdist(vector3d v1, v2)
{
v.x = v1.x - v2.x;
v.y = v1.y - v2.y;
v.z = v1.z - v2.z;
return sqrt(v.x*v.x + v.y*v.y + v.z*v.z);
}

Hope this helps!

To explain why your original question was ambiguous:

A vector has a start point and an end point. How can you find the distance between a four points? However, most of the time the starting point is not used, and is assumed to be the origin (this is probably the way your vector class works, and the way you think about vectors). In that context, it still doesn't make sense, but you could have asked for the distance between the two end points.

Equally valid interpretation of your original question could have been:
What is the distance between the two start points?
What is the minimum distance between the two line segments going from the start point and end point of each vector?

Quibbling a bit here..

A vector is not a point, nor is a vector 2 points.

A vector is a direction and magnitude.

Most game programmers use their vector type for both vectors and points, but in the math world thats actualy a big no-no.

vector = vector + vector
vector = vector - vector
vector = point - point
vector = vector * scaler
vector = vector / scaler

point = point + vector
point = point - vector

now, 'point + point' does not yield a vector, nor does it yield a point. The same goes for 'point * scaler' and so on.

In the math world if you asked what the distance is between two vectors, you would most likely get an ANGLE as an answer.

"Those two vectors are 15 degrees apart"

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. (I guess the actual terms are initial point and terminal point. Or tail and head.) point + point of course does not yield a vector, it makes no sense to add points. It also doesn't make sense to subtract points, and I think a particularly pedantic mathematician would say that is no more valid than adding points and getting a vector.

If a mathematician gave me an angle when I asked for a distance, I would have scoffed. Perhaps I am wrong, but an angle does not give distance. Any reasonable mathematician would have balked at that question and said it was extremely ambiguous. My post was to clarify why it was ambiguous.

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. (I guess the actual terms are initial point and terminal point. Or tail and head.)

No.
A vector is something that behaves like a vector from an algebraic point of view, no points are involved. When we have vectors we can introduce "points" in our algebraic toybox as something that can be summed to vectors to get other points in a way that, for some popular vector spaces, gives affine spaces that match our geometric intuition.

What has an initial point and a terminal point is the line segment, which is not a vector because it cannot be summed meaningfully to other segments.
Instead of addition, multiplication by a scalar and other arithmetic with coordinates, geometric loci like segments, being sets of points, have set operations.
Less philosophically, both n-dimensional vectors and n-dimensional points are uniquely represented by n numbers, while a line segment is determined by its two endpoints which amount to 2n numbers: it cannot be a vector.

Quote:

point + point of course does not yield a vector, it makes no sense to add points. It also doesn't make sense to subtract points, and I think a particularly pedantic mathematician would say that is no more valid than adding points and getting a vector.

There is a substantial difference, which you seem to miss, between subtracting and adding points: subtracting points gives vectors by definition, adding points is nonsensical.

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.

Quote:

Original post by markgame66 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).

This explanation isn't very clear, as there are two separate state variables that you want to control: the robot's position and its facing. You also have two separate control outputs: applying an acceleration (presumably constrained to its facing) and a torque.
If you don't care about the robot's facing at waypoints or at its destination, it should simply turn towards the next waypoint without "moving too fast".
How fast is too fast? You can simply check the angle between two vectors: the robot's velocity and the difference between the waypoint and the robot's position: if its absolute value is decreasing, speed is appropriate; if it's increasing, the robot is worsening the error by running in a wrong direction more than it can compensate by turning.
Meanwhile, that same angle should be used to control steering (turn left if the waypoint is on the left of current velocity and vice versa) with a tasteful PID controller or something similar (presumably with a limited torque output).

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.