On 3/23/07, Nicol Carstens wrote:
Hi guys.
First of all (before I start "complaining") let me start off by saying:
thanks for sharing your work publicly! MUCH appreciated. If you don't
mind,
and have some time to spare me, I need to ask a question...
About myself and my project: I am qualified as an electronic engineer (did
a
masters in control of a model RC helicopter), and have about 6 years
simulation experience in the Aerospace industry. I am trying to use
FlightGear for autopilot/AHRS development work... I am looking at the data
as received from the Native-FDM UDP packet (at 20-40Hz). Maybe I am
missing
something (not at all impossible)... but I think something might be
wrong...
I am using FlightGear Version 0.9.10.
My question:
If I put the aircraft (Cub or 172) into a constant bank and pitch angle
turn
("trimmed"), I expect phidot and thetadot to be near zero, and psidot
non-zero... Yet, I see thetadot near zero, and phidot and psidot non-zero
(as a matter of fact: phidot is almost as "large" as psidot). Surely this
can't be right? According to the FlightGear (and MathsWorks / Matlab)
documentation, this is not p,q,r but Euler/Gimbal angular rates in
rads/sec... not body rates...
I know that the pitch and roll angles are constant because I can see it
visually in the sim, and confirmed looking at the UDP data (roll, pitch,
yaw)...
My goal: I want to derive p,q,r (simulate rate gyroscope sensors) and
calculate the horizon... Building an AHRS. But if I use the current data,
the angles are drifting even faster than using the real hardware!!
Am I missing something, or is there a bug??
Hi Nicol,
After a quick glance in the code, I don't see anything obviously wrong.
Here's one thing for you to try. Fire up the simulation and setup your
aircraft in a stable continuous turn (non-zero roll angle, but zero roll
rate.)
Now open up the property browser (under the file menu) and look in the
/orientation "directory". What is the roll angle and roll rate there? If
that looks correct, then the core FlightGear code should be ok.
Now if the output of your net-fdm packet shows something different, the
problem must be either in the creation or the decoding of the net-fdm
packet. I did a quick look at the code on the FlightGear side and couldn't
see any obvious problems in creating the net-fdm packet. If you are still
seeing a descrepancy between internal roll rate in FlightGear and the value
you are receiving (beyond a simple deg/rad conversion) then I would also
check your net-fdm packet decoding code as well.
Shouldn't be too hard to determine if this is a core FlightGear issue or a
communication issue.
Regards,
Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
