# Calculating SurfaceMFD Accelerations

#### Hielor

##### Defender of Truth
Donator
Beta Tester
Purpose: Calculate precisely (ie, without resorting to stepwise estimation) the ACC and VACC components of the SurfaceMFD.

Forum References:
Getting Acceleration Vectors
Posted by: Topper
Gives code for a stepwise estimation of horizontal and vertical accelerations, with respect to the local horizon reference frame.

Posted by: V8Li
Gives code which aims at getting a precise calculation in post 7, but due to several math errors doesn't get there, and settles on a stepwise estimation using delta-s/delta-t.

------------------------------
Unless otherwise noted, coordinates are with respect to the local horizon reference frame.

Correcting Previous Assumptions:
Both of the above threads (Topper's in post 1; V8Li's in post 3, from reverend) make the assumption that the ACC value displayed on the SurfaceMFD is horizontal component of acceleration. This is not the case, and can be proven by pointing yourself straight up while under full acceleration and noting that the ACC ~= VACC.

Rather, the ACC value displayed on the SurfaceMFD appears to be a stepwise delta estimation of whatever is displayed in the airspeed tape. This is evident in the momentary extreme values present on the ACC tape when switching between airspeed modes. Essentially, the ACC tape shows the vehicle's rate of change of airspeed, or stated differently(and in a form more suitable for precise instantaneous acceleration), acceleration along the airspeed vector.

This value is more convenient from a pilot's perspective than the horizontal component of acceleration; for example, during ascent or descent the pilot may be looking to maintain a constant airspeed. Given horizontal and vertical components of acceleration, both must be zeroed in order to maintain airspeed; given instead airspeed rate-of-change, only that must be zeroed to maintain airspeed.

I assume that the VACC (and VS) elements are as expected; that is, they are the y-component of their respective overall vectors in the local horizon frame.

The ACC Calculation:
The ACC value as displayed in the SurfaceMFD is, as stated above, "acceleration along the airspeed vector." Without further ado, the code to calculate this for the focus vessel (code is deliberately left unoptimized for ease of reading) follows. This code uses the "double length(const VECTOR3 &a)" function as defined in OrbiterAPI.h--you shouldn't have to write this on your own.
Code:
double acc;
VECTOR3 force_vec, acc_vec, spd_vec;
VESSEL* ves = oapiGetVesselInterface(oapiGetFocusObject());

// Get the vectors we need
ves->GetShipAirspeedVector(spd_vec);
ves->GetForceVector(force_vec);

// Normalize the speed vector
spd_vec = spd_vec / length(spd_vec);

// Calculate the acceleration vector
acc_vec = force_vec / ves->GetMass();

// Take the dot product
acc = acc_vec.x * spd_vec.x + acc_vec.y * spd_vec.y + acc_vec.z * spd_vec.z;
Comparison to stepwise estimation methods:
Performance: Although the above computation is more complex than that required for a stepwise estimation, it needs only be performed once per sim step and will introduce an extremely small amount of overhead when compared to the typical amount of processing done by a ship in any given timestep.
Accuracy: Testing was performed by printing the output to oapiDebugString(), and the value was compared to the ACC given for the TAS airspeed mode in SurfaceMFD. The value calculated here was identical to that displayed during level flight. Differences during extreme maneuevers can be explained by the slower response time of the stepwise estimation method.
Moreover, this precise calculation does not rely on accurate timing for the previous value, and in a distributed environment will be unaffected by any potential loss of data caused due to unreliable (or slow) networks.

The VACC calculation:
The VACC value displayed in the SurfaceMFD is, as described above, the y-component of the acceleration vector in the local horizon frame. Assuming the acceleration vector has already been calculated as shown in the previous code fragment, this calculation should be straightforward:

Code:
// INCORRECT
double vacc;
VECTOR3 horacc_vec;

ves->HorizonRot(acc_vec, horacc_vec);
vacc = horacc_vec.y;
// INCORRECT
However, testing of this method shows this to be inaccurate; specifically, at high velocities the indicated VACC will be much lower than actual due to the curvature of the earth. This is most notable at orbital velocities, where actual VACC is ~0, but the above method will indicate a VACC of ~-1g.

To account for this, we have to take into account the "centrifugal acceleration" of the craft, as it's in a rotating reference frame around the planet. Thus:

Code:
double vacc, lon, lat, radius, mag;
VECTOR3 horacc_vec;
VECTOR3 spd_vec2, glob_vpos, glob_rvel, loc_rvel;
OBJHANDLE planet;

// VACC
ves->HorizonRot(acc_vec, horacc_vec)
vacc = horacc_vec.y;

// Account for "centrifugal acceleration"
// Get the relative velocity in the local frame
planet = ves->GetSurfaceRef();
ves->GetGlobalPos(glob_vpos);
ves->GetRelativeVel(planet, glob_rvel);
ves->Global2Local((glob_rvel + glob_vpos), loc_rvel);

// Transform to horizon reference frame
ves->HorizonRot(loc_rvel, spd_vec2);

// Determine the centrifugal acceleration
spd_vec2.y = 0;
mag = length(spd_vec2);
vacc += mag * mag / radius;
Comparison to stepwise estimation methods:
Performance: This computation is significantly more complex than a stepwise estimation, but would still amount for a relatively small portion of the per-step processing performed by a vessel.
Accuracy: Testing was performed by printing the output to oapiDebugString(), and the value was compared to the VACC given in SurfaceMFD. The value calculated here is very close to that acquired by the stepwise estimation, but appears to differ by about +.005 in the vicinity of Earth, at all speed ranges, from landed to orbit.
I don't know why, but it appears that the centrifugal force calculation is over-compensating somewhat. Any ideas?

The above calculation won't work when the ship is landed:
The ground contact force that Orbiter adds doesn't take into account the gravitational pull of the sun, but the gravitational force vector does. Thus, the pull of the sun isn't offset in the total force vector.

However, since you know that VACC=0 when landed, you can just check to see if the vessel is landed and set the VACC to 0:
Maybe I'm missing something else but the answer seems pretty simple. This error is only due to the contact force when landed, right? Can't you just set VACC=0 when landed (use GetFlightStatus to check)?

Conclusion:
In situations where a stepwise estimation is unsuitable, here are the methods needed to precisely (and instantaneously) calculate the ACC and VACC elements as shown on the SurfaceMFD. However, even if the error in the VACC element can be corrected, the increased overhead may not justify the slight increase in accuracy.

Last edited:

#### tblaxland

Webmaster
Good post, Heilor :speakcool:. Maybe drop that into an article for the wiki?

#### Thunder Chicken

Donator
The value calculated here is very close to that acquired by the stepwise estimation, but appears to differ by about +.005 in the vicinity of Earth, at all speed ranges, from landed to orbit.
I don't know why, but it appears that the centrifugal force calculation is over-compensating somewhat. Any ideas?

I'm not sure, but I think the way you calculated your centrifugal acceleration would only go to zero when it was truly vertical (at the equator). At latitudes other than the equator, the centrifugal acceleration isn't vertical (it's always perpendicular to the axis of the earth).

You might want to check your math, maybe use the general cross products instead of 'algebra-fying' the equation. This Wiki page shows all of the acceleration terms due to use of a rotating system of reference http://en.wikipedia.org/wiki/Centrifugal_force

#### Hielor

##### Defender of Truth
Donator
Beta Tester
I'm not sure, but I think the way you calculated your centrifugal acceleration would only go to zero when it was truly vertical (at the equator). At latitudes other than the equator, the centrifugal acceleration isn't vertical (it's always perpendicular to the axis of the earth).

You might want to check your math, maybe use the general cross products instead of 'algebra-fying' the equation. This Wiki page shows all of the acceleration terms due to use of a rotating system of reference http://en.wikipedia.org/wiki/Centrifugal_force

I tested it at the equator too, and the error is even higher there (.0055) while parked. Any other ideas?

#### Thunder Chicken

Donator
I think I am picking up on some semantic confusion regarding the VACC definition.

The Surface MFD method is providing the rate of change of the rate of change of the position vector in the direction of the local vertical.

This *should* be the same number that you get when you take the sum of vertical components of all of the acceleration terms (centrifugal, centripetal, gravity, aerodynamic, thruster forces, and contact forces).

When landed, with no thrusters, the net vertical acceleration is determined by gravity, landing contact forces, and the vertical component of centrifugal acceleration.

In other words, if you look at the last equation in the Derivation on this page http://en.wikipedia.org/wiki/Centrifugal_force:

Surface MFD is calculating the local VACC using the single term on the right hand side of the equation. You are attempting to do it using the terms on the left hand side. It is possible, but you need to be careful to include all of the terms. At the core of the Orbiter code, this is what it is doing already.

EDIT: Parked at the equator, I calculate a centrifugal acceleration of 0.033 meters per second squared (positive 'up', trying to throw you off the planet). This is using R = 6378135 m (radius of earth) and a rotational speed of 7.3 e-05 rad/s ( 2 pi radians per day). Assuming a gravity of 9.81 meters per second squared down, the acceleration due to surface contact would be 9.81-0.033 ~ 9.78 meters per second squared up. The sum of all of these terms would be zero.

This centrifugal acceleration should be zero at the poles, which might be a good check.

Last edited:

#### tblaxland

Webmaster
I'm not sure, but I think the way you calculated your centrifugal acceleration would only go to zero when it was truly vertical (at the equator). At latitudes other than the equator, the centrifugal acceleration isn't vertical (it's always perpendicular to the axis of the earth).
@TC, the velocity vector, spd_vec2, is rotated into a local horizontal frame of reference by "ves->HorizonRot(loc_rvel, spd_vec2)". The y-axis in that frame is perpendicular to the local horizontal plane, not the Earth's rotation axis that you suggested.

@Heilor, I can suggest two possible sources of error:

1. The local horizontal plane is not perpendicular to the radius vector due to the non-spherical nature of the reference body. This should reduce to zero at the equator for Earth, which is not supported by your observations, but should be corrected for completeness nonetheless.

2. Rounding errors in the HorizonRot function. I have read that rotation matrices can accumulate rounding errors so there may be an issue here.

Solution? Find the centripetal force directly from the radius and velocity vectors, as suggested by TC. Some rough code:

Code:
v->GetRelativePos(planet,&rpos);
v->GetRelativeVel(planet,&rvel);
r = rpos/length(rpos);
vacc = dotp(r,acc_vec); // component of acc_vec that is parallel to r
horizVel = length(crossp(r,rvel)); // component of rvel that is in a plane perpendicular to r, direction is not important
vacc += horizVel*horizVel/length(rpos);

Last edited:

#### Hielor

##### Defender of Truth
Donator
Beta Tester
@Heilor, I can suggest two possible sources of error:

1. The local horizontal plane is not perpendicular to the radius vector due to the non-spherical nature of the reference body. This should reduce to zero at the equator for Earth, which is not supported by your observations, but should be corrected for completeness nonetheless.
The local horizon plane is defined (according to the Orbiter API) as having the y-axis be parallel to a line between the center of the body and the vessel. So yes, by definition the local horizontal plane is perpendicular to the radius vector.

2. Rounding errors in the HorizonRot function. I have read that rotation matrices can accumulate rounding errors so there may be an issue here.

Solution? Find the centripetal force directly from the radius and velocity vectors, as suggested by TC. Some rough code:

Code:
v->GetRelativePos(planet,&rpos);
v->GetRelativeVel(planet,&rvel);
r = rpos/length(rpos);
vacc = dotp(r,acc_vec); // component of acc_vec that is parallel to r
horizVel = length(crossp(r,rvel)); // component of rvel that is in a plane perpendicular to r, direction is not important
vacc += horizVel*horizVel/length(rpos);

Thanks, I'll change the code to do that and give it a test. Can't do it now, but I will advise.

#### Thunder Chicken

Donator
The local horizon plane is defined (according to the Orbiter API) as having the y-axis be parallel to a line between the center of the body and the vessel. So yes, by definition the local horizontal plane is perpendicular to the radius vector.

Yes...but this isn't the 'radius' used in the centrifugal force calculation. That 'radius' is the perpendicular distance between your ship and the axis of the earth. For example, this radius would be 6800 km at the equator, 0 at the poles, and some number in between at other latitudes.

#### tblaxland

Webmaster
Yes...but this isn't the 'radius' used in the centrifugal force calculation. That 'radius' is the perpendicular distance between your ship and the axis of the earth. For example, this radius would be 6800 km at the equator, 0 at the poles, and some number in between at other latitudes.
That is only valid for a landed situation. Do you expect that the centripetal acceleration of a body in polar orbit would be any different to that in an equatorial orbit? For an orbiting body (under standard assumptions, ie, mass of orbiting body << mass of reference body) the radius vector is exactly equal to the line from the centre of mass of the orbiting body to the centre of mass of the reference body. Notwithstanding, using the method I gave also works for a landed vessel because the velocity vector, and hence the centripetal acceleration, reduces to zero at the poles.

#### Hielor

##### Defender of Truth
Donator
Beta Tester
Yes...but this isn't the 'radius' used in the centrifugal force calculation. That 'radius' is the perpendicular distance between your ship and the axis of the earth. For example, this radius would be 6800 km at the equator, 0 at the poles, and some number in between at other latitudes.

Not true. I had to draw a diagram in order to figure it out for sure; it's attached.

Consider that if you're in orbit, your axis of rotation will most likely not be the earth's axis, and moreover, the correct radius of your orbit will be...the radius of your orbit. The same applies to an object flying above the surface of the Earth--you've got your own "axis of rotation" that you're spinning about which is what determines your centrifugal acceleration.

Consider also that we're looking for the vertical (with respect to the ship's horizon frame) component of the centrifugal acceleration. See the attached image. CA is the centrifugal acceleration due to the Earth's rotation. Then, the magnitude of the vertical component of CA (CA.V) is CA * cos(lat), by basic trigonometry.

CA is given by the general equation (v ^ 2) / r, where r is the radius of rotation. Given our radius r (apologies for the re-definition of r) from the center of the earth, the radius from the earth's axis of rotation will be r * cos(lat), as shown in the attached diagram.

Plugging that into the equation, we get that CA = (v ^ 2) / (r * cos(lat)). Using our previous definition of CA.V, we see that CA.V then is ((v ^ 2) / (r * cos(lat))) * cos(lat).

The cos(lat) terms cancel out, and we're left with CA.V = (v ^ 2) / r.

So no, the problem is not that I'm calculating the centrifugal acceleration incorrectly, because I'm not calculating the centrifugal acceleration--I'm calculating the vertical component of the centrifugal acceleration. Moreover, if that were the only problem, the equation would have a *smaller* error in the vicinity of the equator, not a *larger* one as is the case.

I'll be attempting tblaxland's method shortly to see if that changes anything, but I have like three homework assignments I'm supposed to be doing...

#### Attachments

• CA.jpg
10.7 KB · Views: 20

#### cjp

Donator
Not true. I had to draw a diagram in order to figure it out for sure; it's attached.

Consider that if you're in orbit, your axis of rotation will most likely not be the earth's axis, and moreover, the correct radius of your orbit will be...the radius of your orbit. The same applies to an object flying above the surface of the Earth--you've got your own "axis of rotation" that you're spinning about which is what determines your centrifugal acceleration.

Not true for someone in orbit. True for someone stationary at the planet's surface.

#### Hielor

##### Defender of Truth
Donator
Beta Tester
Not true for someone in orbit. True for someone stationary at the planet's surface.

Did you read the rest of my post, in which I showed that the conversion to the axis of rotation cancels out for someone on the surface?

Still not working. I've split up the data so I can look at it more precisely.

I'm calculating an expected centrifugal acceleration component of .0339 m/s^2 at the equator, which jives (more or less) with Thunder Chicken's value.

Using Orbiter's "View Forces" lines, an empty DG-S sitting at the equator has a total force acting on it of 373.2N straight down--the centripetal force. However, dividing this by the mass of the vessel (13255kg) gives a centripetal acceleration of .02814, which is about the error I saw earlier (then, error was .0055, now it's precisely .00576).

Out of boredom, I sped up time and noticed that the total force vector was changing, due to the sun's position! Further testing gave the low value for total force at around 370N, the high value at around 528N, so an average of 449N for the total force. That, converted to acceleration, is .03387 m/s^2. Compare to our expected centripetal force of .0339 m/s ^2.

So, apparently, the ground contact force that Orbiter adds doesn't take into account the gravitational pull of the sun, but the gravitational force vector does. Thus, the pull of the sun isn't offset in the total force vector.

#### cjp

Donator
Did you read the rest of my post, in which I showed that the conversion to the axis of rotation cancels out for someone on the surface?

Uhmm,, no . Sorry.

#### Thunder Chicken

Donator
CA is given by the general equation (v ^ 2) / r, where r is the radius of rotation. Given our radius r (apologies for the re-definition of r) from the center of the earth, the radius from the earth's axis of rotation will be r * cos(lat), as shown in the attached diagram.

This was the point I was trying to make - I was concerned that you were confusing the two definitions of 'radius'. Looks like you have it straight.

#### tblaxland

Webmaster
So, apparently, the ground contact force that Orbiter adds doesn't take into account the gravitational pull of the sun, but the gravitational force vector does. Thus, the pull of the sun isn't offset in the total force vector.
Nice detective work, mate.

How are those assignments coming along?

#### Hielor

##### Defender of Truth
Donator
Beta Tester
Nice detective work, mate.

How are those assignments coming along?

Well, the project that was due last night at midnight should be done in a couple hours, and i think the assignment for my other class shouldn't take long.

I should get a bumper sticker that says, "I'd Rather Be Orbiting"

#### Tachyon

##### Donator
Donator
Please tell me that the preceding thread was somehow related to either one or both of your "assignments" Hielor. Because if not, this just took all the fun out of flying the XR2 !

oh and if you don't mind, what and where would those assignments be?
.... major?

#### Hielor

##### Defender of Truth
Donator
Beta Tester
Please tell me that the preceding thread was somehow related to either one or both of your "assignments" Hielor. Because if not, this just took all the fun out of flying the XR2 !
Unfortunately, no, I don't have any classes that require me to do maths in Orbiter. :lol: How did I take all the fun out of flying the XR2?

oh and if you don't mind, what and where would those assignments be?
.... major?
A distributed computing project, and a simple networking assignment. Major is Computer Science, I'm at the University of Texas-Austin. I'll graduate in December, assuming I pass all my classes...which is why I need to do the assignments. Apparently doing the assignments helps in getting good marks. :rofl:

Last edited:

#### Quick_Nick

##### Passed the Turing Test
Donator
A distributed computing project, and a simple networking assignment. Major is Computer Science, I'm at the University of Texas-Austin. I'll graduate in December, assuming I pass all my classes...which is why I need to do the assignments. Apparently doing the assignments helps in getting good marks. :rofl:
I always sort of thought that you weren't even from the US. My brother actually goes to UT @ Austin. (doubt you'd know him though)

Nice work! I wish you luck with the MFDs and your schoolwork.

Awesome!!! :speakcool: