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 data2) Connects to X-plane on localhost (same PC)3) Reads data from X-plane (lat/lon/alt/course), sending these to ArduPilot as GPS sentences4) Simulating FMA copilot stabilization on ailerons/elevator5) Reads and displays telemetry and servo positions from ArduPilot6) Sends servo positions to X-plane to control throttle and rudder7) Records fly path and sends it to Google Earth to displayHere'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 viewsNow 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.kmzYou 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.
E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • 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.

  • 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.
  • 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.
  • 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


  • 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.
  • Ben,
    that would work if you were working to bearings - similar to yacht navigation - but ArduPilot is working to fixed navigation using GPS so it would always try and compensate for the wind. Depending on wind strength the aricraft would 'crab' along the line. This could be minimised by making survey lines as close to the wind as possible - or waiting till its not windy!

  • Good points Mike,

    One way to get a more accurate line track(for photo or other work) is also to compensate for x-winds using desired track plus/minus wind corrections for a desired track made good, it should be easy to set a track away from the desired waypoint and have the aircraft blown onto track using the same theory as real aircraft nav.

  • Ben,
    this is something I have been looking at and discussing with a friend who has extensive experience of a commercial autopilot in his RC model. My concern was really XTE so that the aircraft kept to a line for aerial mapping purposes. After discussions with him I/we have come to the conclusion that best thing is to set out your waypoints well so that the aircraft is alredy close to the required bearing and line when it hits the line of interest. He recommends a minimum line length of 10x the turning radius of the aircraft and put lots of waypoints in to guide it in its approach - intermediate waypoints along the line would also be useful. My persent view is that there is probably no need to introduce line keeping into the navigation routine but that XTE and/or a XTE ealarm be introduced to the base station. Having watched Michals video I was impressed with how well the line was kept and this reassures me somewhat in my approach. What happens in the real world migh prove different and when I get my computer model up and running I will be doing more tests on this - particularly to look at wind effects.

  • Another thought after viewing the above video, is it possible to tell the aircraft to turn the long way around onto the next turnpoint.

    as a example whem the aircraft is tracking and over fly's a waypoint and has to turn left less than 80 deg's to track to the next point a 270 deg ish trun to the right would keep the aircraft over the flightplanned track for a longer time than trying to skidd around a tight turn and re intercepting track further down ?

    just a thought. 8)

  • Michael,
    If you would like a real pilots thoughts on how to get around your Climb and descent problems, drop me a line

    I fly General Aviation , Gliders and Ultralights (LSA'S) as well as model aircraft 8-)


    West Oz Australia
This reply was deleted.