Skip to content

September 2022

ArduPilot and Docker Part 1

ap_docker|690x174

Hello friends,

A recurrent question I got is : How to use ArduPilot SITL (Software In The Loop) with Docker. For those that don’t know what Docker is, it is a container management service : a kind of Virtual Machines (VM) but for applications. This can be really useful to set up a build environment for ArduPilot or simulation with a level of reproducibility as we can manage close to everything like in all VM systems.

Docker can be used in numerous ways with ArduPilot and I will try to share some knowledge on this series of blog posts.

Public Money Public Code

PMPC_sticker_v2 CC-BY-SA 4.0 Free Software Foundation Europe |208x283

Dear Community,

ArduPilot Foundation is glad to announce that we have join the Public Money, Public Code Initiative : https://publiccode.eu/

What is this about ? As a FOSS (Free Open Source) project, we are proud to share with our community all the tools we are using on the project, bringing better transparency and a way to reuse our works. We believe that it should be the same for publicly financed software. Software paid by the citizen should still belong to the citizen and not only to a sole entity!

Wait I am a company, how does this benefit me ?

Let’s take a real example. This is obviously simplified but based on my experience as a software engineer for drone and robotics companies in France and in Europe.

Company A is applying to some European funding to do a better delivery drone.

They spend X time doing the paperwork, Y time doing the promised tasks, and get funded by Z by Europe, with Z < Y. With some arbitrary number : 10000€ paperwork, 60000€ for tasks, 50000€ funding. So it cost them 20000€ in total, which is a nice discount, and got some Intellectual Property on the tasks done so they can monetize and advertise on their product to have some competitive advantage.

But, at the same time, at least another company, Company B, applied for funding for a better delivery drone too within 3 months.

It results in both companies burning 20000€ in non competitive advantage and losing a certain amount of time doing the paperwork for funding.

European citizens just lost 100000€ tax by funding twice the same work (or closely), and got no way to reuse those works…

With public code, what would happen is that Company A will still have the same funding and Intellectual Property, but the task's result will be shared ! Therefore, Company B will be able to use it without needing a grant, or based it on Company A work. European citizens save some taxes and gain access to Company A results !

avantage1 CC-BY-SA 4.0 Free Software Foundation Europe |690x266

avantage2 CC-BY-SA 4.0 Free Software Foundation Europe |690x269

So it won’t be advantageous to get funding anymore ?

Not at all, the only true advantage they could get was Intellectual Property on the tasks done but if we take drone technologies, like in my example, this a very low term advantage as the whole industry is using the same technology and developing the same things in parallel. Moreover, by releasing its results as Open Source, Company A will gain all Open Source advantage. It can be hard for a private company to have a good community that brings them benefits, but if they are working with some project like ArduPilot or ROS, then it is easier to have feedback from the community and gain huge benefits! Sharing back the code on ArduPilot for example, will lower the maintenance on version update as ArduPilot will now handle it in its release and bring incremental improvement with the community, this will also allow better testing and make the code safer.

Are you interested in supporting the Public Money, Public Code Initiative ? You can join the movement by signing the open letter as Individual or a company : https://publiccode.eu/openletter/

|501x391

One of the strengths of ArduPilot is that we rely on the standardized MAVLink protocol for our telemetry. As our drones gain more capabilities, companion computers are often used with many separate pieces of software that need to have access to the flight controller data.

A common approach to do this is to use MAVProxy, the ArduPilot developer’s main Ground Control Station. MAVProxy relies on a module based approach that allows it to have numerous capabilities, can serve as a MAVLink message router between multiple components and implement the routing of MAVLink messages according to Mavlink routing protocol.

Routing components with MAVProxy is simple: we need a --master endpoint to connect to the autopilot and then we can setup as many output endpoints (--out) as we want.

This approach is simple to set up but has some costs. MAVProxy, is a fully featured ground control station and not a sole message router.

Using the default startup options consumes a lot of resources, and defaults to loading numerous modules. You can see those default modules at the MAVProxy prompt, (a prompt that shouldn’t exist for a simple routing feature…), by typing module list :


STABILIZE> adsb: ADS-B data support
arm: arm/disarm handling
auxopt: auxopt command handling
battery: battery commands
calibration: calibration handling
cmdlong: cmdlong handling
console: GUI console
fence: geo-fence management
ftp: ftp handling
layout: window layout handling
link: link control
log: log transfer
map: map display
misc: misc commands
mode: mode handling
output: output control
param: parameter handling
rally: rally point control
rc: rc command handling
relay: relay handling
signing: signing control
terrain: terrain handling
tuneopt: tuneopt command handling
wp: waypoint handling

How can we make this better?

Solution 1 :

Clean up MAVProxy!

First, launch MAVProxy as a deamon with --deamon that removes the interactive shell. Next, you want just routing, so the only module you need is link. This module will allow you to set as many outputs you want on launch.

Secondly, MAVProxy should be configured to stop adjusting telemetry rates... You may have noticed that MAVProxy and all Mavlink GCS, automatically request data from the Autopilot. This comes from a special routine that will regularly set the telemetry stream rates: the frequency the autopilot should send a defined group of messages. This feature is convenient for a GCS but not for your MAVLink router as it will fight against other software on the same link. For example, if you have MAVProxy connected to the Autopilot and a companion computer connected to MAVProxy, if you ask with the companion computer to have the IMU message at 50Hz, after a few seconds the IMU message will stop coming at 50Hz and revert to 4Hz as MAVProxy will have reset it.

Thankfully, MAVProxy has an option to disable this behavior, like most GCS. For MissionPlanner, it is in Planner configuration options.

Your new MAVProxy command line will be something like:


mavproxy.py --master=tcp:localhost:5762 --daemon --default-modules "link" --streamrate -1 --out 0.0.0.0:14552 --out 0.0.0.0:14553

--master for the autopilot link

--daemon for not have interactive shell

--default-modules "link" to keep only the ability to set outputs.

--streamrate -1 to disable messages control from MAVProxy

--out 0.0.0.0:14552 to set new output

Now you have a clean router for your Mavlink messages.

Solution 2:

Use another software that just do MAVLink routing : mavlink-router

This is small C-based software that mostly only does MAVLink routing. It can do the routing of Mavlink messages according to MAVLink routing protocol, do messages filtering and sniffing, and lastly it has a logger system.

Compared to MAVProxy it is very lightweight both in size and CPU usage. However, it is optimized for routing and has limited other capabilities.

If you have multiple pieces of software that need access to the autopilot data stream, mavlink-router is one of the most used options.

Solution 3:

Use some Linux tools. These aren’t dealing with MAVLink specifically, but can still be used to push MAVLink messages through IP networks. Two are well known:

Both allow you to create a serial connection to the autopilot and link it to an IP network.

Solution 4:

Use [mavlink-hub.py] (https://github.com/peterbarker/mavlink_hub). This is another packet-distributor based on pymavlink; it has no routing capabilities and simply sends any packets received on any of its links to each of the other links. Lighter-weight than MAVProxy and written in portable Python, and thus heavier on resources than mavlink-router.

Solution to avoid : MAVROS

MAVROS is a great piece of software but it serves its purpose at linking ONE and only ONE MAVLink system (one autopilot for example) to ROS. It has some routing capabilities to relay messages but considering the heaviness of a ROS deployment, you shouldn’t use it for routing and especially if you don’t need to use other ROS tools. Prefer mavlink-router or even MAVProxy that are much simpler to maintain and efficient for routing.

The Mavlink routing protocol defines how a MAVLink message should be delivered when a target is settled. It can be resumed by the two following pictures.

With MAVLink routing prototocl |501x391

Without MAVlink routing protocol |501x391

Do you know some other solutions ? Let's us know !