The issue I have is that I'm attempting to add drag to an object in this basic physics simulation (Java [Processing]), but once I add the appropriate formula, it causes the objects velocity to increase drastically in the opposite direction. Of course the problem is that drag for some reason is being calculated too high but I'm not sure why thats happening as I'm using the real world equation.
void setup(){size(1280,720);}
class Circle{
float x,y,r,m,dx,dy,ax,ay,fx,fy;
Circle(float xPos, float yPos, float Radius, float Mass){
x = xPos;
y = yPos;
r = Radius;
m = Mass;
}
void ADD_DRAG(){
fx -= 0.5 * 1.225 * dx * dx * 0.5 * r * PI;
fy -= 0.5 * 1.225 * dy * dy * 0.5 * r * PI;
}
void update(){
ADD_DRAG();
ax = fx / m;
ay = fy / m;
dx += ax / frameRate;
dy += ay / frameRate;
x += dx / frameRate;
y += dy / frameRate;
}
}
Circle[] SceneObjects = {new Circle(50,50,20,20000),new Circle(50,50,2,20)};
void draw(){
background(51);
for (Circle c : SceneObjects){
c.update();
circle(c.x * 3,c.y * 3,c.r * 3);
}
}
void mouseClicked(){
if(SceneObjects[1].fx != 2000)
SceneObjects[1].fx = 2000;
else
SceneObjects[1].fx = 0;
}
This is the code, essentially there is a Circle class which stores the objects properties and then the forces applies are updated each draw loop. The mouseClicked void is just for testing by adding a force to the objects. All and any help is appreciated, thanks!
Maths I am Using:
Rearranged F=ma for ax = fx / m;
Acceleration * time = Speed for dx += ax / frameRate; (frameRate is 1/time)
Distance = Speed * time = for x += dx / frameRate; (same as above)
For drag im using this equation https://www.grc.nasa.gov/WWW/K-12/rocket/drageq.html with the constants eg air density etc added as seen.
There are a couple of things wrong here.
You haven't given us numbers (or a minimal complete example), but the vector algebra is off.
Yes, the acceleration is f = -kv2, and |v|2 = vx2 + vy2, but that doesn't mean that you can decompose f into fx=kvx2 and fy=kvy2. Not only is your magnitude off, but your acceleration is now not (in general) aligned with the motion; the path of your projectile will tend to curve toward a diagonal between the axes (e.g. x=y).
Also, your code always gives acceleration in the negative x and negative y directions. If your projectile happens to start out going that way, your version of air resistance will speed it up.
Finally, your time interval may simply be too large.
There is a better way. The differential equation is v' = -k v|v|, and the exact solution is v = (1/kt) z, (with appropriate choice of the starting time) where z is the unit direction vector. (I don't know how to put a caret over a letter.) This leads to v(t) = (1/t)v(t=1.0)
So you can either work out a fictional time t0 and calculate each new velocity using 1/(kt), or you can calculate the new velocity from the previous velocity: vn+1 =vn/(kd vn + 1), where d is the time interval. (And then of course you have to decompose v into vx and vy properly.)
If you're not familiar with vector algebra, this may seem confusing, but you can't get an air-resistance sim to work without learning the basics.
I've been struggling for some time now on how to correctly calculate the yaw angle from an IMU, but can't get it to work. I'm using the LSM9DS1, if that matters.
I already have proper values for roll and pitch. The value for yaw is also more or less correct until I start tilting the device. Therefore I have to implement some kind of tilt compensation.
I calculate the euler angles as follows:
double weight = 0.05f;
private void calculateEulerAngles() {
// Measured angle by the accelerometer
double rollXLMeasured = Math.atan2(this.accelerometer.getX(), this.accelerometer.getZ()) / 2 / Math.PI * 360;
double pitchXLMeasured = Math.atan2(this.accelerometer.getY() / 9.81f, this.accelerometer.getZ() / 9.81f) / 2 / Math.PI * 360;
// Adding a low pass filter
double rollXLFiltered = (1 - this.weight) * rollXLFilteredOld + this.weight * rollXLMeasured;
double pitchXLFiltered = (1 - this.weight) * pitchXLFilteredOld + this.weight * pitchXLMeasured;
this.rollXLFilteredOld = rollXLFiltered;
this.pitchXLFilteredOld = pitchXLFiltered;
// Calculating deltaTime
long time = System.nanoTime();
int difference = (int) ((time - this.deltaTime) / 1000000000);
this.deltaTime = time;
// Adding a complementary filter
this.roll = ((1 - this.weight) * (this.roll + this.gyroscope.getY() * difference)) + (this.weight * rollXLMeasured);
this.pitch = ((1 - this.weight) * (this.pitch - this.gyroscope.getX() * difference)) + (this.weight * pitchXLMeasured);
// Calculating yaw using the magnetometer and applying a low pass filter
double rollRadians = this.roll / 360 * (2 * Math.PI);
double pitchRadians = this.pitch / 360 * (2 * Math.PI);
double magnetometerXCompensated = (-this.magnetometer.getX() * Math.cos(rollRadians)) - (this.magnetometer.getY() * Math.sin(pitchRadians) *
Math.sin(rollRadians)) + (this.magnetometer.getZ() * Math.cos(pitchRadians) * Math.sin(rollRadians));
double magnetometerYCompensated = (this.magnetometer.getY() * Math.cos(pitchRadians)) + (this.magnetometer.getZ() * Math.sin(pitchRadians));
double yawMeasured = Math.atan2(magnetometerYCompensated, magnetometerXCompensated) / (2 * Math.PI) * 360;
double yawFiltered = (1 - this.weight) * yawFilteredOld + this.weight * yawMeasured;
this.yawFilteredOld = yawFiltered;
this.yaw = yawFiltered;
// Print roll, pitch and yaw for debug purposes
System.out.println(this.roll + ", " + this.pitch + ", " + this.yaw);
}
I don't include the whole code I use, since I think it's clear what the above code does and this is the part thats essential to the problem, I suppose.
And again, I get correct values, just not for yaw when I tilt the device. So there has to be an error concerning the math.
Do I have to do my calculations with the raw values, like the data thats inside the IMU, or use already processed data? For example this.accelerometer.getX() actually returns x_raw * 0.061f / 1000 * 9.81f with x_raw being the value stored inside the IMU and 0.061f being some coeffiecent. I basically copied the calculation from the Adafruit library, I'm not 100% sure why you have to multiply/divide those values though.
Also, you might have noticed that when I calculate the magnetometerXCompensated value I invert the x-axis. I do this, because the magnetometer axis aren't aligned with the acceleromter/gyroscope axis, so in order to align them I have to flip the x-axis.
Does anyone have an idea on how to solve this? I'm really tired of it not working properly, since I tried for quite a while now to solve it, but I'm not getting the results I wanted.
You can get all the equations from the next picture. The complimentary/Kalman filter is there in order to get less noise.
Wrote a function that calculates the coordinates of a sprite that moves in a circle.
Well, the formula is elementary
x = x0 + R * cos (t * a + a0)
y = y0 + R * sin (t * a + a0)
The function looks like this
public void pointDefinition(float delta)
{
sprite.setPosition(Gdx.graphics.getWidth()/2+(85*(float)Math.cos(i*delta)), Gdx.graphics.getHeight()/2+(85*(float)Math.sin(i*delta)));
i = i + 0.5;
}
I call it in render ()
In the end, everything works, but the sprite somehow nervously twitches.
Here is a video that demonstrates this.
video
The following content is sent to the delta variable.
pointDefinition(Math.min(Gdx.graphics.getDeltaTime(), 1 / 60f));
I can not understand the reason
You should increment i with delta instead of using delta as a parameter in the formula:
public void pointDefinition(float delta)
{
sprite.setPosition((Gdx.graphics.getWidth() / 2) + (85 * (float)Math.cos(i)), (Gdx.graphics.getHeight() / 2) + (85 * (float)Math.sin(i)));
i = i + delta;
}
After all, delta will have different values each time, which is what is causing your little icon to move back sometimes.
To understand what is happening, imagine these two iterations:
First iteration
i = 2
delta = 0.0025
In this case, i * delta will be 0.005.
Second iteration
i = 2.5
delta = 0.0017
In this case, i * delta will be 0.00425.
As you can see, the value of i * delta, which you are using as the parameter of Math.sin() and Math.cos(), decreased in the second iteration, causing your icon to jitter.
To keep the animation consistent, it is important to make sure the parameter you pass to these two functions (Math.sin() and Math.cos()) only increases with each iteration!
I'm just trying to code a nice looking physics game.
The ball collision looks nice but if the balls are colliding too slow, they "stick" in each other. I have no clue why they do.
Here's my collision function:
private void checkForCollision(ArrayList<Ball> balls) {
for (int i = 0; i < balls.size(); i++) {
Ball ball = balls.get(i);
if (ball != this && ball.intersects(this)) {
this.collide(ball, false);
}
}
}
public boolean intersects(Ball b) {
double dx = Math.abs(b.posX - posX);
double dy = Math.abs(b.posY - posY);
double d = Math.sqrt(dx * dx + dy * dy);
return d <= (radius + b.radius);
}
private void collide(Ball ball, boolean b) {
double m1 = this.radius;
double m2 = ball.radius;
double v1 = this.motionX;
double v2 = ball.motionX;
double vx = (m1 - m2) * v1 / (m1 + m2) + 2 * m2 * v2 / (m1 + m2);
v1 = this.motionY;
v2 = ball.motionY;
double vy = (m1 - m2) * v1 / (m1 + m2) + 2 * m2 * v2 / (m1 + m2);
if (!b)
ball.collide(this, true);
System.out.println(vx + " " + vy);
motionX = vx * BOUNCEOBJECT;
motionY = vy * BOUNCEOBJECT;
}
But this is what happens when they collide with a low speed:
So do you have an idea?
EDIT:
The update of Alnitak works very nice... but one problem is still there... if i add gravity like this:
public void physic() {
motionY += GRAVITY; // <= this part (GRAVITY is set to 0.3D)
checkForCollision(screen.balls);
keyMove();
bounceWalls();
posX += motionX;
posY += motionY;
}
They still move into each other. I think this is the wrong way to add gravity, or isn't it?
And I think I did something wrong with the collision formula, because they don't fall right:
!
and then they slowly sink into the ground.
EDIT:
found an AMAZING tutorial: http://www.ntu.edu.sg/home/ehchua/programming/java/J8a_GameIntro-BouncingBalls.html
This is a common problem that happens because sometimes the delta-v of the bouncing ball is insufficient to take it back out of the collision zone.
So the collision routine reverses the direction again, taking it back inside the other ball, ad-infinitum.
You should add a sufficient offset (in the direction of the collision force) to the position of the ball to ensure that the newly calculated positions are no longer colliding.
Alternatively, check whether the balls would collide once you add the new motion values:
public boolean intersects(Ball b) {
double dx = b.posX - (posX + motionX); // no need for Math.abs()
double dy = b.posY - (posY - motionY);
double d = dx * dx + dy * dy; // no need for Math.sqrt()
return d < (radius + b.radius) * (radius + b.radius);
}
but you should also change ball.intersects(this) to intersects(ball).
They may appear to collide slightly too early, but on a fast moving ball it probably won't be visible.
(m1 - m2) * v1 / (m1 + m2) + 2 * m2 * v2 / (m1 + m2);
This has an integer value 2. Please make it 2.0f or 2.0d then check it out. It must be the problem for small speeds. Becuse integer constant autocasts multiplied doubles.
If this does not work, then Alnitak 's answer would be helpful.
If you need real nice physics, you should use the force then convert it to velocity then convert it to displacement . Look at integrator techniques like Runge Kutta and Euler Integration
Force-->acceleration-->velocity-->displacement
if collision occurs, just update the force then the rest will be flowing.
----> http://codeflow.org/entries/2010/aug/28/integration-by-example-euler-vs-verlet-vs-runge-kutta/ <-----
http://www.forums.evilmana.com/game-programming-theory/euler-vs-verlet-vs-rk4-physics/
http://www.newagepublishers.com/samplechapter/001579.pdf
http://cwx.prenhall.com/bookbind/pubbooks/walker2/
Verlet integration is a point between Runge-Kutta-4 and Euler Integration preferably for molecular dynamics (a good example for bouncing balls if you ommit the electrical fields and bonds)
Just found an AMAZING tutorial:
http://www.ntu.edu.sg/home/ehchua/programming/java/J8a_GameIntro-BouncingBalls.html
Is there an easy way to convert an angle (in degrees) to be between -179 and 180? I'm sure I could use mod (%) and some if statements, but it gets ugly:
//Make angle between 0 and 360
angle%=360;
//Make angle between -179 and 180
if (angle>180) angle-=360;
It just seems like there should be a simple math operation that will do both statements at the same time. I may just have to create a static method for the conversion for now.
// reduce the angle
angle = angle % 360;
// force it to be the positive remainder, so that 0 <= angle < 360
angle = (angle + 360) % 360;
// force into the minimum absolute value residue class, so that -180 < angle <= 180
if (angle > 180)
angle -= 360;
Try this instead!
atan2(sin(angle), cos(angle))
atan2 has a range of [-π, π). This takes advantage of the fact that tan θ = sin θ / cos θ, and that atan2 is smart enough to know which quadrant θ is in.
Since you want degrees, you will want to convert your angle to and from radians:
atan2(sin(angle * PI/180.0), cos(angle * PI/180.0)) * 180.0/PI
Update
My previous example was perfectly legitimate, but restricted the range to ±90°. atan2's range is the desired value of -179° to 180°. Preserved below.
Try this:
asin(sin(angle)))
The domain of sin is the real line, the range is [-1, 1]. The domain of asin is [-1, 1], and the range is [-PI/2, PI/2]. Since asin is the inverse of sin, your input isn't changed (much, there's some drift because you're using floating point numbers). So you get your input value back, and you get the desired range as a side effect of the restricted range of the arcsine.
Since you want degrees, you will want to convert your angle to and from radians:
asin(sin(angle * PI/180.0)) * 180.0/PI
(Caveat: Trig functions are bazillions of times slower than simple divide and subtract operations, even if they are done in an FPU!)
This works with both negative and decimal numbers and doesn't require loops, nor trigonometric functions:
angle -= Math.floor(angle / 360 + 0.5) * 360
The result is in the [-180, 180) interval. For (-180, 180] interval, you can use this instead:
angle -= Math.ceil(angle / 360 - 0.5) * 360
Not that smart, too, but no if.
angle = (angle + 179) % 360 - 179;
But I am not sure how Java handles modulo for negative numbers. This works only if -1 modulo 360 equals 359.
UPDATE
Just checked the docs and a % b yields a value between -(|b| - 1) and +(|b| - 1) hence the code is broken. To account for negative values returned by the modulo operator one has to use the following.
angle = ((angle + 179) % 360 + 360) % 360 - 179;
But ... no ... never ... Use something similar to your initial solution, but fixed for values smaller then -179.
I know that years have passed, but still.
This solution contains no loops, no subtracting, no modulo (allows to normalize to radians interval). Works for any input, including negative values, big values, edge cases.
double normalizedAngle = angle - (ceil((angle + M_PI)/(2*M_PI))-1)*2*M_PI; // (-Pi;Pi]:
double normalizedAngle = angle - (ceil((angle + 180)/360)-1)*360; // (-180;180]:
double normalizedAngle = angle - (floor((angle + M_PI)/(2*M_PI)))*2*M_PI; // [-Pi;Pi):
double normalizedAngle = angle - (floor((angle + 180)/360))*360; // [-180;180):
I'm a little late to the party, I know, but...
Most of these answers are no good, because they try to be clever and concise and then don't take care of edge cases.
It's a little more verbose, but if you want to make it work, just put in the logic to make it work. Don't try to be clever.
int normalizeAngle(int angle)
{
int newAngle = angle;
while (newAngle <= -180) newAngle += 360;
while (newAngle > 180) newAngle -= 360;
return newAngle;
}
This works and is reasonably clean and simple, without trying to be fancy. Note that only zero or one of the while loops can ever be run.
Maybe not helpful, but I always liked using non-degree angles.
An angle range from 0 to 255 can be kept in bounds using bitwise operations, or for a single byte variable, simple allowed to overflow.
An angle range from -128 to 127 isn't quite so easy with bitwise ops, but again, for a single-byte variable, you can let it overflow.
I thought it was a great idea many years back for games, where you're probably using a lookup table for angles. These days, not so good - the angles are used differently, and are float anyway.
Still - maybe worth a mention.
A short way which handles negative numbers is
double mod = x - Math.floor((x + 179.0) / 360) * 360;
Cast to taste.
BTW: It appears that angles between (180.0, 181.0) are undefined. Shouldn't the range be (-180, 180] (exclusive, inclusive]
Here is an integer-only solution:
int normalize(int angle)
{
angle %= 360;
int fix = angle / 180; // Integer division!!
return (fix) ? angle - (360 * (fix)) : angle;
}
Sometimes being clever is just more fun, Platinum Azure.
I have made a formula for orientation of circular values
to keep angle between 0 and 359 is:
angle + Math.ceil( -angle / 360 ) * 360
but to keep between -179 to 180 formula can be:
angle + Math.ceil( (-angle-179) / 360 ) * 360
this will give its orientation shift about -179 keeping actual angle intact
generalized formula for shifting angle orientation can be:
angle + Math.ceil( (-angle+shift) / 360 ) * 360
Well, one more solution, this one with just one division and no loops.
static double normalizeAngle(double angle)
{
angle %= 360.0; // [0..360) if angle is positive, (-360..0] if negative
if (angle > 180.0) // was positive
return angle - 360.0; // was (180..360) => returning (-180..0)
if (angle <= -180.0) // was negative
return angle + 360.0; // was (-360..180] => returning (0..180]
return angle; // (-180..180]
}
How about
(angle % 360) - 179
This will actually return different results than the naive approach presented in the question, but it will keep the angle between the bounds specified. (I suppose that might make this the wrong answer, but I will leave it here in case it solves another persons' similar problem).
int angle = -394;
// shortest
angle %= 360;
angle = angle < -170 ? angle + 360 : (angle > 180 ? angle - 380 : angle);
// cleanest
angle %= 360;
if (angle < -179) angle += 360;
else if (angle > 180) angle -= 360;
It is better to use library functions. They handle special cases like NaN and infinities.
public static double normalizeAngleDegrees(double angle) {
return Math.toDegrees(Math.atan2(Math.sin(Math.toRadians(angle)), Math.cos(Math.toRadians(angle))));
}
Here is my contribution. It seems to work for all angles with no edge issues. It is fast. It can do n180[360000359] = -1 almost instantaneously. Notice how the Sign function helps select the correct logic path and allows the same code to be used for different angles.
Ratch
n180[a_] :=
If[Abs[Mod[a, If[Sign[a] == 0, 360, Sign[a] 360]]] <= 180,
Mod[a, If[Sign[a] == 0, 360, Sign[a] 360]],
Mod[a, If[Sign[a] == 0, 360, -Sign[a] 360]]]
I don't know much Java, but I came across the same problem in Python. Most of the answers here were either for integers so I figured I'd add one that allows for floats.
def half_angle(degree):
return -((180 - degree) % 360) + 180
Based off the other answers I'm guessing the function would looks something like this in Java (feel free to correct me)
int halfAngle(int degree) {
return -Math.floorMod(180 - degree, 360) + 180
}
double halfAngle(double degree) {
// Java doesn't have a built-in modulus operator
// And Math.floorMod only works on integers and longs
// But we can use ((x%n) + n)%n to obtain the modulus for float
return -(((180 - degree) % 360 + 360) % 360) + 180
}
Replace int with float to your liking.
This works for any degree, both positive and negative and floats and integers:
half_angle(180) == 180
half_angle(180.1) == -179.9 // actually -179.89999999999998
half_angle(-179.9) == -179.9
half_angle(-180) = 180
half_angle(1) = 1
half_angle(0) = 0
half_angle(-1) = -1
Math explanation:
Because the modulo operator is open at the upper end, the value x % 360 is in the range [0, 360), so by using the negative angle, the upper end becomes the lower end. So -(-x%360) is in (-360, 0], and -(-x%360)+360 is in (0, 360].
Shifting this by 180 gives us the answer.