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. Eric -- Eric F. Sorton <[EMAIL PROTECTED]> _______________________________________________ Flightgear-users mailing list Flightgear-users@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
