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 [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-users 2f585eeea02e2c79d7b1d8c4963bae2d
