ArduPilot successful flight simulation

A photo of successful flight as seen in Google Earth and X-plane:

Here is another ArduPilot simulation inspired by Jordi's simulation.

My simulation requires minimum additional hardware, all you need is ArduPilot connected by FTDI cable to PC.
Actual simulation runs in X-plane simulator. ArduPilot get simulated GPS data over serial, and it returns back proposed servo positions back over serial as part of telemetry info (servos can also move physically). ArduPilot also reports bunch of variables - lat/lot/alt, next waypoint, distance to it, etc.

What you need to repeat the simulation:
- Modified ArduPilot code from this blog post
- X-plane 9 demo (buy full version if you wish, but demo works just perfect, it only ignores joystick input after 10 minutes, but we control it other way so it really doesn't limit us)
- Google Earth
- ArduSimulator (developed by me), which is simple application that does following:
1) Connects to ArduPilot over serial for sending/receiving data
2) Connects to X-plane on localhost (same PC)
3) Reads data from X-plane (lat/lon/alt/course), sending these to ArduPilot as GPS sentences
4) Simulating FMA copilot stabilization on ailerons/elevator
5) Reads and displays telemetry and servo positions from ArduPilot
6) Sends servo positions to X-plane to control throttle and rudder
7) Records fly path and sends it to Google Earth to display

Here's how to repeat the simulation:
- Start X-plane, go to Menu->Settings->Net Connections, select tab Inet 3 and enable "IP of data receiver", change IP address to and port to 49001. It looks like this:

- Select Aircraft from folder Aircraft\Radio Control\GP_PT_60 (yes, we want to fly RC plane which has ail/elv/rud/thr controll)
- Select airport Innsbruck
- You can open this KML path: Innsbruck.kmz in Google Earth, which was my testing fly plan configured in ArduPilot; this will show you the waypoints
- upload compiled ArduPilot code to the board and leave it running; LOCK LED should keep flashing
- start ArduSim.exe (simulator tool); it will connect to serial port and X-plane; if it can't connect to serial, specify correct port and baudrate and press Start button
- click [Google Earth] button in ArduSim to make connection with GE
- hit B in X-plane to release brakes, and try keys A/W/C to choose various views
Now simulation should be running if everything is connected successfully, and you should see plane in X-plane to fly and visualization path & icon in Google Earth to move. Don't control plane in X-plane! ArduPilot will take-off and fly on its own.

Here's video how it all looks in action:

And complete flight path visualization for Google Earth: Flight.kmz
You can see original waypoints in white, and real fly path in yellow. And also final circulation over start point when all waypoints were visited...

Now about problems and future tasks:
- I have strong impression that controlling altitude by throttle with use of copilot stabilization doesn't work properly, this simulation showed me that plane didn't want to drop altitude from high point to lower one... see results in above flight path in GE. I'm not sure how real plane behaves (didn't went out to real world with this yet), we'll see.
- For this reason I plan to start playing with complete stabilization in ArduPilot, and controlling both elevator+throttle to get desired altitude.
- You can play with dozen of various parameters to control behavior, most obvious are PID settings for throttle/rudder in ArduPilot, but also PID values in stabilization (which is here provided by simulator tool, in real world it is FMA Copilot which you can control by its sensitivity setting). Then you can change maximal servo rotation for ArduPilot to work with. All these values make the plane fly smoother, make more precise turns, etc etc. And the settings seem to depend on actual aircraft and its physical behavior. So there won't be single settings working for everyone.
- It's somehow cumbersome to specify different altitude for various waypoints; while I converted waypoints from KML file out of Google Earth, I had to specify individual altitudes manually in waypoints.h file in ArduPilot code.

After all, I'm pretty happy to see the plane flying in simulator and doing the task! Note that it's ArduPilot doing the navigation work. And in a real airplane, this simulation allows to reuse the ArduSim application as a base station, getting telemetry from plane over Xbee modem and displaying what it does as well as showing path in Google Earth.

Views: 4764

Comment by Michal B on February 2, 2009 at 4:43am
Ben: please make a blog post to describe how altitude hold by throttle works in real planes, more members have problem to get the idea.
Particularly, when FMA copilot stabilizes plane to fly on level, lowering throttle doesn't make it descend (at least not enough in my simulation), and throttle below some value makes the motor stop (simulator plane has gas engine). So explanation and tips how to fix it would help.
Comment by Ben on February 2, 2009 at 5:42am
Michal B

No problems, its been a long day at work and my brain has shut down for the night 8-)
In the next day or so i will start new blog post with some theory of flight in respect to climbing and decending and some suggestions


Comment by Reto on February 2, 2009 at 5:56am
Another way to a solution?
I imagine the Co-Pilot sensor sitting on an articulated board that could slightly tilt forward and backward with an additional servo control. We could imagine that a high altitude would be corrected by telling ArduPilot (on an additional channel, or why not in replacement or conjunction of throttle management), to swing Co-Pilot to the back. A low altitude could be corrected by tilting the Co-Pilot slightly forward.
I know it is a mechanical and not a software solution, but I am sure it could work nicely. Moreover, throttle control could be linked with such system to give out little more power for climbs and decreasing for for descent. Global throttle variation would be reduced and we could - for the better - forget about the hassle of setting up an airframe with too little downthrust to be able to climb when throttling up. More different flightspeeds could so be achieved.
Interested in knowing what you guys think about it.
Comment by Michal B on February 2, 2009 at 7:37am
Regarding altitude hold - I think that we have another problem, seen in Flight.kmz downloadable above.
ArduPilot's altitude target is those of next waypoint, so it try to climb/descend as soon as previous waypoint was reached. But desired altitude should continuously change as we travel to next waypoint, so that plane follows the line.
See this illustration:

So ArduPilot code should linearly interpolate target altitude between 2 waypoints, depending how far we're in way from one to next.
Comment by tychoc on February 2, 2009 at 9:09am
Wow, nice work Michal! I don't read the forum for one day and all kind of interesting developments happen.
I look forward to trying this out once my Ardupilot comes back from Sparkfun.


Comment by Sami Finnila on February 2, 2009 at 9:12am

Just realised that this will work with NXT just as well..! Well... With a little recoding anyways... The source, however, is a little puzzling with it's lack of comments and variables with confusing names (so it's just like my code basicly ;D ). But great work nonetheless!

Comment by Jordi Muñoz on February 2, 2009 at 9:28am
Hey Michael, if you want to hold altitude nicely you must use a PD control with the altitude, the output will go to another PID input that will control the climb rate (the climb rate output controls the elevator).... If you play with your simulator you will realize that is the best way, is like real autopilots... As soon you are reaching the desired altitude the derivative of the altitude error, will slowly reduce the climb rate to void overshoots... I was able to simulate and hold altitude smoothly like airliner.

The problem is that we don't have very good climb rate in ardupilot, we must use a barometer... =/

Comment by Jordi Muñoz on February 2, 2009 at 9:29am
Michael are you sending commands to x-plane through UDP to control the aircraft?

Comment by Sami Finnila on February 2, 2009 at 9:35am

Looking at the source right now and yes, all the communication to Xplane is done through a single UDP socket..

Comment by Jordi Muñoz on February 2, 2009 at 9:42am
HOOOO!!! Thanks Sami... Thats very interesting...


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service