APM hardware-in-the-loop simulation on non-windows system (mac, linux)

Hi guys,

This is not really a post about something new but rather a summary of steps others did before me and a little help to my personal memory (already forgot once how it works). The post is referring to ArduPlane but I don't see what would be different for ArduCopter. Would also like to say thanks to the developers here :-)

The problem: you want to get a HIL simulation running without windows (i.e., on a Mac or linux system) using the latest APM git repo code and QGroundcontrol as the GCS.

Outline of one possible solution:

Install dependencies: ArduPlane (git version), QGroundcontrol 0.9.0, FlightGear V2.4.0, python 2.7, pyserial-2.5, MAVProxy (git version), pymavlink (git version), arduino-0022 and cmake 2.8.6 for building and uploading APM code straight from console
Copy MAVLink.xml to FlighGear protocol directory (for Mac OS: /Applications/FlightGear.app/Contents/Resources/data/Protocol/ )
Start MAVProxy: python2.7 mavproxy.py --master=/dev/tty.usbserial-A600dLKS --fgout=localhost:5010 --fgin=localhost:5000 --out=localhost:14550
Start FlighGear with parameters: --generic=socket,out,40,localhost,5000,udp,MAVLink --generic=socket,in,45,localhost,5010,udp,MAVLink
Start QGroundcontrol
Enjoy :)

More detailed info on dependencies and configuration:

A) APM:

git clone https://code.google.com/p/ardupilot-mega/
cd ardupilot-mega/ArduPlane
Modify APM_Config.h: "#define HIL_MODE HIL_MODE_ATTITUDE"
"#define HIL_PORT 0"
cd ..
Follow instructions in README.txt for building and uploading code (essentially, assuming arduino1280: mkdir build && cd build && cmake .. && make ArduPlane-upload )

B) MAVProxy and pymavlink: (note: should be in the same directory(?)):

mkdir APMHIL
git clone git://git.samba.org/tridge/UAV/pymavlink.git
git clone git://git.samba.org/tridge/UAV/MAVProxy.git

C) Setting stuff up (modify paths according to your installation paths):

export PYTHONPATH=/Library/Frameworks/Python.framework/Versions/2.7:/Users/andre/pyserial/lib/python2.7/site-packages
export PATH=/Library/Frameworks/Python.framework/Versions/2.7/bin:$PATH

D) Trouble shooting:

For my EasyStar I had to fix rudder control to 0 and invert the direction of elevator control. This is easily done by the two modifications inside mavproxy.py:

status.rc_elevator = (-1.0) * scale_rc(m.servo2_raw, -1.0, 1.0, param='RC2')
status.rc_rudder = 0.0;

Also: every time one starts FlightGear one needs to start the engine manually by pressing 'S', which is annoying :)

@Andre, it's not a future project/great idea, he did it already!

The FDM issues for SITL simulation are no different to HITL simulation, and there is already an arducopter FDM integrated with the ardu* code (which is why the HIL stuff works). Flightgear has FDMs of many fixed wing planes including a "SIG Rascal" RC model, which has been incorporated into different ardupilot HITL setups already. I guess you just configure your autopilot (PID gains etc) for the simulated vehicle, in the same way you would do it for a physical one (i.e. hope it works out of the box then adjust as required).

The two tricks I needed to see were in autotest/util.py:

build_SIL() starting line 45; "make -f ../libraries/Desktop/Makefile.desktop clean hil", which is where the "process running on my desktop" is built.
start_SIL() starting line 51, which uses pexpect to run the resulting elf in valgrind. I guess valgrind produces some interesting logs when things go wrong, but I might not need it for my application.

The other interesting thing for me more generally was autotest/arducopter.py, which demonstrates "human friendly semantics" as python functions that wrap lower-level MavLink exchanges (via MavProxy and pexpect). It's neat and very different to what I'm used to in paparazzi, where the flight plan loaded onto the autopilot has a lot more logic in it (variables, conditionals, loops, etc), and that sort of "packing" (low level functions into high level commands) occurs within the autopilot's own flight plan, not external to it. Python is so easy on the eye, I like it :)

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

Join diydrones

Comments

Alan November 9, 2011 at 3:01pm

Could you make a video of you process here? It might help other users linke me too
Chris Gough November 6, 2011 at 3:31pm
@Andre, it's not a future project/great idea, he did it already!

The FDM issues for SITL simulation are no different to HITL simulation, and there is already an arducopter FDM integrated with the ardu* code (which is why the HIL stuff works). Flightgear has FDMs of many fixed wing planes including a "SIG Rascal" RC model, which has been incorporated into different ardupilot HITL setups already. I guess you just configure your autopilot (PID gains etc) for the simulated vehicle, in the same way you would do it for a physical one (i.e. hope it works out of the box then adjust as required).

The two tricks I needed to see were in autotest/util.py:
- build_SIL() starting line 45; "make -f ../libraries/Desktop/Makefile.desktop clean hil", which is where the "process running on my desktop" is built.
- start_SIL() starting line 51, which uses pexpect to run the resulting elf in valgrind. I guess valgrind produces some interesting logs when things go wrong, but I might not need it for my application.
The other interesting thing for me more generally was autotest/arducopter.py, which demonstrates "human friendly semantics" as python functions that wrap lower-level MavLink exchanges (via MavProxy and pexpect). It's neat and very different to what I'm used to in paparazzi, where the flight plan loaded onto the autopilot has a lot more logic in it (variables, conditionals, loops, etc), and that sort of "packing" (low level functions into high level commands) occurs within the autopilot's own flight plan, not external to it. Python is so easy on the eye, I like it :)
Ruben Wijnhoven November 5, 2011 at 3:29am

How do you use mono with missionplanner in ubuntu? When I do mono ardupilotmegaplanner.exe I get al kinds of exceptions but no running of MP.
Andre S November 4, 2011 at 2:54am

Andrew, great idea to do APM revision testing via software simulation. Actually, I had a similar idea a while ago but never followed up on that since I don't know enough about modeling in flight simulators (or actually, flight dynamics in general). Also, I guess, lots of testing would concern settings such as for PID controllers, which may differ significantly from airframe to airframe (or copter to copter). How do you plan to address this?

But it still sounds like a great idea. Maybe also a nice project for the winter months :)
Chris Gough November 3, 2011 at 4:04pm

Thanks Tridge, the penny dropped reading that autotest code.
Developer

Andrew Tridgell November 3, 2011 at 2:27pm

Hi Chris,

The SITL stuff for ArduCopter is now working quite well, and I now run it automatically after every APM git commit. See the Tools/autotest/ directory in the APM git tree. Right now it is testing manual and automatic flight of ArduCopter, but I hope to expand it to test ArduPlane as well, using jsbsim and some of the models from flightgear. You can see the latest output from automated test flights on http://apm.tridgell.net or just look at a kml file of the test flight in googleearth.

The test system uses mavproxy, pymavlink, pexpect and some custom python scripts to hold it all together. If you have a look at Tools/autotest/arducopter.py you can see how the scripting of the flight of the quadcopter works.

Cheers, Tridge
Chris Gough November 3, 2011 at 6:35am

woah! just accidentally deleted my own post while trying to banish a floating advertisement that obviously wasn't displaying correctly in iceweasel. My post said "how would you do this differently for software in the loop", referencing step 3 above, and came between Mike's two comments above.

Mike, my goal is to test/play-with different ground segment configurations (flightgear for synthetic vision, various other components), eventually including a flightgear "multiplayer server" and a collection of HITL and SITL simulations occupying the same virtual airspace. Specifically including ardu* and paparazzi systems. (HITL and SITL are quite strait-forward in paparazzi, with or without flightgear visualisation). Why? as a backdrop for testing my ideas about interoperability between different MAV systems.

So, I'm not so interested in simulating the autopilot hardware with something like emulare, I just want as process on my workstation running the APM code, just like HITL but without the cables and stuff cluttering up my desk. And cheaper, because I will run tens of even hundreds of them them at once (perhaps).
Moderator

Michael Pursifull November 3, 2011 at 5:43am

Well, I suppose you could start with something like http://emulare.sourceforge.net/

It would be interesting to see how far you could get... it is not a trivial project, but it would be interesting. I'm not quite sure what the goal is, but it is interesting.

emulare - Arduino Emulator

emylare - Arduino emulator
Moderator

Michael Pursifull November 3, 2011 at 5:28am

@Andrew - re mono, I must have been doing the same thinking. I still feel dirty just knowing mono was loaded, but I may have sold it short on philosophical grounds :-)
Moderator

Michael Pursifull November 3, 2011 at 5:26am

@Andre S: Or, if you are willing to give it a try, you can have an EasyStar in X-plane (with or without ailerons, or however else you want it) See http://diydrones.com/forum/topics/x-plane-arduplane-bixler-easystar... and let me know how you prefer it...

of 3

This reply was deleted.