Thread Tools
Aug 04, 2008, 01:42 AM
Registered User
Thread OP

Try it: Desktop Simulation Software

This is the first public release of PDAPilot for the desktop. Consider it alpha--it's very rough, but I think it will provide a window into the operation of autopilots that most will not have seen before. If you want your autopilot turn-key, this isn't for you. If you really enjoy tweaking and understanding how things work, I think you will watch this for hours on end. I'll release the source in a few weeks. It's always a ton of work to release source, believe it or not. Source at this stage is filled with half-baked ideas that were commented out, there are ton of unused vars, things need to be restructured, licenses for 3rd party component licenses have to be checked, etc.

As with the waypoint builder SW, you install this from the web each time your run it. In the future that will change. But for now, trust me this is the most painless way to do this.

To get the full desktop environment working, you need to install flightgear, which is a great app written by CLOlson (frequent poster at RC groups) and copy some config files to your machine. Instructions are here for getting the config set up and getting the apps talking to each other:

FlightGear provide a flight sim that can be controlled by an another program. PDA Pilot functions as the autopilot for this program. If you have followed this thread ( you are hopefully aware that PDA Pilot is an autopilot that lives in a PDA, and that PDA goes onto your airplane. I'm super excited about where that will be headed in the future. For now, the engine that runs on the PDA is running ont the desktop, and there is a ton of real-time analysis provided for you to look at and tweak. Today, you can tweak the various gains. In a few weeks, you can try your hand at major algorithmic changes using freely available Visual Studio Enterprise edition. And when you are happy with how your code runs on the desktop, it'll be a snap to move it to your airplane.

The attached jpg shows you the environment. Not shown is a small window with the cockpit view from FlightGear. That allows you ride along with the plane and see what it is experiencing.

The upper left graph shows you the desired altitude, the current altitude, and the elevator action in real time. The graph to the right of that shows you the desired bank, the actual bank and the aileron position in real time. To the right of that, you have a list of waypoints. These are auto-generated right now. When you get to teh last waypoint, new waypoints are generated to automatically bring the plane back to circle around the launch point.

The map shows you the location of the waypoints and the path taken. The red dots are 1 Hz GPS updates, and the 10 green dots between each red dot are esimtates of the current location. To the right of that, you have a list of parameters. To the right of that, you have a section in which you can add noise to the various sensors. This isn't hooked up, but will be expanded to include gyro drift. You will notice in the first graph that the altitude is indeed fuzzy. that's because it is being fuzzed up by noise, and that noise is similar in in nature to what the SCP1000 altitmeter will generate. Noise is importantto simulate because some parts of your PID loop (deriviative) and roll and pitch estimates are very sensitive to noise.

At the bottom, you have some visual dials showing VSI, speed and bank.

There's a big button to turn the autopilot on, and a small button to turn it off.

Finally, there are the various gains. Follow the instructions above, and the plane shoudl fly pretty well right out of the box. Crank the pitch or bank proportional term up, and you'll see the plane start to oscillate. Reduce the I setting on altitude, and you'll see an altitude offset error creep in. But more importantly, you'll readily see this in the graphs. This, to me, is incredible to watch and learn. Over the coming weeks, I'll expose some more of the internal parameters are being tunable.

In any case, I'd love to know if you were able to make it work at all. You will need a fast machine, and you do need to be running windows.

To run the app itself (which doesn't do much if you haven't installed flightgear) start here:

Let me know if you try and are able to make it work or not.
Sign up now
to remove ads between posts
Aug 04, 2008, 03:02 AM
Registered User
Nice concept, i'm kicking around the idea of doing something similar. Have you hit any walls using the .net CF framework ? What kind, and what quantity of sensors can you hook up to your pda?

Curious to see how your project pans out.

Aug 04, 2008, 12:11 PM
Chris Anderson
very impressive! Just out of curiosity, why did you decided to use PDAs as the target platform? (I realize it works on desktops as well, but the name suggests you're heading towards handhelds)
Aug 05, 2008, 12:17 AM
Registered User
Thread OP
Updated. Substantial improvements to real-time graphing (see attached) and substantial reductions in CPU needs. The Autopilot is consuming around 4% of the total CPU while running, even with all the GUI updates. The core autopilot code, the same stuff that runs on the PDA, takes a few hundred microseconds every 100 mS. All the 64-bit floats and full math lib. Rock on.

Same link as before:

The attached graph was taken while the plane was in flight. Tweak the gains, wait for a turn, copy the graph to a ppt slide, change the gain, repeat, etc. Then you have a family of curves to study and understand.
Aug 05, 2008, 12:30 AM
Registered User
Thread OP
Originally Posted by zlite
very impressive! Just out of curiosity, why did you decided to use PDAs as the target platform? (I realize it works on desktops as well, but the name suggests you're heading towards handhelds)
Smartphones are included in that, but it's easier to just say PDA

The writing is on the wall (to me). Reduce the proprietary hardware to the smallest and cheapest thing possible (sensors only), and use off the shelf hardware and world-class tools to write the software as quickly as possible. I use eclipse a lot, and it's worlds away from Visual Studio. I've written a lot of code in C and C++, and those languages are major impediments to getting high quality code done quickly.

NVidia has announced 720p encoding and decoding in CPUs next year targeted for PDAs. Wireless and GPS is already built in. The PDA is your all-in-one box that you can upgrade every year to bring incredibl new functionality to your UAV.

Arroive at the field, view the terrain maps directly on your PDA, click in points of interest and waypoints, set recording for 720p hi-def when you aren't taking pictures. Throw the plane in the air, have a voice in your ground-based PDA relay distance to waypoints and overall health while you monitor from the ground. And no laptop in sight. And no extra wires in the plane. Just hang a PDA from teh wing and go.
Aug 05, 2008, 12:38 AM
Chris Anderson it. Smartphones do indeed make a lot of sense. We built a navigation-only autopilot on a Windows mobile smartphone a couple years ago, which worked okay but we found it hard to make the code portable enough to handle different phones and evolving technology. Now we (and our pals at Pict'Earth) are working with Nokia N95s, which will be a lot easier to play with once Symbian delivers on their open source promise and drops the painful signing process.
Aug 05, 2008, 01:09 AM
Registered User
Thread OP
Althought Nokia ships a lot of Symbian phones, they are about the only one, and their phones have never been known for being tiny and light. And the development tool story for Symbian isn't so hot IMO. It's a pretty old architecture that goes wayyy back and carries a lot of baggage. You should give windows mobile another try
Aug 05, 2008, 07:32 AM
Registered User
Congratulations Matttay!!! i really think it is the way to start a good UAV project.

In fact, I am making exacly the same stuff, i am using the MATLAB.

A exlpanation of my experience here (Spanish):

Files with .m files here:
and FlightGear configuration files here:

This matlab files are for "time speed" x 6, it is very interesting feature of flightgear for uav testing

Jose Luis
Aug 05, 2008, 10:00 AM
Chris Anderson
Originally Posted by matttay
Althought Nokia ships a lot of Symbian phones, they are about the only one, and their phones have never been known for being tiny and light. And the development tool story for Symbian isn't so hot IMO. It's a pretty old architecture that goes wayyy back and carries a lot of baggage. You should give windows mobile another try
I agree. The reason we picked the N95s is that they have the best cameras available on a 3G smartphone today, with a Zeiss lens and a 5MP sensor. But I have no doubt that some Windows Mobile phone will someday match that. Which phone are you looking at?
Aug 06, 2008, 04:59 PM
Registered User

Wow thanks!

I have been a casual observer and day dreamer when it comes to to diy autopilot uav community. If your looking for feed back on your PDA Flight Gear application all I can say is it ran flawlessly on my machine. I don't see the map on it but I can make changes to the autopilot interface for heading in the flight gear drop down menu autopilot settings and it changes heading. I also read your enteries about using the smart phones for uav and I have to agree it is a great idea!

So when do we get the source code for all this so I can throw it into my visual studio and start seeing how this all works? I really appreciate people like you showing the way into this stuff. It is something I have been very intrested in for a while and now it looks like I've got a starting off point. Zero capital investment so far, lol!

Thanks agian for being so forth coming with the information, looking forward to your next posts!
Aug 08, 2008, 10:57 AM
Registered User

optimize time in flightgear autopilot testing

I am success using Flightgear with Matlab

to this moment i was trying basic control at high altitude but now i am testing landings and it is more dificult because test time are too long due i have to re-start simulator each time i try.

i have some ideas about how optimice testing process:

- Disable graphics? or remove scenary?

- or Could i make a remotely reset or update initial position (latitude, longitude, altitude...) through UDP and the leave to fly another time?

any idea?

Aug 11, 2008, 02:21 AM
Registered User
Thread OP
OK, a new release is up here:

This has a lot of visual cleanup, and also makes it easy to turn off traces on the graph of the various parameters.

Also added is the pilot accelerations from Flight Gear. These aren't graphable (yet), but you can see them in the status display. I've been down a lot of roads this week, as I've tried to take the pitch/bank info from flightgear, and then synthesize that into gyro data, and then re-synthesize that in to pitch and bank values as measured in degrees. Along the way, there's the option to add in gyro drift and noise.

Currently, I'm using several minute averages of the gyros to establish the average, and then using that as a reference for the rotations. However, while this works quite well on the actual airplane, it's not working as well in the simulation. I suspect it's because there's not any bandwidth limiting happening inside flightgear in the reported data, and as a result it's akin to sampling data without any antialias filter. Unfortunately, the damage is done once it arrives into my app, adn the result is that even with gyro drift turned off, the estimated pitch and actual pitch drift over time. To estimate pitch and bank, I'm looking at rate-of-climb and velocity as an indicated of pitch, and rate-of-turn and velocity as an indicator if bank. What happens in the code is that pitch data from teh gyro is allowed to accumulate for two seconds, and then at that point, the gyro data is average with the rate-of-climb pitch estimation taken over the last second. This works reasonably well, but there are likely more improvements to be had. There's a picture of the estimated and actual pitch and bank during flight. Bank is dead on, pitch is still in need of some work. But have faith, because as I noted the real airplane has been much more kind in this regard. One area to note is that after all the waypoints have been flow, the airplane flies back home to its launch point and flies a circle over head. This is problematic, because it doesn't currently give us a good reference (straight and level flight) to recal the gyros. So more thinking is needed here.

There's a new file that I've not shared before called "sensors.cs". This is where all the sensor data is munged. The purpose this file is to build all the various representations of the data the entire autopilot requires from just a limited set of sensors (or in the case of the desktop SIM, the values that are retrieved from FlightGear). This is also where all the gyro processing and estimation logic lives, so be forewarned it's messy and without much guidance in the form of comments.

GPS lag has been introduced into the simulation. YOu can decide to lag the GPS readings by 0, 1, 2 or more samples. It's actually pretty devastating on teh simulation, and it has a huge impact on the rate of turn, and the ability to converge. You can trim the gains to help, but less lag the better from the GPS.

Some perf monitoring metrics have been added. You can see a figure noting "IpS". This is interrupts per second. We desire running the simulation at 10 interrrupts per second (not really interrupts, but I think everyone gets that), and as we drop below that, things become less ideal. Now, as you run things on a low-spec machine, this figure could dip to well below 9, and at that point you'll know why things are going south. Dont' worry that it's not exactly 10--there's some overhead issues that I think I understand that is the reason. Just make sure that when you run it's over 8 or so.

That's all for now. The source is included here:

It should be buildable with the free MS C# Express Edition, but I didn't confirm that. It's a fairly manual process for me right now to do a source release, because I use links to source files all over the place on my hdd. To release the source I need to copy the project and manually fix up the links. So, I won't be able to do a source release frequently until things get restructured.

Note the source is still really, really nasty. I'll clean up a lot in the coming week.

PS. One other cool thing is that the autopilot has flown the full-sized J3 Cub and the RC Rascal with the same settings. This is encouraging, for sure. But if you really pusht he speed on teh J3 you'll see problems for sure.
Aug 11, 2008, 02:25 AM
Registered User
Thread OP
Originally Posted by mrb0y
I don't see the map on it but I can make changes to the autopilot interface for heading in the flight gear drop down menu autopilot settings and it changes heading.
YOu might not have been seeing the impact of my app at all. The autopilot drop down is for FlightGear's autopilot.

Can you tell me the starting GPS location for your flight? Were you talking off from SFO airport? I know for sure if you have a location outside of the US you won't see a map. Also, make sure FlightGear is all the way running and ready for takeoff before starting the autopilot app.
Aug 13, 2008, 02:33 PM
Registered User


Ok, I wanted to make sure I was doing things right before I posted, it took me a little bit more setup than I would regularly devote, but I figured it was worth it and I was right. You are correct about the UI in flight gear, it caused a few set up problems even after careful consideration of those problems were taken into account. Long story short, I had a terrible time getting it set up but once I did the everything worked as advertised!

On the PDA Autopilot application side of things it could not have been easier, just start up the application and watch it do it's thing. It was able to make it to the 3rd way point and crash??? I'm going to post a few screen shots though I don't think they will be very helpful.

Is there a way to generate a log of what the autopilot has done so we can go back in and trouble shoot???

I have the source you released running in the express version of C#, I have Visual Studio 2005 but it would not let me open the project stating it was created in a newer application version. I think it's great that you posted the source as a project in express so everyone can get involved at no cost.

I'm going to have to brush up on my C and everything else, lol but that is one of the motivating factors for getting into this. I took a glance at the code but I just got to the point where I could get everything running.

I would like to thank you again for taking the time to share your work, it really is nice to get a look into this from some one who is as knowledgeable and forthcoming as your self.

I'm still shopping for a broken smart phone and will most likely go with an easy star derivative of some sort for the platform.

Should I have expected the autopilot to crash at any point during the default flight plan???

I wonder if I induced an error by an inadvertent input to the flight gear window at some point???

I guess if there was still focus on the flight gear window and I moved the mouse???

At any rate I'm going to play with his some more as time permits, thanks a ton!!!!

Aug 14, 2008, 02:18 AM
Registered User
Thread OP
It's good to hear you have it running. I just published a new version that has a checkbox near the graph that says "Use Gyro Estimates". Same link as the old version (...publish.htm).

The version you were running synthesizes gyro values from actual pitch values, quantizes those to 10 bits, and then attempts to derive the pitch and bank from those values. That was a bulk of my time last week, and yes, it can crash the airplane if measured pitch/bank values deviate from actual. I'm getting ready to go back to my original plan of having alt error drive elevator, because having alt error drive pitch (current case) requires pitch accuracy within a few degrees. And actually even with perfect pitch accuracy some of the models in FlightGear hold level altitude with a few degrees pitch down, which means alt error driving pitch never quite converges. Yes, you can band-aid and make the algorithms more and more clever, but the previous version was working much better than the current version and wasn't so susceptable to gyro drift and it was simple.

When you try the current version, run a full course with the "Use Gyro Estimates" checkbox unchecked. It shoudl be rock solid with 25m waypoints. Let me know if that works for you.

If you want to change the code on your end, in sensors.cs the code is:

if (UseGyroEstimates == false)
PitchAngle_deg = SimPitchAngle_deg;
PitchAngleHistory_deg.Add(PitchAngle_deg); //*


if (UseGyroEstimates == false)
BankAngle_deg = SimBankAngle_deg;
BankAngleHistory_deg.Add(BankAngle_deg); //*

The lines with //* are existing inside the update function. Hopefully you can hook thecheckbox up to those.

Glad you can compile this with free c# version. Let me know how the unchecked version works for you.

Quick Reply

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Need Flite simulation software CROSSWIRED Micro Helis 4 Apr 29, 2009 04:17 AM
simulation software to practice 3D hovering curtqn Simulators 9 Jan 18, 2005 10:17 PM
Anybody try pro/DESKTOP for three dimensional plane design? mike98624 The Builders Workshop 26 Apr 24, 2003 09:43 PM
Anyone made "Simulation software" for E3D? Fast Fly Sport Planes 7 Oct 20, 2002 04:31 PM