Recently I attended a local event related to Drones and Unmanned Aerial Vehicles (UAV) here in Galicia.

The event was a nice place to meet some interesting projects and people in the community although, on the low-level technical side, I missed some local company/individual using Open Source flight stacks.

This blog entry contains my notes to build and test an Open Source UAV autopilot based on Ardupilot and Pixhawk, together with the simulation setup needed to explore autonomous missions, flight logs, control commands and open development.

The requirements

Ideally our flight software platform should fullfill the following minimum requirements:

  • Top-Down Open Source. The platform should be open from a full-stack perspective (boards, design, hardware controller, operating systems, protocols, interfaces, etc)
  • Stable, responsive and reliable flight code. The platform should be battle-tested and a joy to play in manual, guided or automatic modes.
  • Ground Control Station (GCS) communication support. GCS should be available in different client environments (GNU/Linux, Microsoft Windows, etc). It should ship with an usable and easy to operate built-in interface.
  • High-level commands support. Good and powerful control abstractions and programming primitives should be available to bring in more complex use cases, new flight features, etc.
  • Telemetry. Measurements and monitoring support should be available in order to generate proper flight logs on real time.
  • Simulator available. Some kind of simulation based on hardware and/or software would be used to avoid costs related to crashes, tests, training, mission planning, etc.
  • Companion computer. A companion computer should be available to offload non critical flight computing and leverage existing hardware domain extensions in a 'Plug&Play' way.

The Open Source flight platform

With the previous requirements in mind I found the Ardupilot and Pixhawk projects a good fit. The fixed wing aircraft looks also a good building target.

In detail, the main technical blocks and projects are:

From a logical perspective we are looking for one layered architecture with well-defined responsibilities. It should be also flexible and modular. In order to ease the maintenance, development and extension we should expect a logical architecture similar to the following one.

As described in the great 'Small Unmanned Aircraft: Theory and Practice' resource related to this architecture, the path planner produces straight-line or Dubins paths. The path manager switches between orbit following and straight-line path following to maneuver along the waypoints paths. The path-following block produces commands to the low-level autopilot, which controls the airframe. Each of the blocks relies on estimates of the states produced by filtering the onboard sensors.

In the case of our platform the following picture shows how all pieces fit together.

Building the flight code

It is possible building Ardupilot for different target hardware on the supported development environments (GNU/Linux, Microsoft Windows and Apple Mac OSX) and vehicles (plane, copter, rover...).

We are interested to build the Pixhawk family (Pixhawk, Pixhawk2, PixRacer or the original PX4) using the ArduPlane specific flight code. The technical instructions and step-by-step commands are available here.

I got successful builds under Ubuntu 16.04 LTS (Xenial Xerus) with target hardware Pixhawk (make px4-v2) and Pixhawk2 (make px4-v3).

Building the simulator

In order to run/test experimental code safely a simulator is needed. The project supports several simulators (Gazebo, Replay, etc). We will go with the Software In The Loop (SITL) simulator.

The SITL simulator does not require a flight controller, and all vehicles are supported. The SITL simulator allow us to run our vehicles without any hardware. This simulator is also used by the autotester.

The SITL simulator is a build of the autopilot code using an ordinary C++ compiler, giving you a native executable that allows you to test the behaviour of the code without hardware. When running in SITL the sensor data comes from a flight dynamics model in a flight simulator.

The required dependencies, technical instructions and step-by-step commands to build the simulator are available here.

Running a mission in the simulator

In order to test the SITL build we can load and run a simple flight mission. CMAC-toff-loop.txt will do the work. This file contains a mission which flies in a loop. It is good enough to test the simulator.

With the SITL simulator in place you can start the simulation with the following command.

sim_vehicle.py --console --map --aircraft test

From within MAVProxy type:

  • wp load ../Tools/autotest/ArduPlane-Missions/CMAC-toff-loop.txt
  • arm throttle
  • mode auto

The virtual aircraft will takeoff and follow the planned waypoints in a loop.

Companion computer

A companion computer can be used to interface with Ardupilot on a flight controller using the MAVLink protocol. This way the companion computer gets access to the autopilot data to provide additional functionality/integration if needed. A companion computer can be also used to offboard control.

In our case we are interested in some kind of affordable and versatile computer with good GNU/Linux support. The Raspberry PI 3 Model B (RPI) will do the work. You can find the technical documentation to interface, configure and set up the RPI over a serial connection here.

On the hardware side you only need to connect the pixhawk’s TELEM2 port to the RPI’s Ground, TX and RX pins.

On the software side you can use one of the existing APSync images, or you can install a Raspbian together with Pymavlink, MAVProxy, DroneKit, ROS, etc.

Developer API and ROS

On the development side we are interested on high level abstractions in order to interface with Ardupilot.

We will use the Robot Operating System (ROS) framework here together with its MAVROS package, a MAVLink extendable communication node for ROS with proxy for Ground Control Stations.

In order to test ROS we can use SITL as deployed previously. The technical configuration and step-by-step commands are available here.

Launching ROS is straightforward. With SITL running you only need to run the following command:

roslaunch apm.launch

You should see something similar to the following picture.

In this point you can implement some code snippet to test MAVROS or you can use its utility commands.

In order to test the installation quickly we can run two simple utility commands related to waypoints and flight mode.

The mavwp command line tool can be used to handle waypoints (show, pull, goto, etc).

'rosrun mavros mavwp show' displays the following mission's waypoints.

On the other hand we will use the mavsys command line tool to switch the autopilot mode.

'rosrun mavsys mode -c loiter' will switch to LOITER mode.

In LOITER mode the plane will circle around the point where you started the loiter, holding altitude at the altitude that you entered loiter in.

There is also another way to 'program' the autopilot. It is possible hacking the MAVProxy tool to support a TCP/UDP server. This way it is possible redirecting the MAVProxy's console over a socket. The code is available here.

To bind a TCP/UDP server on port 5234 over all interfaces you can run the following commands:

mavproxy.py --[tcp|udp]=0.0.0.0:5234

With this hack in place you can pipe your input/output commands over the network for this minimalist ground station. You might also be interested in this resource related to plane SITL/MAVProxy.

Wrapping Up

From a software-side perspective, I found a well documented and stable Open Source flight stack. In this first contact I kept the focus of my tests on the identification, building, simulation and architecture of the different parts of the software stack.

The level of maturity of the projects looks good enough to grow new use cases, features and customizations on top of them. The many interfaces available and high level abstractions are a great addition to inspect, monitor and drive the vehicle.

The possibility to have a companion computer also adds freedom to support more complex and powerful computations running in parallel and isolated from the critical code running on the real-time flight computer. This configuration raises the reliability of the whole solution.

Comments

comments powered by Disqus

Recent Entries