Software

Drone

The drone runs the official image from Emlid, which runs Raspbian. On top of Raspbian, you will usually run one or more of the following software:

  • ArduPilot: Absolutely necessary, as it provides all to logic for flying. Sometimes referred to as APM, but that is just a popular flight controller running ArduPilot. The software project ArduPilot is split in some parts, of which we only use Copter (sometimes referred to as ArduCopter, or APM:Copter). Backed by DroneCode.
  • MAVProxy: A popular ground station, but in a drone it will be used primarily for proxying.
  • DroneControl: A small web application developed by Evert, so you can more easily start/stop ArduPilot and shutdown the Raspberry Pi. Source here: https://github.com/evertheylen/DroneControl

Ground

On the ground you may run the following software:

  • MAVProxy: Both as a proxy, or a GCS. It looks promising as a GCS but has a steeper learning curve.
  • QGroundControl: A decent GCS, works in all major OS’s (including Android, but not recommended). More info in `their site<http://qgroundcontrol.com/>`_.
  • Tower: A very stable GCS, and the de facto standard for Android. Get it here (you’ll also need 3DR Services)

There are a lot of other GCS’s, but these are tested with our drone (MAVProxy not so much, but their proxy functionality is solid). More GCS’s can be found here.

Communication

The holy grail of open-source drone software is the MAVLink protocol. However, some flight stacks (like PX4) speak a different dialect, so watch out for incompatibilities with MAVLink-based drones. MAVLink is binary and can be sent over special telemetry modules, but we just use WiFi, usually encapsulated in UDP.

Proxying

As suggested above, the king of proxying in the drone world is MAVProxy. The proxy is bidirectional. I won’t provide instructions for using it as a full GCS, only for using it as a proxy. Let’s say Arducopter is running (locally) at port 14550 (as is usual when you want to proxy), and you would like to use two Ground Control Stations, one at 192.168.1.2:14550, and another at 192.168.1.3:14550. The corresponding MAVProxy command would be:

mavproxy.py --master localhost:14550 --out 192.168.1.2:14550 --out 192.168.1.3:14550

Keep this process running or all GCS will lose control of the drone!

Alternatively, you can use the output command in the MAVProxy shell to add or remove outputs:

MAV> output list
0 outputs

MAV> output add 192.168.1.2:14550
Adding output 192.168.1.2:14550

MAV> output add 192.168.1.3:14550
Adding output 192.168.1.3:14550

MAV> output list
2 outputs
0: 192.168.1.2:14550
1: 192.168.1.3:14550

MAV> output remove 0
Removing output 192.168.1.2:14550

MAV> output list
1 outputs
0: 192.168.1.3:14550

MAV>

Of course, you can also do the proxying on your own laptop, rather then on the Raspberry Pi itself. In that case the master may be an external IP address, but the outputs may be local.

NOTE: The DroneControl program does not use MAVProxy.

Programming

The usual way of programming a drone would be to write a program that sends MAVLink commands to the drone, while the code runs on another PC. However, with the Raspberry Pi as our main flight controller, we can run that program on the drone itself, and theoretically achieve a fully autonomous drone (of course, not recommended for safety).

Manually crafting and sending MAVLink packets is rather tedious. If you’re programming in Python, you’re in luck: 3DR created DroneKit. Sadly, it’s Python 2 only. (Originally Dronekit spanned much more than the Python component but the other parts (like the cloud part) never gained much traction).

It is important to note that a program written with dronekit acts as a full-blown MAVLink receiver/transmitter. To run your program while also being able to use a GCS (highly recommended), using MAVProxy is essential.

Tip: The combo Raspberry Pi + Navio can be powered in three ways:

  • Through the power module from the battery
  • Through the servo rail (not used in our drone)
  • Through the Raspberry Pi’s power

If you use the last way of powering it (there should be a specific charger for it, since it uses more than most smartphone chargers can provide), you don’t have to use any batteries to develop on the drone. Everything will work (including RC and GPS etc), but there won’t be power going to the ESC’s.

Maintaining

While I am a fan of bleeding-edge software, it may mean your drone falls out of the sky. Therefore, only install updates to flight-critical software if it’s encouraged by Emlid. After major updates, you should recalibrate the drone.