# Distance Between Two Vectors?

## Recommended Posts

Hi If I want to know the distance between two vectors is it just simply V1.length - v2.length? Seem to simple somehow Cheers Mark

##### Share on other sites
It's (v1 - v2).length

##### Share on other sites
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

##### Share on other sites
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

##### Share on other sites
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!

##### Share on other sites
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?

##### Share on other sites
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"

##### Share on other sites
Quote:
 Original post by Rockoon1A 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.

##### Share on other sites
Quote:
Original post by Ezbez
Quote:
 Original post by Rockoon1A 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.

##### Share on other sites
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...

##### Share on other sites
Quote:
Original post by Ezbez
Quote:
 Original post by Rockoon1A 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 EzbezIf 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.

##### Share on other sites
Quote:
 Original post by markgame66I 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).

##### Share on other sites
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

##### Share on other sites

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)

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by markgame66Given 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.

##### Share on other sites
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)?

 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

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by markgame66Problem 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.

Ok I think popsoftheyear dumbed what I had said a lot sorry to confuse people tried to make it simple. I went back to the books; 3 Calculus book and 2 physics books said the same thing (issues need to be answered), Planar and scalar version of vectors. Just want to get some facts straighten out.

What we need to know or know already:
1) We are talking about Planar vectors
2) in 2D grid based map view
3) real time issues and not discreate
4) computational adjustments from discreate(computer) to real time(real moving robot)
5) movement speed, how fast is fast and how slow is slow???

Problems:
Over correction based on turning radious calculation when close to target.

problem A: how close is close? 1 inch, 1 foot, 100 feet, 1/4 mile? (deals with the speed)
problem B: over turning,
Problem 1b: make adjustments to compensate over turning at speed ***.
Problem C: calculation is too fast when close to target compensation is to rapid.
Solution C: make a clock delay when target is in **** range. (based on speed)
Problem D: where are the corrdance (0,0) once the robot left the starting point.
Solution D: need the idea how you are moving along your axis x,y robot is (0,0), or robot follows a degree based travel plan from the map, and how to orentate the robot.

Tried:
Failed: re-calcuation broad range direction (in motion) from exact calculated magitude(way point).

Here are some of the problems to solutions to figure out again answers are based on distance (magitude), speed, acceleration and time, which we dont have.
I think if you get into the math of vectors too far your going to get into a math nightmare that will keep you awake at night. I still think you have the right idea for the vector problem its the re-calcuation to turning problem is the new issue.

##### Share on other sites
But why is there a need for a clock delay though before responding again though? The closer he gets to the destination, the robot will have the potential to diverge from the "straight path" faster as the angle will change quicker... so instead of cutting the correction but some factor based on the distance, why not allow for a greater drift (by angle, not distance...) which can be calculated according to some factor based on distance.

By the time the robot is less than a single unit away from the destination, it will be allowed to diverge by say 90 degrees from the original course... but it won't look like it diverged much at all, and by defining an answer to "problem a" (how close is close enough? 1 unit away? .1 units away?), it won't seem like it is going crazy once it approaches its destination.

Of course I'm just thinking about all this logically and have absolutely no experience actually working with such a thing... so take what I say with a grain of salt...

##### Share on other sites
ironhand69 - filling in some more details:

Each cell in the 2D grid represennts 4cm in the real world.
At the moment (This will change to smoother motion once I get this steeting solution sorted) the robot recieves a "MOVE_FORWARD" command ~once a second. If it finds it outside the allowable orientation (Measured with a Gyroscope) then it will steet left or right X degrees to correct.

Movement speed isn't realy relavant given the motion at the moment.

popsoftheyear - Things can get out of hand when within 2-3 cells from a way point.

I see what you're saying re allowing the diverge angle to change. But I think this equates to the same thing. i.e. what alg to use to allow that increase as distance to way point decreases.

[Edited by - markgame66 on December 3, 2008 7:14:14 AM]

##### Share on other sites
Quote:
 Original post by popsoftheyearBut why is there a need for a clock delay though before responding again though? The closer he gets to the destination, the robot will have the potential to diverge from the "straight path" faster as the angle will change quicker...

A clock will help keep a forward motion longer whether in a straight line or drifting off the direction of choice. It also slows down the pace of the process (the brain) from micro seconds to seconds or even mins if you need the time. The algorthm it self is a type of clock taking **** nano-seconds to process each instructions and then repeat. Things get complex when we switch from the analog world to the digital world and then back again.

Quote:
 Movement speed isn't realy relavant given the motion at the moment...

Ok, Think of it this way your driving a lawn tractor and a friend is driving a car and another friend is flying a plan at sub sonic speed, another friend is flying a jet super sonic. Who will have a smoother transaction the closer they reach the same exact destination? Who will have more time to compansate the change if drift is off.

you have a processor that is working at super sonic and travel time at snail pace. Its ok, we can do this.

A) now we have to say well over distance traveled or related time re-calculate your "new" mag. for direction maybe not compensate for travel path.

B)If we copensate direction were going to follow the path as a saw-tooth direction.

C) Have the process stop calculation with in 1 or 2 cm from destination and start recalculation for new direction. this may give enough (dought it) time to reach the destination and turn to new direction

D)Let me ask my Mentor on this you caught my interest on this topic and this deals with things we sometimes run into implementing software to hardware.

##### Share on other sites
Quote:
Original post by ironhand69
Quote:
 Original post by markgame66Given 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

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.

I had a long talk with my Mentor on this one, with the information I had. He stated the same thing I was talking about except he used:
fuzzy logic< /a>
Fuzzy logic
here is two sites that explain what fuzzy logic is about.

vector plotted and mag found(x,y,*map_corr,*end_point){
map corr [5.68,6.89]
end_point_checking[a]= map corrdanates entered.roundup[0] //double to int covertion
end_point_checking[b]= map corrdanates entered.roundup[1] //double to int covertion
***other stuff happens***

final result for travel is:
end_points_checking[6,7]

Use are we at grid logic;
check
x = convert.int(double end_point[0]);
y = convert.int(doulbe end_point[1]);
if (x = end_points_checking[0] and y = end_point_checking[1]){
stop travel;
if (x < end...checking[0]+ 5){
if (y < ... same as x idea){}
};
/////////////////////////////
its just the idea what Im talking about,,(I hope) my high level programming is quite shaky right now.

Question was brought up:
if you only have a map tick in integers how do I get it to form a double.

Answer was: two counters count upper ticks and count lower ticks
upper ticks 1 tick = 10 lower ticks// it could be any thing you want 2,5,10 etc.
lower ticks 1 tick = map sector in cm

***Post this see if it needs changes in a min***>

[Edited by - ironhand69 on December 4, 2008 4:41:42 PM]

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628282
• Total Posts
2981820

• 9
• 10
• 11
• 17
• 15