Velocity = length / time
so why a vector (x, y, z) is used to represent it?
Technically speaking, length divided by time gives you the speed, not velocity. Speed doesn't tell you which direction you are travelling in, while velocity does. In a three dimensional space, in order to describe where you are going and how fast, you need to supply three values: the direction AND speed you are going in each of the three fundamental directions (normally called axes and referred to by x, y, and z). But you could refer to them as forward/backward, sideways, and up/down if you want. For example, if you are travelling at 5km/hour upwards, the vector could be (0,0,5). Travelling 5km/hour downwards, your speed is just the same but the vector would be (0,0,-5). Travelling at 5km/hour at a 45 degree angle forward, the SPEED along each of the x and z axex would be the square root of 5, so the vector would be (approximately) (2.2,0,2.2). And so on.
Because velocity is not "length/time". It is the first derivative of position. Position is a vector, and so its derivatives are also vectors.
Most likely to measure the change in three dimensional space for the object.
Magnitude of the vector should be the speed you expect, and as the object changes direction, the vector components will most likely change.
You would use a vector because you can have velocity in 3 dimensions. In other words, the 3D velocity is the combination of distance/time in all 3 dimensions. It might be better to name the variables xPrime, yPrime, and zPrime, so that the vector more clearly represents velocity, rather than position.
Perhaps it is the speed that the object is moving in each of the directions in a 3D space, doing it this way means that you can extrapolate a direction of movement, after all velocity is movement with a direction.
Related
I'm trying to track an object moving through space. The actual movement of the object should generally be fairly straight and even when not straight it should be smooth.
My measurements consist of the 3D coordinates of the object, the timestamp, as well as a 3x3 covariance matrix, but that's it. I do not have the velocity or acceleration (except insofar as it could be estimated from different position measurements).
Is it possible for me to use a Kalman filter with this data?
Yes.
I wouldn't bother faking up velocity observations as in effect the kalman filter will be doing that.
I'd guess you'd want position and velocity in the state vector; whether to have acceleration too is trickier; if the object is turning/accelerating slowly I'd first try not having acceleration in the state.
I've found that most of the work in implementing such filters goes into tuning, that is choosing, and perhaps adapting, the process-noise covariance matrix.
I have a camera with the coordinates x,y at height h that is looking onto the x-y-plane at a specific angle, with a specific field of view. I want to calculate the 4 corners the camera can see on the plane.
There is probably some kind of formula for that, but I can't seem to find it on google.
Edit: I should probably mention that I mean a camera in the 3D-Graphics sense. Specifically I'm using XNA.
I've had to do similar things for debugging graphics code in 3D games. I found the easiest way of thinking about it was creating the vectors representing the corners of the screen and then calculating the intersection with whatever relevant objects (in this case, a plane).
Take a look at your view-projection (or whatever your Camera's matrix stack looks like multiplied together) and realize the screen space they output to has corners with homogonized coordinates of (-1, -1), (-1, 1), (1, -1), (1, 1). Knowing this, you're left with one free variable and can solve for the vector representing the corner of the camera.
Although, this is a pain. It's much easier to construct a vector for each corner as if the camera isn't rotated or translated and then transform them by the view matrix to give you world space vectors. Then you can calculate the intersection between the vectors and the plane to get your four corners.
I have a day job, so I leave the math to you. Some links that may help with that, however:
Angle/Field of view calculations
Line plane intersection
ignoring lens distortions and assuming the lens is almost at the focal point then you just have a triangle formed by the sensor size and the lens, then the lens to the subject - similar trianlges gives you the size of the subject plane.
If you want a tilted object plane that's just a projection onto the perpendicular object plane
Im not sure how to use vectors correctly in game programming. I have been reading advanced game design with flash which shows you how to create a vector with a start point and endpoint and how to use that for games, for example the start point would be used for a characters position in a game and the x and y length would be used for velocity. But since I have started looking online I have found that vectors are usually just x and y with no start point or end point and a character would be moved by having a position vector and a velocity vector and acceleration vector. I have started creating my own vector class. And wondered what the reasons for and against each method are. Or is it completely not important?
Initially a vector means direction. Classical vector is used in physics to present a velocity so that the vector direction stands for the heading and the vector length is a speed.But in graphics vectors are used also to present position. So if you have some point, let's say, in 2d space noted by x ,y it remains point if you don't want to know in what direction it set relating to the origin which is usually a center of the coordinate system. In 2d graphics we deal with Cartesian coordinate system which has an origin in top left corner of the screen. But you can also have a direction of some vector relative to any other point in the space.That is why you have also vector operations like addition, subtracting ,dot product, cross product. All those help you to measure distances and angles between vectors. I would suggest you to buy a book on graphics programming. Most of them introduce an easy to grasp primer to vector math.And you don't need to write a vector class in AS 3.0 You have a generic one - Vector3d
I have a program that takes as input an array of lat/long points. I need to perform a check on that array to ensure that all of the points are within a certain radius. So, for example, the maximum radius I will allow is 100 miles. Given an array of lat/long (coming from a MySQL database, could be 10 points could be 10000) I need to figure out if they will all fit in a circle with radius of 100 miles.
Kinda stumped on how to approach this. Any help would be greatly appreciated.
Find the smallest circle containing all points, and compare its radius to 100.
It's easiest way for me to solve this is by converting the coordinates to (X,Y,Z), then finding the distance along a sphere.
Assuming Earth is a sphere (totally untrue) with radius R...
X = R * cos(long) * cos(lat)
Y = R * sin(long) * cos(lat)
Z = R * sin(lat)
At this point, you can approximate the distance between the points using the extension of the pythagorean theorem for threespace:
dist = sqrt((x1-x2)^2 + (y1-y2)^2 + (z1-z2)^2)
But to find the actual distance along the surface, you're going to need to know the angle subtended by the two points from the origin (center of the Earth).
Representing your locations as vectors V1 = (X1, Y1, Z1) and V2 = (X2, Y2, Z2), the angle is:
angle = arcsin((V1 x V2) / (|V1||V2|)), where x is the cross-product.
The distance is then:
dist = (Earth's circumference) * angle / (2 * pi)
Of course, this doesn't take into account changes in elevation or the fact that the Earth is wider at the equator.
Apologies for not writing my math in LaTeX.
The answer below involves pretending that the earth is a perfect sphere, which should give a more accurate answer than treating the earth as a flat plane.
To figure out the radius of a set of lat/lon points, you must first ensure that your set of points is "hemispherical", ie. all the points can fit into some arbitrary half of your perfect sphere.
Check out Section 3 in the paper "Optimal algorithms for some proximity problems on the Gaussian sphere with applications" by Gupta and Saluja. I don't have a specific link, but I believe that you can find a copy online for free. This paper is not sufficient to implement a solution. You'll also need Appendix 1 in "Approximating Centroids for the Maximum Intersection of Spherical Polygons" by Ha and Yoo.
I wouldn't use Megiddo's algorithm for doing the linear programming part of the hemisphericity testing. Instead, use Seidel's algorithm for solving Linear Programming problems, described in "Small-Dimensional Linear Programming and Convex Hulls Made Easy" by Raimund Seidel. Also see "Seidel’s Randomized Linear Programming Algorithm" by Kurt Mehlhorn and Section 9.4 from "Real-Time Collision Detection" by Christer Ericson.
Once you have determined that your points are hemispherical, move on to Section 4 of the paper by Gupta and Saluja. This part shows how to actually get the "smallest enclosing circle" for the points.
To do the required quadratic programming, see the paper "A Randomized Algorithm for Solving Quadratic Programs" by N.D. Botkin. This tutorial is helpful, but the paper uses (1/2)x^T G x - g^T x and the web tutorial uses (1/2)x^T H x + c^T x. One adds the terms and the other subtracts, leading to sign-related problems. Also see this example 2D QP problem. A hint: if you're using C++, the Eigen library is very good.
This method is a little more complicated than some of the 2D methods above, but it should give you more accurate results than just ignoring the curvature of the earth completely. This method also has O(n) time complexity, which is likely asymptotically optimal.
Note: The method described above may not handle duplicate data well, so you may want to check for duplicate lat/lon points before finding the smallest enclosing circle.
Check out the answers to this question. It gives a way to measure the distance between any two (lat,long) points. Then use a smallest enclosing circle algorithm.
I suspect that finding a smallest enclosing circle may be difficult enough on a plane, so to eliminate the subtleties of working with latitude and longitude and spherical geometry, you should probably consider mapping your points to the XY plane. That will introduce some amount of distortion, but if your intended scale is 100 miles you can probably live with that. Once you have a circle and its center on the XY plane, you can always map back to the terrestial sphere and re-check your distances.
If I have a series of points as longitude and latitude, how would I calculate the center of all of those points?
Geomidpoint covers 3 different methods for calculating this.
Several people have answered to take the mean of the latitudes and longitudes. This is sort of the right idea, but means are more complicated on the sphere.
The latitude/longitude representation is essentially artificial and has discontinuities (at the poles, and opposite the prime meridian if you aren't careful), so it taking means in it doesn't seem likely (to me) to have a sensible geometric interpretation. I think you need to do something like averaging vectors in earth-centered coordinates, and then normalizing the result to put it back on the sphere.
I hope someone with more experience in these matters can comment more concretely.
Don't just take averages.
You can convert to 3d coordinates, then take the average (of x,y, and z coords), then project it back onto the sphere and turn that back into lat/long.
The wikipedia page on spherical coordinates has conversion algorithms.
First off, you need to define which centre you're interested in. Take these two points:
A. .B
The centre is easy, it's halfway between them. Now add a third point:
A. C. .B
Is the centre still halfway between A and B or is it weighted towards A because of C? So is the centre the point nearest to all points or just the points on the enclosing polygon?
Also, as it's long/lat you're dealing with the points are on a surface of a sphere so the distance between long 0 and long 90 degrees is much greater at lat 0 than at lat 45 degrees.
You're probably looking for the centroid of the simple polygon defined by the points. There is information on how to calculate it for various geometries in that article.
Wolfram Alpha will do this for you if you ask the question in the following form:
centroid of polygon with vertices: (X, Y), (X, Y), (X, Y), (X, Y), (X, Y), etc.
Just remember to convert each "(X, Y)" into decimal form first.
Wolfram Alpha will return the answer in decimal form, which you can then copy and paste into Google Earth.
See Moe's answer, although if your points are distributed across the globe, you'll have to be satisfied that your center tends towards the Prime Meridian and not the International Date Line.