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!

Views: 7458

Comment by Michal B on January 26, 2009 at 3:53am
Perfect, I'm looking forward to simulate flying.

I'd just propose alternative solution for those who don't have two FTDI cables (like me). This is sharing serial port on PC, so that we can simulate GPS and read data on single serial cable.
This means using same serial port in 2 applications. I found this tool which allows that. But it is too expensive for what it does, so I hope to find free alternative until my trial ends.
Comment by Reto on January 26, 2009 at 6:20am
There's a practical serial emulator perfect for splitting one physical COM port to as many as 8 virtual ports which are all accessible simultaneously by as many different applications. It is FREEWARE !
check it out, it called "Free Virtual Serial Ports Emulator" and produced by
Comment by Michal B on January 26, 2009 at 7:15am
Why using wires? I simply plug normal FTDI connector to ArduPilot, same connection as used for sending program to the board.

Reto: thanks for link to freeware serial splitter!

3D Robotics
Comment by Chris Anderson on January 26, 2009 at 7:23am
D'oh! Of course you're right. Sorry--too early in the morning and not enough coffee. I'll delete my comment so as not to confuse people ;-)
Comment by Reto on January 26, 2009 at 5:41pm
By the way, experimenting for the first time with GPSfeed+ (freeware GPS emulation), serial splitter, Python (with serial library) and Google Map makes fun! My yellow pushpin circles around my home at 1200m altitude with the viewport following it. and all that in the middle of the night, noiseless !!!
Comment by Michal B on January 27, 2009 at 4:19am
Reto: how do you make the pushpin moving in Google Earth?
Comment by Reto on January 27, 2009 at 8:37am
Hi Michal. Basically, the NMEA data is parsed by a Python script into a KML file (I called it gps.kml). this file contains basic placemark/point information for the latest read NMEA location data.
In Google Earth, another KML file is loaded (I called it gps_link.kml) which contains info for dynamically establishing a network link to gps.kml file. The network link is set up for an actualization every 1 second.
so every second, a new NEMA sentence is parsed to gps.kml and read by Google Earth through its gps_link.kml.
Actually, I added some fancy features by multiplying this basic concept to 2 more kml file couples:
- aerial path for tracking the plane in the air
- trace of the path on the ground
Those traces need to concatenate the subsequent XYZ coordinates into a single string. such format is not very efficient for reading/writing, but the KML files grow not to fast with the little amount of data added with each new position!
I just finished preparing a nice Piper Cub icon (view from behind sightly above) with transparent background (PNG format). It is not as smooth as a flight sim, but it does the job.

by the way, I based my NMEAparser/KML builder on a Python script by Jaroslaw Zachwieja (under GNU license).
Hope this helps.

Comment by Michal B on January 27, 2009 at 12:00pm
Very nice. I can just add that after little exploration, I found this KML tutorial which explains technical details.
Comment by Reto on January 27, 2009 at 2:16pm
Even if it is not the main goal of this thread, I may add here a backview of the Sig Rascal 110'' span. The plane selection window of open source FlightGear lets you rotate the chosen planes in 3D, making it easy for a fast screenshot in a maximized window. All left to do is to open that shot in a bitmap editor and saving it with the backround blue as transparent background to have a new icon.
We could even let Python load different views of the plane in the KML files for the different angles of view. Well, I just thought the plane icon PNG file can also be transformed to a shadow projected on the ground. I shall try that out now (ArduPilot and GPS still not arrived...)
Comment by Michal B on January 28, 2009 at 8:11am
I tried to add shadow:

I simply made black color overlay over plane in Photoshop. Then shadow icon is drawn with some opacity.


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

Join DIY Drones


Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service