3D Robotics

Simulating flight with ArduPilot

This is the first post in what I hope will be a mini-series on doing hardware-in-the-loop simulations with ArduPilot. A simulation is something you do to test your autopilot on the ground, where you won't get in trouble. It's an absolutely necessary thing when you're writing your own code or fiddling with ours and constructing a simulator is part of basic autopilot development. It's called "hardware-in-the-loop" because you're using your real autopilot hardware, but feeding it simulated sensor or GPS data to make it think that it's in the air and moving around. Then you watch its reactions and see if it's doing what it's supposed to. Eventually this series will take you to a full closed-loop simulation, where the simulator talks to the autopilot and the autopilot talks back to the simulator, totally replicating the interaction between plane and space. But for now, we'll start with the basics: simulated GPS in and telemetry out. To do this, you'll need a computer with two USB ports (or two computers, as I've shown above) and two FTDI cables (or other USB-to-serial converters). Although it's not totally necessary, you'll also probably want a breadboard to do all the wiring on. [UPDATE: See the comments below. You can download a utility that will turn one physical port into multiple virtual ports. That way you can use a single FTDI cable, and plug it straight into ArduPilot as usual. If you're using this method, ignore all the stuff below about the breadboard and wiring.] You'll be running two programs on the computer(s): a GPS simulator and a terminal to see incoming serial data. I like the FlyWithCE GPS simulator and for a terminal, I use Realterm. Plug in your FTDI cables one at a time. If you go into your Device Manager (Control Panel/System) after you plug each one in, you'll see which ports they're assigned to. Now set up the GPS simulation software and the terminal so each is using a different one of those ports, and set the baud rate to 4800 for each. Now we're going to connect them to ArduPilot. Set up a breadboard with header pins and plug your two FTDI cables in on each side, with one 3-pin header off to one side on its own row. Use jumper wires to connect the 3-pin header to the following ArduPilot pins on its FTDI port: GND, TXO and RXI. Depending on which FTDI cable you're using you can figure out which pins are which this way: --If you're using the Adafruit cable, the black wire is ground, the yellow wire is TXO and the orange wire is RXI. --If you're using the Sparkfun breakout board, the pins are labeled. Now wire up the breadboard as follows: The "GPS" cable (the one that's associated with the GPS simulator) should have its RXI pin connected to ArduPilot's RXI pin. The "telemetry" cable (the one that's associated with the terminal program) should have its TXO pin connected to the ArduPilot's TXO pin. All the grounds should be connected together. It looks like this when you're done:

Needless to say, you should disconnect ArduPilot's GPS module, but otherwise keep the autopilot in the plane wired up to the servos and Rx as usual. Power it on. In your GPS simulator program, enter a starting location lat/lon (it doesn't matter which if you're just doing RTL, although you might want to keep it in your hemisphere!) and pick move or circle and some speed at which you want it to fake the aircraft's motion. In your terminal program, there's nothing to do as long as you've got the right port and speed selected. Now press "Start" in the GPS sim. It will start spitting NMEA sentences down the FTDI cable, which ArduPilot will think are coming from its GPS module. Meanwhile ArduPilot will start sending data (wherever there's a Serial.println command in the code) out its TXO pin to the other FTDI cable, which should show up in the terminal program. The autopilot should also respond the way you would expect if this was real GPS data, including moving the rudder to steer back to its starting position when you toggle it on with your RC transmitter. Of course it won't really steer home because A) it's on the ground and B) we haven't enabled a feedback loop yet. But you can at least test program logic and see what the autopilot is thinking as it gets moving GPS data. In the next post, we'll use a flight simulator program instead of the GPS simulator utility, and we'll discover what a "human in the loop" simulation is!
E-mail me when people leave their comments –

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

Join diydrones


  • Chris,
    Looking forward to your next post in this---
    "This is the first post in what I hope will be a mini-series on doing hardware-in-the-loop simulations with ArduPilot."
    I really appreciate how you take the tiime to clearly explain things for us beginners!
  • I have succeed test simulation the ardupilot with Michal B codeusing X-plane and his ArduSim. Now I love to simulation test with the original code with X-plane like jordi done. Hope I can learn some.
  • 3D Robotics
    What do you mean by "original code"?
  • Hello Chris, any update for this sim that using original code?
  • Simulation half-way done:

    I fly in X-plane, which sends data to simulator. This sends GPS to ArduPilot, and those sends telemetry back to simulator, which sends path to GEarth. Uff, that sounds complicated...
    So data go through ArduPilot already. Now I'm ahead to send commands back to X-plane from AP.
  • Michal,
    look forward to the blog and hopefully instructions. Chris and Jordi have done a great job and it seems the lauch of the boards has really inspired a few people. In particular you seem to be contributing a lot - please keep it up - it is appreciated!
  • I'm doing now cheap simulation with X-plane and Google Earth, connecting to ArduPilot hardware. ArduPilot gets synthetic GPS data from X-plane over serial (same as in real flight), and AP sends back servo positions over serial to X-plane. In middle sits a simple PC application which manages signals here and there, and suits also as a base station.
    This is very similar to what Jordi did (the "complicated" simulation), but I don't use any additional hardware for reading servo out of AP, just a single FTDI cable. It won't test all aspects (mux switch in AP), but navigation algorithm should be tested just fine.
    When I have successful flights, I'll make a blog post.
  • I know about your closed loop system you use for simulating and you are right it is complicated for the average user. That's why I'm looking at simple options myself.

    One thought was to read Pulsein from Ardupilot into a Diecimila/mini/barebones or similar and send analogout to a joystick's potentiometers this can then control a simulator program as if the joystick pots were doing the job, not that simple I discovered, it worked! but not perfect erratic input into the sim. Maybe I require some filters in the code? I can explain a bit more if any one is interested. Or please tell me if I’m wasting my time.
  • 3D Robotics
    Gagarien, we've also done a full closed loop simulation as you describe. It's here, but too complicated for the average user right now. We're working on making it easier (and cheaper).
  • No problem Michal B. I only got started with physical computing over a year ago – not my field and that’s not even programming. What you guy’s are doing makes my head spin! So keep up the good work.

    I’m still looking at a way to do full closed loop simulation some how get Ardupilot to send serial data to say Flightgear and simulate throttle and rudder control as per waypoints in Ardupilot. Then use the autopilot function in the simulator program to do stabilizing (wing leveler and pitch hold) this of course with the simulator sending NMEA strings via serial out.

    Maybe I’m too hasty, as Chris mentioned “later in the series” but thought I can play around and be helpful to Ardupilot project.
This reply was deleted.