Re: [Flightgear-devel] c172r-yasim solution error
Mathias Fröhlich wrote: I have checked in into JSBSim's cvs a change which will make the inerial acceleration in the earth fixed geodetic horizontal local frame availabel to the HUD. That patch is attached to this mail. So you could apply that to your local tree and use that until flightgears JSBsim is again synced with the original tree. Which is now. I've synchronized JSBSim CVS and JSBSim/FlightGear CVS again. Now it is also possible to do carrier landings with JSBSim carrier enabled aircraft. Thanks Mathias. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Le dimanche 22 mai 2005 10:45 +0200, Erik Hofman a crit : Mathias Frhlich wrote: I have checked in into JSBSim's cvs a change which will make the inerial acceleration in the earth fixed geodetic horizontal local frame availabel to the HUD. That patch is attached to this mail. So you could apply that to your local tree and use that until flightgears JSBsim is again synced with the original tree. Which is now. I've synchronized JSBSim CVS and JSBSim/FlightGear CVS again. Now it is also possible to do carrier landings with JSBSim carrier enabled aircraft. Thanks Mathias. Erik About carrier landing , i have not found the LAUNCHBAR and HOOK fonction in it. It is may be impossible to do it without the original patch. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Hi,
On Freitag 20 Mai 2005 16:37, Andy Ross wrote:
Mathias Fröhlich wrote:
At first I need to know how this local frame is meant.
What I have found from the code is that it is meant to be the *geodetic*
horizontal local frame.
But is is meant to be fixed at the aircraft and thus rotates due to the
aircrafts velocity or is it fixed at the earth and relocated for every
frame to display?
For what it's worth, YASim supports this NED (north/east/down)
coordinate frame for output, but doesn't use it internally. It's
pretty strange IMHO, and of course has a singularity problem at the
poles. If JSBSim is having trouble with it, it might be best to just
junk the concept and fix the HUD code to use body coordinates.
Yep, JSBSim uses *a* horizontal local frame, the geocentric one.
But not the geodetic horizontal local frame like flightgear seems to expect.
And no sane guy will calculate how the geodetic (not geocentric!) horizontal
local frame attached to the aircrafts center of gravity will rotate due to
longitudinal movement ...
And that JSBSim uses that one has historical reasons and that I did not want
to discuss the change of that with Jon at that time...
... I discussed for much smaller changes for weeks with him. :-/
Ok, Fixing that in the HUD and just use the orientation of the body frame and
the body velocity for everything in the HUD would be a good idea IMO.
There are other issues with the HUD anyway.
- Having properties as inputs.
- Being able to clip the HUD to be limited to some line stripe surrounding the
HUD glass.
- Being able to rotate the HUD so that it appears to be on that glass it is
projected to.
But until then, Mike:
I have checked in into JSBSim's cvs a change which will make the inerial
acceleration in the earth fixed geodetic horizontal local frame availabel to
the HUD.
That patch is attached to this mail. So you could apply that to your local
tree and use that until flightgears JSBsim is again synced with the original
tree.
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: JSBSim.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/JSBSim.cxx,v
retrieving revision 1.31
diff -u -r1.31 JSBSim.cxx
--- JSBSim.cxx 16 Dec 2004 12:47:20 - 1.31
+++ JSBSim.cxx 21 May 2005 07:14:14 -
@@ -26,6 +26,7 @@
#endif
#include simgear/compiler.h
+#include simgear/math/sg_geodesy.hxx
#include stdio.h // size_t
#ifdef SG_MATH_EXCEPTION_CLASH
@@ -552,9 +553,34 @@
Propagate-GetUVW(3) );
// Make the HUD work ...
-_set_Velocities_Ground( Propagate-GetVel(eNorth),
-Propagate-GetVel(eEast),
--Propagate-GetVel(eDown) );
+{
+ const FGLocation l = Auxiliary-GetLocationVRP();
+ double xyz[3] = { l(eX)*SG_FEET_TO_METER,
+l(eY)*SG_FEET_TO_METER,
+l(eZ)*SG_FEET_TO_METER };
+ double lat, lon, alt;
+ sgCartToGeod(xyz, lat, lon, alt);
+ FGQuaternion Tec2geodhl(0, -0.5*M_PI-lat, lon);
+
+ FGColumnVector3 ecVel = l.GetTl2ec()*Propagate-GetVel();
+ FGColumnVector3 geodhlVel = Tec2geodhl.GetT()*ecVel;
+
+ _set_Velocities_Ground( geodhlVel(eNorth)*SG_FEET_TO_METER,
+ geodhlVel(eEast)*SG_FEET_TO_METER,
+ -geodhlVel(eDown)*SG_FEET_TO_METER );
+
+ // Transform the acceleration to the earth centered frame and then
+ // back to the geodetic hl frame.
+ FGColumnVector3 accel = Propagate-GetUVWdot();
+ accel -= Propagate-GetUVW()*Propagate-GetPQR();
+ accel = Propagate-GetTb2l()*accel;
+ accel = l.GetTl2ec()*accel;
+ accel = Tec2geodhl.GetT()*accel;
+
+ _set_Accels_Local( accel(eNorth)*SG_FEET_TO_METER,
+ accel(eEast)*SG_FEET_TO_METER,
+ -accel(eDown)*SG_FEET_TO_METER);
+}
_set_V_rel_wind( Auxiliary-GetVt() );
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] c172r-yasim solution error
On Freitag 20 Mai 2005 16:37, Andy Ross wrote: Mathias Fröhlich wrote: At first I need to know how this local frame is meant. What I have found from the code is that it is meant to be the *geodetic* horizontal local frame. But is is meant to be fixed at the aircraft and thus rotates due to the aircrafts velocity or is it fixed at the earth and relocated for every frame to display? For what it's worth, YASim supports this NED (north/east/down) coordinate frame for output, but doesn't use it internally. It's pretty strange IMHO, and of course has a singularity problem at the poles. If JSBSim is having trouble with it, it might be best to just junk the concept and fix the HUD code to use body coordinates. Yep, JSBSim uses *a* horizontal local frame, the geocentric one. But not the geodetic horizontal local frame like flightgear seems to expect. Actually, IIRC, FlightGear did it's own conversions from geocentric to geodetic and so expects to get geocentric locations from the FDM. Over time, perhaps this has changed. I have checked in into JSBSim's cvs a change which will make the inerial acceleration in the earth fixed geodetic horizontal local frame available to the HUD. That patch is attached to this mail. So you could apply that to your local tree and use that until flightgears JSBsim is again synced with the original tree. Mike: for the purposes of energy calculations (I assume you are providing some kind of guidance via HUD symbology based on energy) and based on a quick look at your equations there should be virtually no difference between the geocentric accels and the corresponding geodetic values. Previously in JSBSim we have provided NED accels (in the geocentric local frame), but this capability was lost when the EOM were rewritten. If everyone is happy with this change, I'll make sure it gets into the newer JSBSim version that is finishing up development in another branch. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
In a message dated 5/20/2005 8:36:06 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: I didn't test this, but it should work for a quick hack. The result will be an aircraft that looks like a Skyhawk but flies like a Warrior. A, Sweet...!!! Although the aircraft seems to act like a mix-breed, this will certainly serve my purposes in the short term. If you get the chance, try the hack on your machine and let me know if you experience some performance degradation in both a/c and FG. I had to copy the pa28-161.xml file into my ...data/Aircraft/c172p folder for a successful launch. Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Hi, On Donnerstag 19 Mai 2005 04:45, Jon Berndt wrote: We do have vUVWdot, which is body frame. We also have Tb2l, which is a transformation matrix that goes from body to local. This is where it gets hazy for me, too, and I have to sit and think about it, but since the body frame is rotating wrt to the local frame, I think there is an acceleration due to the rotation, as well, so one cannot simply transform from body axes to local frame. We can do this, it will just take some thinking. And, yes, Mathias is the expert, here. This is where it gets a little hazy for me, too, but IIRC, vVeldot = vUVWdot*Tb2l + vPQR*vUVW If that's not right, it's something like that, and I know we can calculate it. But, I'll really be surprised if it's not being calculated somewhere already. Ok, At first I need to know how this local frame is meant. What I have found from the code is that it is meant to be the *geodetic* horizontal local frame. But is is meant to be fixed at the aircraft and thus rotates due to the aircrafts velocity or is it fixed at the earth and relocated for every frame to display? Or the other question is: what is that hud element meant to display? I cannot yet make sense of that. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Mathias Fröhlich wrote: At first I need to know how this local frame is meant. What I have found from the code is that it is meant to be the *geodetic* horizontal local frame. But is is meant to be fixed at the aircraft and thus rotates due to the aircrafts velocity or is it fixed at the earth and relocated for every frame to display? For what it's worth, YASim supports this NED (north/east/down) coordinate frame for output, but doesn't use it internally. It's pretty strange IMHO, and of course has a singularity problem at the poles. If JSBSim is having trouble with it, it might be best to just junk the concept and fix the HUD code to use body coordinates. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
In a message dated 5/20/2005 2:09:17 AM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
But is is meant to be fixed at the aircraft and thus rotates due to the
aircrafts velocity or is it fixed at the earth and relocated for every frame
to display?
Or the other question is: what is that hud element meant to display?
I cannot yet make sense of that.
Hi M,
The HUD element provides a visual indicator of energy within a constant
speed climb or descent thru the use of hud_ladr.cxx:
if(energy_marker) {
if (total_vel 5.0) {
t1 = 0;
t2 = 0;
} else {
t1 = up_vel/total_vel;
t2 = asin((Vxx*Axx + Vyy*Ayy + Vzz*Azz)/(9.81*total_vel));
}
pot_slope = ((t2/3)*SGD_RADIANS_TO_DEGREES)*factor + vel_y;
The values of Vxx, Vyy, ... are called in for the JSBSim and YASim both, but
Axx, Ayy, ... are called for YAsim only, rendering the HUD element to
indicate velocity only.
As for reference plane, I'm hazy as to the effect of the frame on the
reference but would lean towards the geodedic or earth-referenced
acceleration. I
have been through the flight.cxx and .hxx files along with the
src/FDM/JSBSim.cxx and YASim.cxx and have come away with the v_dot_local,
Get_ and
Set_Accels_Local as the given terminology in the NED sections, although
these
may be in name only and not function.
To refresh the initial query; I would like to use the energy marker within
a training tool using a simple single trainer but I need 2 VOR's for
intersection identification. The PA-28 -YASim provides the energy marker and
the
c172 - JSBSim provides the avionics... hmmm...
Thanks,
Mike
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
In a message dated 5/20/2005 12:49:29 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Or if you really want to cheat: use the Cessna 3D model with the Piper FDM configuration. :) I think that's how this whole thing started... YASim FDM with c172 model results in a YASim solution error - insufficient elevator trim. I could start altering the geometry or moving the CG, but I was hoping NOT to upset all the previous efforts put into the model. Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Mike wrote: Andy Ross wrote: Or if you really want to cheat: use the Cessna 3D model with the Piper FDM configuration. :) I think that's how this whole thing started... YASim FDM with c172 model results in a YASim solution error - insufficient elevator trim. Not the C172 model (which, for many reasons, is not going to be maintained as a YASim plane). I mean use the Cherokee model. You can use the 172 panel and graphics with another airplane's FDM configuration. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Mike wrote: Could you send me some specifics on the above procedure? I'm playing around within the pa28-set.xml without much success. In your Aircraft/c172p directory, edit the c172p-set.xml file and replace these lines: flight-model archive=yjsb/flight-model aero archive=yc172p/aero with: flight-model archive=yyasim/flight-model aero archive=ypa28-161/aero I didn't test this, but it should work for a quick hack. The result will be an aircraft that looks like a Skyhawk but flies like a Warrior. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
We can do this, it will just take some thinking. And, yes, Mathias is the expert, here. Thanks for your input, here... I'll sit tight and see if Mathias can respond. Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
?? I would have figured the HUD symbology is FDM-independent. That would be ideal, however there seems to be a dis-connection between the EOM in the JSB models that's present in the YASim model. Of course, I'm comparing the PA-28 to the c172 models, but the PA-128 will drive the energy markers within the HUD according to model velocities and accelerations while the c172 seems to pass a zero value for the accelerations and the energy markers just hang onto the velocity vector values. Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] c172r-yasim solution error
That would be ideal, however there seems to be a dis-connection between the EOM in the JSB models that's present in the YASim model. Of course, I'm comparing the PA-28 to the c172 models, but the PA-128 will drive the energy markers within the HUD according to model velocities and accelerations while the c172 seems to pass a zero value for the accelerations and the energy markers just hang onto the velocity vector values. Mike Can you be specific? Which accelerations are zero. This may be a bug. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Can you be specific? Which accelerations are zero. This may be a bug.
hud_ladr.cxx defines:
// OBJECT MOVING RETICLE
// TYPE ENERGY_MARKERS
// ATTRIB - ALWAYS
//energy markers - compute potential slope
if(energy_marker) {
if (total_vel 5.0) {
t1 = 0;
t2 = 0;
} else {
t1 = up_vel/total_vel;
t2 = asin((Vxx*Axx + Vyy*Ayy + Vzz*Azz)/(9.81*total_vel));
c172 JBS Axx, Ayy, Azz seem always zero where PA-28 and A-10 YASim have
values. This effectively makes t2 = 0 and defeats the pot_slope from any
value
other than Vx, Vy, Vz.
Mike
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] c172r-yasim solution error
c172 JBS Axx, Ayy, Azz seem always zero where PA-28 and A-10 YASim have values. This effectively makes t2 = 0 and defeats the pot_slope from any value other than Vx, Vy, Vz. Mike Interesting. Since I lost a hard drive recently and haven't had time to reinstall FlightGear yet, I'll have to get to this later, but maybe someone else can have a look. I'd be interested to know what drives Axx, Ayy, Azz. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] c172r-yasim solution error
I'm a bit hazy on the reference frames, and I don't have a book handy, but it looks to me as if JSBSim doesn't calculate accelerations in the local frame (north, east, down). Maybe Jon or Mathias can weigh in on this, but looking at Propagate.h I see local-frame velocities available through GetVel(), body-frame accelerations available through GetUVWdot(), but I don't see a way to get local-frame accelerations. Dave We do have vUVWdot, which is body frame. We also have Tb2l, which is a transformation matrix that goes from body to local. This is where it gets hazy for me, too, and I have to sit and think about it, but since the body frame is rotating wrt to the local frame, I think there is an acceleration due to the rotation, as well, so one cannot simply transform from body axes to local frame. We can do this, it will just take some thinking. And, yes, Mathias is the expert, here. This is where it gets a little hazy for me, too, but IIRC, vVeldot = vUVWdot*Tb2l + vPQR*vUVW If that's not right, it's something like that, and I know we can calculate it. But, I'll really be surprised if it's not being calculated somewhere already. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Michael G. Grizansky wrote: I noticed an earlier post regarding the A-10 yasim model with the same error and the repair seemed a simple typo repair, ( filght vs. light) in the control area. Is there some way I could perform some maintennance on this model or am I bumping up against a steep wall. Sure, if you like. Check out the README.yasim document for a start, and maybe read through the archives for issues other people have had. The error message you are seeing indicates that the solver runs out of elevator authority before it can get to the approach angle of attack specified in the configuration file. The standard way to fix this involves some combination of: + Increase the elevator authority in its flap definition. + Increase the horizontal stabilizer effectiveness + Move the c.g. rearward with ballast. But again: it is unlikely that this model will be maintained in the future. The standard FlightGear 172 is a JSBSim model, and it works quite well. If there is something specific you need from the Skyhawk model, you might best be served by modifying the JSBSim one. And if you want a YASim lightplane, definitely check out the pa28-161. This is very well tuned (by David Megginson, who actually owns such a Cherokee) and works great. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
But again: it is unlikely that this model will be maintained in the future. The standard FlightGear 172 is a JSBSim model, and it works quite well. If there is something specific you need from the Skyhawk model, you might best be served by modifying the JSBSim one. And if you want a YASim lightplane, definitely check out the pa28-161. This is very well tuned (by David Megginson, who actually owns such a Cherokee) and works great. Andy A, At your suggestion, I spent this AM looking at the Cherokee / Warrior and agree it's as realistic as needed. My problem arises in the radio/nav stack where the individual VOR's cannot be set independently like in the c172, ie: the headings on each OBS are always the same. I'm looking into an instructor's aide for IFR approaches and would like to define an approach path intersection with the second vor-radial, easy to do with the c-172. To add to the confusion, I'm using the energy markers in the HUD to define inputs to the student and the Yasim FDM seems to support more HUD components than the JBS FDM... although I haven't spent too much time in the hud_ladr.cxx to find the links... Mike ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] c172r-yasim solution error
I'm using the energy markers in the HUD to define inputs to the student and the Yasim FDM seems to support more HUD components than the JBS FDM... Mike ?? I would have figured the HUD symbology is FDM-independent. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
MICHAEL G KRIZANSKY wrote: I'm getting a YASim Solution Error when I try to run the c172r-yasim. The error states insufficient elevator for trim and FG then aborts. Is there anyone that can point me in the right direction. This particular configuration isn't maintained. I did it long ago when submitting YASim as a proof of concept (basically duplicating JSBSim airplanes). The official/maintained Cessna is the JSBSim model. If you want a good single engine example of a YASim aircraft, the pa28-161 is your best bet. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172r-yasim solution error
Andy Ross [EMAIL PROTECTED]Sent by: [EMAIL PROTECTED] 05/16/2005 04:23 PM MST Please respond to FlightGear developers discussions <FLIGHTGEAR-DEVEL@FLIGHTGEAR.ORG> To FlightGear developers discussions flightgear-devel@flightgear.org cc bcc Subject Re: [Flightgear-devel] c172r-yasim solution error MICHAEL G KRIZANSKY wrote:I'm getting a YASim Solution Error when I try to run the c172r-yasim. Theerror states insufficient elevator for trim and FG then aborts. Is thereanyone that can point me in the right direction.This particular configuration isn't maintained. I did it long ago whensubmitting YASim as a proofof concept (basically duplicating JSBSim airplanes). Theofficial/maintained Cessna is the JSBSimmodel. If you want a good single engine example of a YASim aircraft,the pa28-161 is your bestbet.AndyI noticed an earlier post regarding the A-10 yasim model with the same error and the repair seemed a simple typo repair, ( filght vs. light) in the control area.Is there some way I could perform some maintennance on this model or am I bumping up against a steep wall. Mike ___Flightgear-devel mailing listFlightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
