On Tue, 29 Mar 2005 09:45:43 -0500, Eric wrote in message
[EMAIL PROTECTED]:
On Thu, Mar 24, 2005 at 03:24:01PM -0500, Jeff McBride wrote:
I am looking into the possibility of using FlightGear as a simulator
to test flight control software that I am developing for a UAV
(Unmanned Aerial Vehicle) project. The idea is that I will take
control values (ailerons, throttle, etc) from the telemetry link
and pass them to FG, then take the resulting location, speed, etc.
from FG and pass it back to the UAV as if it were coming from the
on-board GPS.
Sorry for the delayed response, I just noticed this thread yesterday
and wanted to talk to my employer before posting ...
We have had a similar setup working in our lab for over six monthes.
It is a hardware-in-the-loop simulation for testing our UAV hardware
and adaptive autopilot. I am hoping to get a paper out in late Summer
(at AIAA's [EMAIL PROTECTED]) which will cover the details. I'll
provide an overview below. If anyone is interested in more details,
let me know.
From what I can tell, FG has support for this kind of thing, but no
documentation of it. So, my question for the experts is what is the
best way to do this? I was going to try to use the generic
network interface, but as far as I can tell it doesn't support a
bi-directional link. Perhaps I can run two of these (one in, one
out), but is there a better way I should be looking at? There seem
to be a lot of options.
Our hardware, an embedded computer running Linux, interfaces with
sensors and acuators via a serial port. We wrote a small briding
application which reads the data from FlightGear using the native I/O
(FGNetFDM and FGNetCtrls) and translates the data to the same format
as produced by the sensors (i.e. the bridging application generates
NMEA GPS packets).
As mentioned in the thread, the code is setup to read all available
data from the sockets and throw away all but the latest packet. Once
everything is initialized, we can operate easily at 50Hz sending and
receiving a single packet to FG within the timeslice.
The controls packet contains quite a few fields and, in addition to
the expected aileron, elevator, rudder, and throttle, a few others are
required. I'd have to dig back through our code to see what we set if
you are interested. All of the information you need to simulate your
sensors should be in the FDM packet; be careful with the units.
Of course, my next problem will be creating a model of the plane I
am flying, but I am waiting until I get there to tackle that one.
Creating the model was definately the hardest task. During initial
testing, we used the models available in Flightgear, mainly the Cub,
as it was one of the slowest flying airplanes. We have since
developed a working JSBSim model of our R/C sized aircraft. We should
have some flight test data in the next month which we will be able
to compare to FlightGear to gauge how accurate our model is.
Hope the information proved useful and as I mentioned above, if anyone
is interested in additional details, please let me know.
..oh yeah, shoot! ;o)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
___
Flightgear-users mailing list
Flightgear-users@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-users
2f585eeea02e2c79d7b1d8c4963bae2d
