I'm writing an application for iphone4 and I'm taking values from the accelerometer to compute the current movement from a known initial position.
I've noticed a very strange behavior: often times when I walk holding the cellphone for a few meters and then I stop, I register a negative peak of overall velocity when the handset decelarates. How is that possible if I keep moving in the same direction?
To compute the variation in velocity I just do this:
delta_v = (acc_previous + acc_now)/2 * (1/(updating_frequency))
Say you are moving at a constant 10 m/s. Your acceleration is zero. Let's say, for the sake of simplicity, you sample every 1 second.
If you decelerate smoothly over a period of 0.1 seconds, you might get a reading of 100 m/s/s or you might not get a reading at all since the deceleration might fall between two windows. Your formula most likely will not detect any deceleration or if it does, you'll get two values of -50 m/s/s: (0 - 100) / 2 and then (-100 + 0) / 2. Either way you'll get the wrong final velocity.
Something similar could happen at almost any scale, All you need is a short period of high acceleration or deceleration that you happen to sample and your figures are screwed.
Numerical integration is hard. Naive numerical integration of a noisy signal will essentially always produce significant errors and drift (like what you're seeing). People have come up with all sorts of clever ways to deal with this problem, most of which require having some source of reference information other than the accelerometer (think of a Wii controller, which has not only an accelerometer, but also the thingy on top of the TV).
Note that any MEMS accelerometer is necessarily limited to reporting only a certain band of accelerations; if acceleration goes outside of that band, then you will absolutely get significant drift unless you have some way to compensate for it. On top of that, there is the fact that the acceleration is reported as a discrete quantity, so there is necessarily some approximation error as well as noise even if you do not go outside of the window. When you add all of those factors together, some amount of drift is inevitable.
Well if you move any object in one direction, there's a force involved which accelerates the object.
To make the object come to a halt again, the same force is needed in the exact opposite direction - or to be more precise, the vector of the acceleration event that happened before needs to be multiplied with -1. That's your negative peak.
Not strictly a programming answer, but then again, your question is not strictly a programming question :)
If it's going a thousand miles per hour, its acceleration is 0. If it's speeding, the acceleration is positive. If it's slowing down, the acceleration is negative.
You can use the absolute number of the velocity to invert any negative acceleration, if that's needed:
fabs(delta_v); // use abs for ints
Related
I'm making a soccer simulation game and for that I'm using normal 2DBody nodes for the players and ball. But I would like to be able to speed up the game, without breaking the physics and getting other results.
To speed up the game I found Engine.time_scale and Engine.iterations_per_second that affect the game speed.
So default values for timescale = 1 and for iterations_per_second = 60
By just setting time_scale = 0.5, physics seem to break. At least I can see, that it looks less natural than on normal speed.
When fasting up by setting time_scale = 0.5 and iterations per second = 120,
so physics don't seem to break.
But I can't really tell if this is 100% true. (Also 99% would be okay ;-) )
So does somebody know another way to speed up the game without breaking physics or can confirm, that modified time_scale and iterations per second don't break physics?
First of all, Godot documentation says:
float time_scale - Controls how fast or slow the in-game clock ticks versus the real life one. It defaults to 1.0. A value of 2.0 means the game moves twice as fast as real life, whilst a value of 0.5 means the game moves at half the regular speed.
So if you want to speed up the game time you should increase that value, not decrease. As far as I understand this value will influence how much time delta is passed to _physics_process(delta) methods (and other engines internal physics calculations), and time_scale works as a multiplayer for that value.
Physics engine runs with a fixed time step, so iterations_per_second will influence it as documentation mentions:
int iterations_per_second - The number of fixed iterations per second (for fixed process and physics).
Yes, modifying both values should give better results, because increasing iterations_per_second makes calculations of physics more frequent and that means more precise (let's call it "time detailing"). Could it still "break physics"? Yes, if physics calculations won't be fast enough to keep up with engine iteration frequency. In that case the only solution will be to optimize your game.
Most GPS systems report "accuracy" in units of meters, with the figure varying over orders of magnitude. What does this figure mean? How can it be translated to an error function for estimation, i.e. the probability of an actual position given the GPS reading and its reported accuracy?
According to the Wikipedia article on GPS accuracy, a reading down to 3 meters can be achieved by precisely timing the radio signals arriving at the receiver. This seems to correspond with the tightest error margin reported by e.g. an iPhone. But that wouldn't account for external signal distortion.
It sounds like an error function should have two domains, with a gentle linear slope out to the reported accuracy and then a polynomial or exponential increase further out.
Is there a better approach than to tinker with it? Do different GPS chipset vendors conform to any kind of standard meaning, or do they all provide only some kind of number for the sake of feature parity?
The number reported is usually called HEPE, Horizontal Estimated Position Error. In theory, 67% of the time the measurement should be within HEPE of the true position, and 33% of the time the measurement should be in horizontal error by more than the HEPE.
In practice, no one checks HEPE's very carefully, and in my experience, HEPE's reported for 3 or 4 satellite fixes are much larger than they need to be. That is, in my experience 3 satellite fixes are accurate to within a HEPE distance much more than 67% of the time.
The "assumed" error distribution is circular gaussian. So in principle you could find the right ratios for a circular gaussian and derive the 95% probability radius and so on. But to have these numbers be meaningful, you would need to do extensive statistical testing to verify that indeed you are getting around 95%.
The above are my impressions from working in the less accuracy sensitive parts of GPS over the years. Concievably, people who work on using GPS for aircraft landing may have a better sense of how to predict errors and error rates, but the techniques and methods they use are likely not available in consumer GPS devices.
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.
I am trying to write a simple game, but I'm stuck on what I think is simple physics. I have an object that at point 0,0,0 and is travelling at say 1 unit per second. If I give an instruction, that the object must turn 15 degrees per second , for 6 seconds (so it ends up 90 degrees right of it's starting position), and accelerate at 1 unit per second for 4 seconds (so it's final speed is 5 units per second), how do I calculate it's end point?
I think I know how to answer this for an object that isn't accelerating, because it's just a circle. In the example above, I know that the circumference of the circle is 4 * distance (because it is traversing 1/4 of a circle), and from that I can calculate the radius and angles and use simple trig to solve the answer.
However, because at any given moment in time the object is travelling slightly faster than it was in the previous moment, my end result wouldn't be a circle, it would be some sort of arc. I suppose I could estimate the end point by looping through each step (say 60 steps per second), but this sounds error prone and inefficient.
Could anybody point me in the right direction?
Your notion of stepping through is exactly what you do.
Almost all games operate under what's known as a "game tick". There are actually a number of different ticks that could be going on.
"Game tick" - each game tick, a set of requests are fired, AI is re-evaluated, and overall the game state has changed.
"physics tick" - each physics tick, each physical object is subject to a state change based on its current physical state.
"graphics tick" - also known as a rendering loop, this is simply drawing the game state to the screen.
The game tick and physics tick often, but do not need to, coincide with each other. You could have a physics tick that moves objects at their current speed along their current movement vector, and also applied gravity to it if necessary (altering its speed,) while adding additional acceleration (perhaps via rocket boosters?) in a completely separate loop. With proper multi-threading care, it would fit together nicely. The more de-coupled they are, the easier it will be to swap them out with better implementations later anyway.
Simulating via a time-step is how almost all physics are done in real-time gaming. I even used to do thermal modeling for the department of defense, and that's how we did our physics modelling there too (we just got to use bigger computers :-) )
Also, this allows you to implement complex rotations in your physics engine. The less special cases you have in your physics engine, the less things will break.
What you're asking is actually a Mathematical Rate of change question. Every object that is in motion has position locations of (x,y,z). If you are able to break down the component velocity and accelerations into their individual planes, your final end point would be (x1, y1, z1) which is the respective outcome of your equations in that plane.
Hope it helps (:
In a soccer game, I am computing a steering force using steering behaviors. This part is ok.
However, I am looking for the best way to implement simple 2d human locomotion.
For instance, the players should not "steer" (or simply add acceleration computed from steering force) to its current velocity when the cos(angle) between the steering force and the current velocity or heading vectors is lower than 0.5 because it looks as if the player is a vehicule. A human, when there is an important change of direction, slows down and when it has slowed enough, it starts accelerating in the new direction.
Does anyone have any advice, ideas on how to achieve this behavior? Thanks in advance.
Make it change direction very quickly but without perfect friction. EG super mario
Edit: but feet should not slide - use procedural animation for feet
This is already researched and developed in an initiative called "Robocup". They have a simulation 2D league that should be really similar to what you are trying to accomplish.
Here's a link that should point you to the right direction:
http://wiki.robocup.org/wiki/Main_Page
Maybe you could compute the curvature. If the curvature value is to big, the speed slows down.
http://en.wikipedia.org/wiki/Curvature
At low speed a human can turn on a dime. At high speed only very slight turns require no slowing. The speed and radius of the turn are thus strongly correlated.
How much a human slows down when aiming toward a target is actually a judgment call, not an automatic computation. One human might come to almost a complete stop, turn sharply, and run directly toward the target. Another human might slow only a little and make a wide curving arc—even if this increases the total length to the target. The only caveat is that if the desired target is inside the radius of the curve at the current speed, the only reasonable path is to slow since it would take a wide loop far from the target in order to reach it (rather than circling it endlessly).
Here's how I would go about doing it. I apologize for the Imperial units if you prefer metric.
The fastest human ever recorded traveled just under 28 mph. Each of your human units should be given a personal top speed between 1 and 28 mph.
Create a 29-element table of the maximum acceleration and deceleration rates of a human traveling at each whole mph in a straight line. It doesn't have to be exact--just approximate accel and decel values for each value. Create fast, medium, slow versions of the 29-element table and assign each human to one of these tables. The table chosen may be mapped to the unit's top speed, so a unit with a max of 10mph would be a slow accelerator.
Create a 29-element table of the sharpest radius a human can turn at that mph (0-28).
Now, when animating each human unit, if you have target information and must choose an acceleration from that, the task is harder. If instead you just have a force vector, it is easier. Let's start with the force vector.
If the force vector's net acceleration and resultant angle would exceed the limit of the unit's ability, restrict the unit's new vector to the maximum angle allowed, and also decelerate the unit at its maximum rate for its current linear speed.
During the next clock tick, being slower, it will be able to turn more sharply.
If the force vector can be entirely accommodated, but the unit is traveling slower than its maximum speed for that curvature, apply the maximum acceleration the unit has at that speed.
I know the details are going to be quite difficult, but I think this is a good start.
For the pathing version where you have a target and need to choose a force to apply, the problem is a bit different, and even harder. I'm out of ideas for now--but suffice it to say that, given the example condition of the human already running away from the target at top stpeed, there will be a best-time path that is between on the one hand, slowing enough while turning to complete a perfect arc to the target, and on the other hand stopping completely, rotating completely and running straight to the target.