MAVProxy 1.6.1 Released

MAVProxy 1.6.1 is now out!

You can get it via pip install MAVProxy --upgrade in Linux or for the Windows installer.

Major changes include:
-New “horizon” module for a graphical HUD
-New “magical” module for easy compass calibration
-Performance enhancements for MAVExplorer under Windows
-Extra graphs in MAVExplorer
-Support of joystick buttons for RC controls
-Upgrade to OpenCV3 for all map displays


Thanks Stephen!
Will have to try it out!

With the joystick button for RC Controls, does that mean that a standard USB PC joystick can be used to control the aircraft over Mavproxy now? Would it be possible to extend this to a BT or wifi joystick controller for RC remoteless flying, and does this support RFD900x PPM out?

It would be nice to be able to use a Pi/Odroid with wifi/BT on the ground connected to a RFD900x to control an aircraft with a PC/PS4 joystick in stabilize or guided mode. The RC TX could then stay at home (old clunky taranis!)

Also for the OBC are you looking at integrating a way for the coordinates of dynamic no-fly- zones to be updated to the PXH via mavproxy and telemetry in flight? I realise that we don’t yet know the specifics of how the organizers will tell us where the DNFZs are, but I was hoping to maybe use the avoidance already integrated into the APM ADS-B module as a way to integrate it into aircraft navigation (they also mention ADS-B in the 2018 rules). Obviously this will need to incorporate some predictive avoidance as to not get stuck on the wrong side of a DNFZ/NFZ/geofence and run out of range or time, and prioritize WP1-2, RTL/base, remote landing site etc in flight. What do you think?

Any joystick still needs a template file to tell MAVProxy which axes/buttons are mapped to which RC Channel. There’s a full list of ready-to-go joysticks at

If you want to add a new joystick, take a look at the existing template files at

If it doesn’t appear as a joystick device to the OS, it would need it’s own module. Definitely do-able.

The APM source code can do the avoidance directly -

Our initial idea (noting that it’s early days) is to modify this code to be OBC-compliant. It could change depending on how development goes in the next 12 months :slight_smile:

Thanks for all the links Stephen, I’ll go through them.

Predictive avoidance is probably a different subject and might be a bit to early to develop until we get more specifics of the requirements from the OBC. Hopefully this can be fully incorporated into the mainstream APM code with some options for configuration purposes (like the advanced fail safe code). I think the autonomy type 2 is the biggest additional challenge atm, apart from the range/VTOL component.