I'm building an autonomous quad copter I'm trying to move the quad to a target GPS co-ordinate, I'm calculating the distance of the target using haversine formula, and now I want to calculate the heading.
For example, I want the quad to turn to the direction of the target and move forward until it reaches the destination (this part is already done).
How do I calculate the yaw so that it turns to the direction of target?
Calculating it using only the GPS co-ordinates is very inaccurate. If I use a magnetometer, the declination angle changes from place to place.
How do I calculate this? How does ardu pilot do this calculation?
One way to develop control algorithms that deal with inaccurate measures is to combine different measures by some sort of filtering. In that sense, your set point reference is built based on both GPS and magnetometer measures.
There are several ways to accomplish this task. Many applications use data fusion based on Kalman Filters. The general idea is that you are going to use a predictor (or state observer) to achieve a better estimate of the heading. I suggest some research on these topics: data fusion, Kalman filtering.
Here is an example:
http://scholarscompass.vcu.edu/cgi/viewcontent.cgi?article=4188&context=etd
Related
I'm building a system that receives a stream of live GPS coordinates, around every second or two. I would like to smooth out the visualisation of it so that the location doesn't jump too much when there is a less then accurate datapoint. I would also like to visualise the speed of the moving point, not just jump from one to another.
To do it I have implemented a Kalman filter that gets the coordinates and models speed and acceleration. This helps smooth out the curve but the output of a Kalman filter has the same rate of one data point per second. I thought I would be able to interpolate this by running the "predict" part of Kalman filter 60 times per second, while the update part would only be done when a new coordinate arrives.
However, it turns out this results in a non continuous function and there is a visual jump after a new update comes in.
How can I solve this problem? Is there an algorithm that would output a continuous smooth path while feeding it coordinate points?
Is there a way to divide an already- existing road network into a 2-D grid of equal sized cells?
I need to extract some information such as vehicle density, average speed,...etc. from each cell.
are there any libraries, tools, APIs or tutorials?
I am new to SUMO so any help would be appreciated.
The easiest way is probably to generate an fcd output (sumo --fcd-output) which gives coordinates for every vehicle and then aggregate the values in a simple script. Depending on the precision needed and the data volume you expect, you can also aggregate the output to edges (and to time intervals) in SUMO using the mean data output but then you will need to handle the case of edges which are in multiple cells yourself. There is some help in parsing a sumo network and sumo outputs in sumolib.
I have been exploring the GPS data mining literature esp. for problems like anomalous trajectory detection, time travel prediction, etc and one very common method I see is dividing the data or map into grids. Can any one please explain the logic of this? Are the coordinates euclidean in this case? Is grid decomposition really necessary?
I would be grateful if someone can also give/ quote some links or materials I should explore. I am new to this field, so please pardon me if the question is very obvious.
Thanks & Regards,
Lesnar
No they are not euclidean. But they don't have to be. The grids are not rectangles anymore, but can be treated as such for some operations.
If you create a lat/long grid, then each cell by means of meters is not rectangular. However it defines a zone where you add a counter, which has a clear inside/outside definition. And you can use cartesian operations (Rectangle.inside())
So the lat / lon span is constant for each cell, but not the longitudinal meters span, which shrinks by cos(latitude).
If one needs a grid with equal grid cells sizes by means of meters, then one
has to transform the geo coordinates before.
Currently I'm working on a little project just for a bit of fun. It is a C++, WinAPI application using OpenGL.
I hope it will turn into a RTS Game played on a hexagon grid and when I get the basic game engine done, I have plans to expand it further.
At the moment my application consists of a VBO that holds vertex and heightmap information. The heightmap is generated using a midpoint displacement algorithm (diamond-square).
In order to implement a hexagon grid I went with the idea explained here. It shifts down odd rows of a normal grid to allow relatively easy rendering of hexagons without too many further complications (I hope).
After a few days it is beginning to come together and I've added mouse picking, which is implemented by rendering each hex in the grid in a unique colour, and then sampling a given mouse position within this FBO to identify the ID of the selected cell (visible in the top right of the screenshot below).
In the next stage of my project I would like to look at generating more 'playable' terrains. To me this means that the shape of each hexagon should be more regular than those seen in the image above.
So finally coming to my point, is there:
A way of smoothing or adjusting the vertices in my current method
that would bring all point of a hexagon onto one plane (coplanar).
EDIT:
For anyone looking for information on how to make points coplanar here is a great explination.
A better approach to procedural terrain generation that would allow
for better control of this sort of thing.
A way to represent my vertex information in a different way that allows for this.
To be clear, I am not trying to achieve a flat hex grid with raised edges or platforms (as seen below).
)
I would like all the geometry to join and lead into the next bit.
I'm hope to achieve something similar to what I have now (relatively nice undulating hills & terrain) but with more controllable plateaus. This gives me the flexibility of cording off areas (unplayable tiles) later on, where I can add higher detail meshes if needed.
Any feedback is welcome, I'm using this as a learning exercise so please - all comments welcome!
It depends on what you actually want and what you mean by "more controlled".
Do you want to be able to say "there will be a mountain on coordinates [11, -127] with radius 20"? Complexity of this this depends on how far you want to go. If you want just mountains, then radial gradients are enough (just add the gradient values to the noise values). But if you want some more complex shapes, you are in for a treat.
I explore this idea to great depth in my project (please consider that the published version is just a prototype, which is currently undergoing major redesign, it is completely usable a map generator though).
Another way is to make the generation much more procedural - you just specify a sequence of mathematical functions, which you apply on the terrain. Even a simple value transformation can get you very far.
All of these methods should work just fine for hex grid. If artefacts occur because of the odd-row shift, then you could interpolate the odd rows instead (just calculate the height value for the vertex from the two vertices between which it is located with simple linear interpolation formula).
Consider a function, which maps the purple line into the blue curve - it emphasizes lower located heights as well as very high located heights, but makes the transition between them steeper (this example is just a cosine function, making the curve less smooth would make the transformation more prominent).
You could also only use bottom half of the curve, making peaks sharper and lower located areas flatter (thus more playable).
"sharpness" of the curve can be easily modulated with power (making the effect much more dramatic) or square root (decreasing the effect).
Implementation of this is actually extremely simple (especially if you use the cosine function) - just apply the function on each pixel in the map. If the function isn't so mathematically trivial, lookup tables work just fine (with cubic interpolation between the table values, linear interpolation creates artefacts).
Several more simple methods of "gamification" of random noise terrain can be found in this paper: "Realtime Synthesis of Eroded Fractal Terrain for Use in Computer Games".
Good luck with your project
We're building a GIS interface to display GPS track data, e.g. imagine the raw data set from a guy wandering around a neighborhood on a bike for an hour. A set of data like this with perhaps a new point recorded every 5 seconds, will be large and displaying it in a browser or a handheld device will be challenging. Also, displaying every single point is usually not necessary since a user can't visually resolve that much data anyway.
So for performance reasons we are looking for algorithms that are good at 'reducing' data like this so that the number of points being displayed is reduced significantly but in such a way that it doesn't risk data mis-interpretation. For example, if our fictional bike rider stops for a drink, we certainly don't want to draw 100 lat/lon points in a cluster around the 7-Eleven.
We are aware of clustering, which is good for when looking at a bunch of disconnected points, however what we need is something that applies to tracks as described above. Thanks.
A more scientific and perhaps more math heavy solution is to use the Ramer-Douglas-Peucker algorithm to generalize your path. I used it when I studied for my Master of Surveying so it's a proven thing. :-)
Giving your path and the minimum angle you can tolerate in your path, it simplifies the path by reducing the number of points.
Typically the best way of doing that is:
Determine the minimum number of screen pixels you want between GPS points displayed.
Determine the distance represented by each pixel in the current zoom level.
Multiply answer 1 by answer 2 to get the minimum distance between coordinates you want to display.
starting from the first coordinate in the journey path, read each next coordinate until you've reached the required minimum distance from the current point. Repeat.