Gary Mortimer and I are leaning towards a simulation round for the next T3 contest, but I need some feedback about what would work best.
There are two kinds of simulations: "open loop" and "closed loop".
Open loop means that you connect the output of the simulator to the input of the autopilot. The simulation drives the autopilot with synthetic GPS coordinates and sometimes synthetic attitude data, essentially replacing the autopilot's sensors. This basically fools the autopilot into thinking that it is flying, and you can watch how it responds. This is typically done by having the simulator output data via the serial port and feed that into the autopilot.
Closed loop means that you also connect the output of the autopilot to the input of the simulator, so that the autopilot is "flying" the aircraft on screen. This usually requires a relatively complicated bit of hardware that converts the PWM servo output of the autopilot into what amount to joystick commands via USB or serial that steer the plane in the simulator. It can also be done entirely in software on the host PC, as in the case of Matlab simulations being driven by a flight simulator.
Here are some blog posts that show examples:
--Curt Olson's FlightGear demo
--Faisal Shah closes the loop, Part 1
--Faisal Shah closes the loop, Part 2
Here's a proposed contest structure:
Two sets of winners:
Both must write "DIY" (in cursive) over a place of their choosing.
--Group One: Open loop (video showing you mirroring the airplanes control surfaces with the arrow keys): First six to complete this win a $25 gift certificate to the DIY Drones store.
--Group Two: Closed loop (aircraft controls the flight simulator): First three to complete this win a $50 gift certificate.
What do you think? Is this doable?
Comments
There is a (very) rough cut of an EasyStar on gitorious:
http://gitorious.org/ron-s-hanger/easystar-rc/
It can be had as a tarball from here:
http://gitorious.org/ron-s-hanger/easystar-rc/archive-tarball/master
The directory must be renamed "EasyStar"
This plane must also be started "in the air" as the
current engine doesn't have enough power (70 watts) to overcome the
ground drag.
It still needs its aerodynamic coefficients tuned, too. It seems rather
pitchy.
B
I finally ended up with input data coming in on 1 port via the RF link and output data to PicPilot via another port using the USB interface on the PicPilot. Now the issue seems to be I can only use extremely slow update rates (on the order of 10Hz or less) or FlightGear starts throwing errors on the log screen and the plane spirals to the ground. I'm shooting for 50Hz both ways as that's what the internal loops run at.
It was late last night when I got to that point, so I may have a bone head bug in there somewhere, but any help from the local experts would be appreciated. I'll hit some more tonight.
I'm running a quad core with relatively new graphics card (yes, I'm a gamer) so I don't think that's the issue.
Brian
- The commands to the autopilot are initially fed to the ap through HyperTerminal - which is then closed
- UAVStation is started to show the progress of the simulatinon - then closed
- HyperTerminal is started again; to stop sim in autopilot - then closed
- A batch-file is started to download log from ap
- A new batch-file is started to decode the log, (generate kml-files etc)
- One of the KML-file is opened in GoogleEarth
http://www.vimeo.com/10561473
log.txt.TRACE-001.kml