For the last T3 round before the weather improves (in the Northern Hemisphere), we're going to do something indoors! It's a simulation round, which I previewed here.
I'll repeat the basics:
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 the contest structure:
Two sets of winners:
Both must write "DIY" (in cursive) over a place of their choosing. Example above from brakar, who, like Jesse & Jared, have jumped the gun a bit and already submitted successful entries for this round.
--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.
A special top prize will go to the person who best documents how they went about it and creates a useful tutorial for others to use afterward (judge: Gary Mortimer). The prize for that will be the notorious Raven UAV clone (unless the winner requests something else, in which case I may grant mercy and come up with something of equal or greater value).
Also, as suggested by Brian Wolfe, anyone who completes either of these rounds will get points added to their grand total: One point for open loop and four points for closed loop. Here are the current cumulative rankings after five T3 rounds:
Brian Wolfe 31
Vassilis 24
Brakar 23
Mark Griffin 18
Krzysztof Bosak 17
Andrus Kangro 12
Jesse Jared 8
IOS 6
Bill Premerlani 6
MarcS 6
Joe 6
Steve Joyce 5
Steve Westerfield 3
Chris Anderson 3
Icebear 1
Entries must include a video and KML track and a description of your simulation setup (flight sim, autopilot, other hardware). Submit your entry in the comments below by 12:00 midnight PST on Sunday, May 2nd.
Comments
Yea, it's the normal hardware. I just have one software load that works for both HWITL and real flying. If I receive a certain command via the USB port I switch over to HWITL mode and start using the received HWITL packets in place of real sensor data and start spitting out control surface commands via the USB port. If the servos were plugged in to the PicPilot they would still actually move. In addition I change a couple gain terms to support the current Rascal model in FG. The rudder response of the Rascal in particular is about half what the AXN Floater is, so I double that gain term. My plan is to modify the FG model so I can use exactly the same gain terms.
I also plan to add some more features to the custom app such as adding noise and bias to the rate and acceleration data. I already filter it to 12 Hz to simulate the analog filter on my hardware. It wouldn't be hard to filter the control surface commands either to simulate bandwidth of the servos and backlash in the control coupling. Those are secondary effects though and probably not that important with a fixed wing.
I should also note that when doing my calulations in the autopilot, all surface commands are normalized between +/-1 indicating full throw in the positive or negative direction. It turns out that Flight gear is expecting the data in exactly the same format. I don't convert that normalized value to an actual pulse width until I pass the data to the PWM generator. It makes the code easier to follow because I'm not carying around the baggag of a weird counts to pulse width gain term and it means I don't have to do anything special to pass the command to FG.
The video also came out stretched after compressing. Not sure why.
Long and somewhat boring, but here you have it.
DIY Drones T3-6 - Simulation from Brian Wolfe on Vimeo.
Software used:
Flight gear 1.9.1 (Flight gear 2.0 has serious problems - avoid at this point until an update is released)
Custom Software written in Borland Builder to pass data between Flight gear and the autopilot using UDP sockets and serial (USB) interface.
This app also logs the GPS data for generating the KML file.
The basic structure is this: Flight gear passes body rates and accelerations to the PicPilot along with Lat, Lon, heading, speed and altitude. Basically all the data that would otherwise be captured by on board sensors. This data is processed by the autopilot just as if it had come from the real sensors.
After processing the data, the PicPilot generates aileron, rudder and elevator commands for the purpose of navigation and stabilization. These commands are fed back to Flight gear which uses them to compute aerodynamic forces on the aircraft and move it accordingly on the screen. All this is done at 50Hz.
I'll add links to the software I used including the interface app and Flight gear Configuration files in the next day or two. I also need to post the video but it's 2.5GB at the moment so I need to do something about that.
Rascal_Run_3.kmlKML File
B
I'll keep tweaking things and should have a complete entry and writeup soon. Important note at this stage is avoid FG 2.0 and stick with 1.9.1.
B
I experienced this problem with FG2.0 and rolled back to FG1.9.1. FG2.0 doesn't wait for new values, it just hangs if you don't send enough data. So I use FG 1.9.1 because its UDP queue lag is known and avoidable.
I've looked a bit at X Planes as well, but I guess body accelerations are hard to get from the sim via UDP (rates are no problem). I need accels for closed loop HWITL if I want to use my internal attitude estimator. A final "punt" approach will be to generate estimated rates and accels internally myself and just feed the attitude to FG so it can display my position and attitude - an approach some of the other sim setups seem to be doing, but I'd really like to take advantage of the heavy duty modeling in FG or XPlanes.
The quest continues.....
Thanks very much. I'll give that a try. Sort of a modified poll and response setup instead of just asynchronously sending packets to FG.
I'll post what I find.
B
I fought with latency in the begining of FG use. And I found that rising FG input frequency doesn't solve the problem completely. So I decided to add a variable to FG property tree and use it as a packet number.
FGWrapper does the following:
1. Gets a packet from FG with values of attitude, position, etc and "FG_packet_number"
2. Converts and sends values to the autopilot
3. Reads and converts response from autopilot
4. Checks the difference between "FG_packet_number" from step 1 and "internal_packet_number". If this difference is more than threshold (I use "3" as value) then skip step 5 (synchronization case)
5. Increases "internal_packet_number" and sends it back to FG with other values (normal case)
In other words FGWrapper periodicaly stops sending packets to prevent FG queue flooding.
I use the same gain in the simulation and real life.
-
1
-
2
-
3
-
4
of 4 Next