I found the instructions for setting up the Simulator a bit sketchy.  

I got it working on my Dell Latitude D830 laptop with Windows 7 Pro 64bit. I'm using X-Plain 9.21rc2,  the AruduPilotMega Planner 0.5 by Michael Oborne, ArguPilot Mega with IMU shield and a  Spektrum 8 receiver / transmitter.

I was not sure how all this fit together but I think I understand it now. Here is how I understand it now.

  1. The Radio communicates with your receiver.
  2. Your receiver talks PPM to the APM inputs.
  3. The APM, with a few special changes in APM_config.h, is told to send X-Plane data 
    USB port on the IMU shield.
  4. Using the FTDI serial driver the ArduPilotMega Planner connects to the APM and opens
    the network port 49005 on localhost IP ( for X-Plane to talk to.
  5. X-Plane, with a few settings, sees the data on the port and acts accordingly.

My transmitter is programmed for a simple four servo plain no mixing.

The switches on my IMU, from left to right are  UP, UP, UP Down, when you are facing the switch.

This turns off the IMU mixing. 

In the ArduPilotMega Planner, I set my comm port and check the Reverse box for Roll, Pitch and 


For a time I could had trouble getting all the controls to register.  After checking and rechecking my

connections I got it to work find. 

Views: 1682

Reply to This

Replies to This Discussion

Cool, Try the RC planes in Xplane. They should match the default PID settings a little better.
I'll update the graphic this weekend. I'm still working on simulation documentation with much more to come.
I'm on the edge of getting HIL working. Right now I'm just trying to get it to Fly manually. The biggest issue is the timing between FlightGear (FG) and the output of the APM. It is easy to over run FG's input and then the controls become unresponsive.

I'm finding FlightGear is easier to work with the X-Plain. To bad there is not an API interface to RealFlight.

The biggest issue seems to be that APM overruns the input of FG and causes it to be very sluggish. I have found turning off as much of the display features as I can helps increase the frame rate and gets working just fast enough if I can get it over 40fps.

Is there a way to slow down the updates coming from APM?

Also FG uses a IP interface. Is there a way to change the IP used by the Simulator? I could then run FG on one system and APM and the simulator on another.
I still have not yet got a HIL simulator working all the way. I'm beginning to learn all the issues. I have been able to fly both the X-plane and FlightGear simulator through the APM but I have not seen the GPS tracking data return back through to the Ground Station.

After creating cables for all the serial ports and connecting things like the GPS emulator to the APM it came to me; What if I used a second APM to encode the flight APM's PPM output and send serial GPS data from the simulator to the GPS port. This would fix a couple of issues that bother me. 1) You are not flying the "real" code when you run a HIL now and 2) it would embodiment the testing code.

The code should be simple enough. The APM code is already reading PPM and translating it into joystick code for the simulator. Reading the NEMA code and formating it as GPS code for the APM should be simple too.

I have only one issue. I've looked for days and even studied the PERL code that talks to the simulators. I'm still confused about how best to that interface. Because there is no network, serial would be the best way out of the hardware so a utility to read that and send to the simulator would be needed.

Does anyone know of "GOOD" example of code to interface with either X-Plane or FlightGear?
The second APM you describe wouldn't be sufficient because more than PPM and GPS data is exchanged over the HIl interface -- with the existing HIL implementation, attitude (roll/pitch/yaw) and airspeed data are also exchanged. However, it is possible to create a piece of hardware to replace the shield which emulates the behavior of the accelerometer, gyro, pressure, and other sensors on the shield based on input from the computer simulation. I have a design that uses one ATMega48 to translate the PPM signals and another ATMega48 to emulate the ADC and BMP085, but it's non-Arduino code and the connections have to be breadboarded. If you or someone else is interested in pursuing this, I'd be interested in sharing the code.

Michael Obourne's APM Planner has pretty good example code for interfacing with the existing APM HIL protocol and X-Plane (and FlightGear as I understand, but I've never used that). I have very good success with an older version of his planner along with X-Plane.
I didn't think of the other signals. I have a Arduino Mega and I was thinking of using it instead of another APM. It doesn't really need the PPM buffering. But the three pin row is nice.

I see how roll/pitch/yaw would be needed. I haven't looked closely at these devides. I do have the spec sheets. I'm guessing they are in degrees +- and may not require much translation.

The air speed would not be needed. Not all APM user have added air speed to their IMUs. GPS speed is substituted. I could use an analog output from a Arduino Mega as an air speed output.

Other outputs could be generated and feed to the APM also. Thinks like battery/fuel level, amps/volts, heading, air temp, engine RPM and more be emulated by the simulator or external and feed to the APM. (dream moment)

Looking at Michael code it does look good while lacking some documentation. It seems to be the SIM interface that is causing most of the problems. I'll start with that and then work on the hardware. I'm still thinking a second APM with a few selected jumpers to feed the flight APM's inputs would work nicely.

Would sell a few more APM's too.
Update: I have successfully installed C# express and checked and compiled Michael Obourne's APM Planner code. Michael, if you reading, I'll have a few updates for you in a while. (I love Open Source)
The sensors you'd want to emulate on the second board include:
- ADC (high-speed SPI interface; handles gyros, accelerometers, and airspeed sensor)
* PH2: Clock
* PC4: nCS
* PH1: Data in
* PC3: Busy (pin is currently optional)
* PH0: Data out
- GPS (UART interface)
* PD2: GPS Tx (APM Rx)
* PD3: GPS Rx (APM Tx)
- BMP085 pressure+temp sensor & magnetometer (I2C/TWI interface)
* PD1: SDA
* PD0: SCL
* PC7: EOC (pin is currently optional)

I couldn't get a 20 MHz AVR to respond quickly enough to the SPI request via the proper method, so I just dumped the message I anticipated the APM to request as soon as nCS went low (via attachment to INT0). Let me know if you end up pursuing this hardware-only HIL interface as I'm interested in getting one working as well.

I don't think there should be any problems with the existing software HIL; what part of your [nicely accurate] diagram are you calling the "SIM interface"? The USB/Serial, the APM Planner, the Network IP, or the flight sim itself?

I've made more progress but I still can't fly a mission.

I was having big issues with X-Plane getting a high frame rate. I recommend you display Frame Rate on the screen so you can keep track of this. (See my settings pic.) The screen rate needs to be higher then the UPD rate feeding X-Plane for good results. I fixed this issue by running X-Plane on a different computer then the Flight Planner / ArdupilotSim.  To make this work, I had to program the ArdupilotSim program to connect to X-Plane at a different IP then  I added two new text fields for Simulater IP and Port.


This IP and port send the control data to X-Plane ( I set the IP address and port in X-Plane to send it's data back to the ArdupilotSim program ( port 49005).

With my connection to X-Plane working. I added these lines to APM_Config.h, compiled and uploaded the code to my APM.

Using APM PLanner 0.4.12 by Michael Obone, I added a few way points and started flying.  Here are my waypoints.


#define WP_RADIUS 30 // What is the minimum distance to reach a waypoint?
#define LOITER_RADIUS 45     // How close to Loiter?
#define HOLD_CURRENT_ALT 0    // 1 = hold the current altitude, 0 = use the defined altitude to for RTL
#define ALT_TO_HOLD 600

float mission[][5] = {


I found my Mode switch has three modes, Manual, FBW-B and Auto. In manual I can fly all day. In FBW-B mode the plane doesn't fly to the next waypoint and I can only control the rutter. In Auto mode I can control everything but the throttle.What am I missing?

Here is my X-Plan settings.

The APM code I'm using is the code is the latest "Release".



Mark, do you want me to add the remote ip and port options to the planner?

Sure.  Or I can send my my code.  I added the needed code to save these values as well.

You take Diffs?

send me something and ill see what i can do

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service