Is there a mathematical solution for preventing fly-aways?
My understanding is that the following is what causes them:
- Accel z goes negative due to ship vibration versus an actual drop in altitude
- The ship corrects by adding power
- The added power causes a larger vibration-induced negative z
- The ship corrects the pseudo altitude drop by adding more power
- A fly away occurs
My understanding of mathematical solutions are:
- A filtered or weighted z only diminishes (does not solve) the effect.
Has anyone tried a "significant z", z / s, where s is the moving average of the variation of z?
- when the IMU isn't vibrating, s is low so the magnitude of z / s is high
... z is significant
... z can be trusted for use in altitude control
- when the IMU is vibrating, s is high so the magnitude of z / s is low
... z / s has less effect
... and will not caused a flyaway
Replies
The topic has been hijacked by the discussion of acceleration. But i think we are done with the original discussion so ...
... the jet is experiencing 1g of downward acceleration in all cases even though it logically seems like it isn't. Once you understand this, you will also understand why the accelerometer correctly displays -1g (if +z is oriented away from earth's core).
the following has way to many words, but if you follow them, you will understand what's not intuitive.
first, let's talk about x and y acceleration to get them out of the way.
Case 1: the jet is passing perpendicular to a planetary core (with the same mass and diameter as Earth) with no atmosphere. There is no drag, thus no need to accelerate the object in x or y to keep it at it's constant velocity. Thus there is no acceleration in x or y. The motors to maintain x/y velocity are turn off. The accelerometers for x&y are measuring 0.
Case 2: jet is passing through our atmosphere with the friction of the atmosphere creating drag. Drag is a force. Force is m x a, with the 'a' being acceleration. So the jet has a decelerating force acting on it. Thus to maintain velocity, the jet engines for x/y must exactly counter the force of drag. The accelerometer knows nothing of both individual forces. It doesn't know of the -.25g drag in x and +.25g thrust in x. All it sees is the net. Thus it correctly reports 0g.
This is easy to understand. There is no new knowledge here.
Now for z-acceleration.
Case 1 (which has 2 subcases): the jet is passing perpendicular to a planetary core (with the same mass and diameter as Earth) with no atmosphere. There is no drag. Given that there is only a jet motor that can propel in x (the flaps won't work in zero atmosphere), the only ways to get the jet perpendicular to the orbit are:
a) come in at an ellipse so that the jet is in a slingshot and perpendicular at only one point, the origin of the ellipical arc. Gravity acts on the jet to it draw it closer to the core (distance from the core is changing at a non-constant negative rate or negative z-aceleration), until the origin, where the rate of change is 0 (constant velocity thus 0 acceleration), followed by a non-constant positive change in distance from the core (positive z-acceleration). The gravitational force acting on the jet causes a free-fall that is later accelerated away from the core--called by space techs, a slingshot. An accelerometer correctly senses this force and can track it. Absolutely critical in space routing.
b) use the jet engines to put the object in a non-decaying concentric orbit that does not require further use of the engines to maintain that orbit. In this case, the ship is now perpendicular to gravity at all times. Let's say there is no drag at this particular orbit. so what holds the ship in the orbit? Gravity is the centripetal (Cp) force that counters the centrifugal (Cf) force that would otherwise get the ship to take in a straight line and get the hell out of Dodge (circling around the planet). So here is the cool part that still blows my mind. Ready? One would think that since Cf counters Cp that the net force would be zero and the accelerometer would read 0 just as with the x/y accelerometers in a jet-drag situation. But the z-accelerometer will read between (but not including) 0g to -1g depending on the elevation of orbit (how far it's from the core).
What??? The reason is that centrifugal force is not a true force (that's the part that screws with my mind). Force is derived from acceleration. Cf is derived from the inertia of motion (velocity). Cf is based on mass and velocity, not acceleration.
Thus once again, the z-accelerometer is correctly reporting net force.
The approximately -1g being reported by the z-accel is not a bias. It's reality. Whether i'm just sitting in my chair, running on a track, sitting in the seat of an aircraft on the ground, or siting in the seat of an aircraft flying at constant altitude at near the speed of sound, I stay in contact with the ground or my seat because there is about -1g trying to accelerate my body through the seat, floor, or ground.
Case 2: This is not hard to figure out as it just adds drags drag into the mix.
Okay, I'm sorry for "hijacking" the thread -- but solving this is apparently the root cause of the problem noted in the first post.
Not being able to even discuss the issue ... this seems to be a real problem if smart folks don't know the difference between acceleration and gravity -- even to the point where they go on to describe why "free fall" is not "zero gravity". I'm actually scared that I am missing something, and so is Forrest, as he continually talks about gravity, while I cannot accept remedial astrophysics as an answer to my concern with what appears to be misuse of an instrument (accelerometer) by the flight controller and/or he software stack running upon it -- though I get the feeling I'm missing something. :-)
So I am sensing there is something connecting gravity to acceleration in our software stack; but I am unable to get a sensible answer on why the electronic component includes g in acceleration when it (g) is apparently completely unused in maintaining attitude, altitude, airspeed, or direction, other than indicating which way is currently up -- if this is the sensor providing that input. The last response shouts in bold type that the accelerometer is correctly reporting 'net force'. But acceleration is also not force but only one of two components of force... what am I missing?
Can someone who knows why we see gravity as "downward acceleration" -- and therefore, why a saturated Z axis results in the FC compensating for that false reading and vertically flying away, please indicate the design decision taken to work this way? There must be a worse case that is avoided. At least we cold then understand... or maybe come up with an idea to fix that.
It's an honest question, and with all politeness, please can we answer the question directly rather than using incorrect analogy to jet planes or completely unrelated gravity stories about satellites and so-called non-decaying orbits! :-)
Chris
ah ...
first understand that a -1g in the accelerometer is not saturated. it's just a number defining it's state at a particular moment that can roam between all g states that the ship will encounter in flight (say -4g to +4G):
second, understand that in determining altitude, the FU:
- is really determining relative elevation so it can hold steady up and down
- cannot do this with GPS because it's not accurate or fine enough
- cannot do this with the barometer because i'ts not accurate, fine enough, and affected by natural air variation which gets further disturbed by prop wash
- so it primarily uses Accel-z
In alt-hold, loiter, return to launch, position hold, etc., the ship doesn't need to know it's elevation or altitude, only whether or not it is going up or down (yes ... even in RTL amazingly enough). It turns out that the accel-z sensor is highly sensitive. Move the ship up an inch (to do so it needs to accelerate up ever so slightly thus increasing the g-force) and the sensor knows allowing the FU to correct.
So when you see your ship just hovering in space and not moving up or down, surprisingly, it's not the baro that is doing most of the work. It's accel-z.
Did that address your question? Does that help?
Thank's Forrest, very clear explanation and very interesting to know how our machines work.
Barometer - that caught me by surprise too. always thought that the baro was so sensetive that it could report a 1" movement up or down and that was why alt-hold was so incredibly beyond belief in keeping my ship just hanging there in space. but that's not the case as was explained to me. baro only provides a fairly accurate indicator of pressure, which post processing math can change into changes in pressure. but changes in pressure has too many causes with only cause being moving the ship up or down.
Gravity - a cool side note is that there isn't a sensor built yet (to my knowledge) that directly detects gravity. primarily because it isn't something that we even as yet understand. we don't even know if it is something that originates in our 3 dimensional space or something that leaks in from 9 dimensional space. all we can do is sense the affect of gravity--it's ability to accelerate mass.
z-Accelerometer - so it doesn't sense gravity, it only senses net acceleration from forces on a piezo crystals (usually made of silicone and oxygen atoms) that displaces an electrical charge when the lattice is stretched or squeezed. Hold it just right (perpendicular to the Earth's core) and it displaces a charge that can be used to calibrate it to the gravitational force at that location. Move it from 0 to 9.8 m/s/s in deep space and it will produce the same displaced charge.
z-Accelerometer use in alt-hold - a wind moves the ship upward that was previously sitting still. Before the wind, the z-velocity was 0, 0, 0 (so acceleration was 0). The wind hits and the z directional movement speeds up to .001, .002, and 003 m/s/s (so acceleration, the change in velocity, is .001).
- the piezo changes shape (it's squeezed) during the acceleration
- electrons are displaced in the piezo crystal
- the brain of the accel chip sees this voltage change
- it converts via calibration data to a calibrated voltage
- it sends out this voltage to the ship FCU
- the ship FCU now knows that the ship is going up
- it compensates and stops the upward movement (cuts throttle)
- it reverses the acceleration that was reported
- until the ship is back where it started
When i was told this, i thought, how clever and unexpected! Of course it is more complex than this because the ship is actually using 3 sensors to 'see' changes in z:
- GPS
- Barometer
- Accelerometer
- Sonar or vision (if equipped)
So hopefully, you now know why:
- the accelerometer is so good at sensing changes in elevation (change in movement begets acceleration just as gravity begets acceleration)
- why the gravitational constant is irrelevant (the ship only cares about acceleration, the change in movement)
P.S. we could talk only in terms of m/s/s. Ya man, i was hauling ass at 29.4 meters per second squared. But it's easier to say, god my head hurt when i smashed into that tree at 3 g. So the term gravity is only a convenience of speech that give us a reference. For example, one of my jobs at Boeing was to keep the floors in tact enough so that folks can exit after a "9g deceleration". OK ... a "crash". Or "slowing down at a rate of 88 m/s/s". Take you pick.
@Forrest,
when you said"when you see your ship just hovering in space and not moving up or down, surprisingly, it's not the baro that is doing most of the work. It's accel-z.", it confused me because the APM alt-hold is not using the GPS, if the baro is not the main source, please edicate me how to use the accel-z to pin out the altitude. Thanks
https://www.youtube.com/watch?v=hByJBdQXjXU
Err, there's no gravity? Stand back, I'm going to try Science!!!*bzzzzzzt*
I knew ESA had a newer dataset -- ESA GOCE captured a geoid in 2011 from some Googling...
do you know patent numbers for SIRF/SURF and did you contact patent holders, assigners yet ?
This thread is 6 years old
-
13
-
14
-
15
-
16
-
17
of 20 Next