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

Robin Hilliard November 6, 2013 at 4:49am
Hi Koen,

I got some updated settings from Section 6.5.2 of http://mapserver.flightgear.org/getstart/:
```
fgfs --native-fdm=socket,in,60,,5503,udp --fdm=null
```
worked for me, where 5503 was the default --fgout argument passed to runsim.py by sim_arduplane.sh. It seems that MavProxy is no longer responsible for forwarding info to flightgear, it comes directly from the runsim.py script.

Cheers,
Robin
Andre S March 29, 2012 at 10:51am

sent you a friend request. If you accept we can send PM like email (or I can send you an email address).
Andre S March 29, 2012 at 10:11am

Hi,

Sorry again for the late reply. Didn't notice your post. What exactly are the errors you get? I'll check out the current repo versions at the weelend.

Cheers, Andre
Andre S March 1, 2012 at 12:01pm

Hi Aaron,

sorry, just saw your questions. The value for the "--master" parameter depends on your (windows, mac, linux). It's the serial port your APM is connected to. Your're right, that was sort of missing from the instructions. So if you live in the windows world that may be COM0 or COM1 or something.. Hope this answers (both) of your questions... Andre
Andre S November 11, 2011 at 1:15am

Alan, if I find the time I'll give it a try but in the meanwhile if you have concrete questions then PM me, just sent a friend request. Cheers, Andre
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

of 3

This reply was deleted.