Dear all,

DISCLAIMER: I hope I do not bend the forum rules too much by this blog post and would hate to offend the community by starting the discussion of a (at least marginally) political topic. However, since in the past also UAV regulatory developments and issues that relate to the open-source community have been discussed, and since I believe this topic is highly relevant to the diydrones community, I decided to go ahead.

Those of you who have been visiting wikipedia, google, or some of the other sites that participate in the SOPA/PIPA blackout today may have noticed that parts of the private and public web communities have decided to virtually demonstrate against these (sets?) of law proposals. I myself, being located inside Europe, don't think I can completely follow the legislative process and the actual implications of SOPA/PIPA. However, it seems obvious to me that this topic is very relevant to diydrones as a site of open information exchange. I would like to raise awareness here and ask those who actually are located in the US and can influence the vote by contacting their representatives to please inform themselves and consider (as google's picture says) to take action. Please check out:

https://www.google.com/landing/takeaction/

http://en.wikipedia.org/wiki/Sopa   (the only wikipedia page that seems to work today)

http://yro.slashdot.org/story/12/01/18/0834219/ask-slashdot-what-can-you-do-about-sopa-and-pipa

Thanks!

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:

1. 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
2. Copy MAVLink.xml to FlighGear protocol directory (for Mac OS: /Applications/FlightGear.app/Contents/Resources/data/Protocol/ )
3. Start MAVProxy: python2.7 mavproxy.py --master=/dev/tty.usbserial-A600dLKS --fgout=localhost:5010 --fgin=localhost:5000 --out=localhost:14550
4. Start FlighGear with parameters: --generic=socket,out,40,localhost,5000,udp,MAVLink --generic=socket,in,45,localhost,5010,udp,MAVLink
5. Start QGroundcontrol
6. Enjoy :)

More detailed info on dependencies and configuration:

A) APM:

1. git clone https://code.google.com/p/ardupilot-mega/
2. cd ardupilot-mega/ArduPlane
3. Modify APM_Config.h:  "#define HIL_MODE            HIL_MODE_ATTITUDE"
                                         "#define HIL_PORT            0"
4. cd ..
5. 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(?)):

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

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

1. export PYTHONPATH=/Library/Frameworks/Python.framework/Versions/2.7:/Users/andre/pyserial/lib/python2.7/site-packages
2. 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 :)

1. If somehow possible, a GCS should not rely on libraries or tools whose distribution is limited for reasons such as a) operating system or b) commercial distribution or license issues
2. A suitable GCS should be able to present the relevant data as simple as possible; rather than including the latest bells and whistles (realistic cockpit instruments, audio, etc.) the data should be presented in a comprehensible form
3. The GCS should be as platform independent as possible (i.e., not be Windows-only)