Menu
▾
▴
Re: [Flightgear-devel] Turn ball fix & JSB notes
|
From: Tony P. <ap...@ea...> - 2001-08-27 22:39:01
|
On Monday 27 August 2001 11:28 am, you wrote:
> Observation number one was that the problem is specific to the JSBSim
> code. When using LaRCsim, the ball behaves more or less like it
> should. A few printf's later, I thought I had it: when asked for the
> local (pilot) acceleration, LaRCsim will return a value including
> gravity, but JSBSim won't. The Z component of JSB's pilot
> acceleration is zero when the plane is stopped on the ground, LaRCsim
> reports -32.1 ft/sec^2.
While it is certainly true that gravity is acts on the aircraft, it is also
true that while at rest on the ground, the ground is acting on the aircraft
as well. In fact, the force produced by the ground should be exactly equal
and opposite to that produced by gravity. Therefore, the total vertical
acceleration of the aircraft is zero, not 1.0 or -32.174 ft/sec^2
I really don't understand where this practice of referencing veritcal accel
back to 1 rather than 0 got started. One guess may be the aerodynamicists'
practice of using nlf (normal load factor) which is -- more or less -- lift
divided by weight and is equal to 1.0 in steady, level flight but is still
zero on the ground at rest.
>
> Easy enough to fix, so I added some code to add in a gravity vector to
> the pilot's acceleration before returning the value. But that wasn't
> the whole story. Here things gets a little tricky:
>
> JSBSim stores an internal value in FGTranslation::vUVWdot. The name
> implies that this is the time derivative of the velocity. So that's
> the acceleration, right? Wrong.
Yes it is, it's acceleration in the body reference frame.
> This is the time derivative of the
> velocity in the PILOT's reference frame.
The body reference frame has its origin at the cg, so it's not really that
either.
> But regardless, it does work, and the JSBSim code does the right thing
> with the plane's motion. EXCEPT when you try to interpret "Vdot" as
> an acceleration. There it breaks down, and actually has the effect of
> cancelling itself out. Think about a plane in a static turn: the
> plane is accelerated relative to the GROUND, but its velocity through
> the AIR is constant. Thus, the vUVWdot vector will be zero. But
> that's wrong -- what if the plane is in a big honkin' 9G bank and the
> pilot is about to black out?
Since a fair amount of "extra" (vs that required for steady, level) lift is
required to maintain a 9g turn and since wdot comes directly from the sum of
the forces, vUVWdot _will_ properly reflect the acceleration of the aircraft.
(Yes, you must make more lift to pull more g's in a turn)
> In the plane's frame, acceleration isn't
> the same thing as the time as the time derivative of velocity.
It depends on which velocity you are talking about.
>
> But knowing this, a solution was at hand. I hacked in a new
> "LocalAccel" value that didn't include the fictitious force, added a
> gravity vector, and used this instead. It works. Mostly. The patch
> is at the bottom of this note. Some notes about the implementation:
>
> + The gravity value is a hard-coded 32.1 ft/sec^2. This is plenty of
> precision for the turn & bank ball, but could certainly be improved
> upon. I'm sure there's a gravity model somewhere in JSBSim that
> takes altitude and position into account. If not, I believe LaRCsim
> has one that could be stolen.
This is not difficult, just needs to be done.
>
> + You'll probably need to turn down the "factor" in the turn.xml file.
> In JSB sim, rudder authority is MUCH higher than LaRCsim, and the
> resulting lateral accelerations are therefore higher. I'm not a
> pilot, and have never been in a Skyhawk, so I can't say which sim is
> correct. I used a factor of about 60 or so (with proportional
> changes to the max/min) with some success.
This is a problem I noticed myself yesterday. I have fixed it and will send
the updated c172.xml file off to John Check shortly.
>
> + There seems to be a collision of coordinate conventions. The X and
> Y (but not Z) acceleration components had to be inverted to get them
> to match the sense of the gravity vector. I didn't investigate this
> further. LaRC seems to use an "x-front, y-left, z-up" convention,
> whereas JSB is x-back, y-right, z-up. I may have gotten those mixed
> up. This was a classic case of making sure I have an even number of
> sign errors. :)
>
> Really, the biggest problem with the fix is that it's a hack. If I
> might make a mild criticism, I'd suggest ditching the "UVW" frame
> entirely and doing all the calculations in an unaccelarated global
> frame of some sort. The UVW frame is convenient for representing the
> airflow relative to the plane, but it's a huge source of confusion and
> bugs (like, for example, this one) for everything else. It's also not
> as useful for the airflow calculations as you'd expect, once you start
> getting fancy. For tight turns and (especially) spins, the airflow
> around the plane is NOT a constant flow field. In a reasonably tight
> spin, the difference between the flows at each wingtip can easily be a
> factor of two. Even worse, try representing a turbulence field as a
> fictitious force. :)
>
> And there remain some weird issues. The y-axis (side) acceleration
> doesn't seem to always go to zero when it should. With the plane
> moving straight ahead very slowly on the ground, I see a side
> acceleration of ~2 ft/s^2, and the ball is hanging noticeably off to
> the side. Clearly this isn't right; it may be due to an interaction
> with a part of the code I didn't understand and account for.
I will investigate this.
>
> Also, while the Z (into-the-seat) force seems to be correct with this
> patch, the X and Y show some really weird behavior. Try this: take
> off in the 172 and gain some altitude. Tap the yoke to one side, and
> then center it. The plane will slowly turn over into a death spiral.
> This bit is correct. But watch the accelerations as it does it (I did
> this with a printf in the "slip-skid" code in steam.cxx). The Z force
> continues to climb to 2-3 G's, but the side and forward forces keep
> changing. The side force goes from 1 G off to the side to zero and
> back again, and the forward/back force does the SAME thing, 180
> degrees out of phase. And weirdest of all: the period of this change
> is one compass revolution. When facing north, my Y acceleration is
> zero and the pilot is pushed forward in his seat at 1 G. By the time
> it's facing south, he's dangling sideways in his chair. Clearly
> something is mixing the global reference frame with the local one, but
> I can't find it. I thought for a while that I'd done something like
> swap two components of the gravity vector, but I removed it and saw
> the same behavior. I'm (fairly) certain that this behavior is endemic
> to the vUVWdot calculation.
Are you looking at the cg accels or the pilot accels?
>
> Anyway, without further ado, here's the patch. It's a CVS diff
> against the current source tree.
>
> Andy
>
> ===================================================================
>
> --- FGTranslation.h 2001/07/10 13:56:39 1.20
> +++ FGTranslation.h 2001/08/27 06:12:09
> @@ -90,6 +90,8 @@
> inline FGColumnVector GetvAero (void) { return vAero; }
> inline float GetvAero (int idx) { return vAero(idx); }
>
> + inline FGColumnVector GetLocalAccel(void) { return vLocalAccel; }
> +
> inline float Getalpha(void) { return alpha; }
> inline float Getbeta (void) { return beta; }
> inline float Getqbar (void) { return qbar; }
> @@ -117,6 +119,7 @@
> private:
> FGColumnVector vUVW;
> FGColumnVector vUVWdot;
> + FGColumnVector vLocalAccel;
> FGColumnVector vNcg;
> FGColumnVector vPQR;
> FGColumnVector vForces;
>
> ===================================================================
>
> --- FGTranslation.cpp 2001/07/10 13:56:39 1.18
> +++ FGTranslation.cpp 2001/08/27 06:12:09
> @@ -82,6 +82,7 @@
> FGTranslation::FGTranslation(FGFDMExec* fdmex) : FGModel(fdmex),
> vUVW(3),
> vUVWdot(3),
> + vLocalAccel(3),
> vNcg(3),
> vPQR(3),
> vForces(3),
> @@ -127,6 +128,18 @@
> mVel(3,3) = 0.0;
>
> vUVWdot = mVel*vPQR + vForces/Mass;
> +
> + // Local acceleration is similar, but it includes gravity too, and
> + // does NOT include the mVel*PQR fictitious force (which is an
> + // artifact of the accelerated reference frame used here). Note
> + // that the gravity vector is the Z unit vector times the inverse
> + // of the "local to body" matrix (it's orthogonal, so that's just
> + // the transpose); the X and Y gravity components are inverted to
> + // match coordinate conventions.
> + vLocalAccel = vForces/Mass;
> + vLocalAccel(1) += 32.1 * State->GetTl2b(3, 1);
> + vLocalAccel(2) += 32.1 * State->GetTl2b(3, 2);
> + vLocalAccel(3) -= 32.1 * State->GetTl2b(3, 3);
>
> vNcg = vUVWdot*INVGRAVITY;
>
> ===================================================================
>
> --- FGAuxiliary.cpp 2001/06/20 20:29:32 1.14
> +++ FGAuxiliary.cpp 2001/08/27 06:12:08
> @@ -112,9 +112,9 @@
> // vPilotAccel = Translation->GetUVWdot() + Aircraft->GetXYZep() *
> Rotation->GetPQRdot();
>
> vToEyePt = Aircraft->GetXYZep() - MassBalance->GetXYZcg();
> - vPilotAccel = Translation->GetUVWdot()
> - + Rotation->GetPQRdot() * vToEyePt
> - + Rotation->GetPQR() * (Rotation->GetPQR() *
> vToEyePt); + vPilotAccel = Translation->GetLocalAccel()
> + + Rotation->GetPQRdot() * vToEyePt
> + + Rotation->GetPQR() * (Rotation->GetPQR() * vToEyePt);
>
> earthPosAngle += State->Getdt()*OMEGA_EARTH;
> return false;
--
Tony Peden
ap...@ea...
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
|
