Servers by jDrones

Swarming experiments for the common man - Part 3 - MULTICAST

Geese fly in a V formation because it reduces the naturally occurring downward pull of gravity. When the birds fly behind one another, it creates free lift. In essence, it allows the birds to save energy.


When I asked Andrew Tridgel (@tridge) what methods are available to publish the Leader Position Localisation over radio, here’s one of the answers:
“Use a multicast link, which gives you a shared transport.”

What is multicast?
In short, multicast is a means of sending the same data to multiple recipients at the same time without the source having to generate copies for each recipient. Whereas broadcast traffic is sent to every device whether they want it or not, multicast allows recipients to subscribe to the traffic they want. As a result, efficiency is improved (traffic is only sent once) and overhead is reduced (unintended recipients don’t receive the traffic).
More info here:

Examples of Multicast usage with ArduPilot

As demonstrated in real flight test by Tridge in the video above and using an adaptation of this Simulator -SITL- script:

The script is using mcast: as the default multicast mavlink socket  (

And start both instances of simulator by connecting to this socket
PLANE --model plane --uartA $UARTA
COPTER --model quad --uartA $UARTA 

Demonstrated using Morsesimulator by @ashvath100

Demonstrated using AirSim Simulator by @rajat2004

NOTE: For those who want to try the examples above on a Windows10 environment, there is an issue with MULTICAST on WSL2 as it restrict the usage to local address:, making the communication “non standard” . Traffic to multicast groups: IANA has reserved – for multicast groups, with commonly used within private organizations.
PyMavLink default UDP multicast mavlink socket (mcast:) is

Configurations and tests on RaspBerry pi:

A) Check if MULTICAST is enabled (it should be)
ip link show wlan0 | grep MULTICAST

B) Create route to wlan0 (This sets all of the class D (/4) Multicast routes to go via wlan0)
sudo route add -net dev wlan0

C) Make route permanent
sudo nano /etc/network/interfaces
up route route add -net dev wlan0

D) Check routes
ip route list dev wlan0 scope link

If you are wondering why ping (or any address in this class D) does not give you anything back it is because the ICMP to reply to broadcast/multicast ping message is disabled by default. To enable you need to edit /etc/sysctl.conf and set:
net.ipv4.icmp_echo_ignore_broadcasts = 0

Pi4-01 as Gateway : as Multicast Broadcaster
Pi3-10 & Pi3-11 connected to Pi4-01 Multicast signal
Dev PC on WIFI : (may change; adjust accordingly)

On Pi4-01 Start Arducopter local and launch mavproxy with Forward Position:
./arducopter --model quad --master tcp: --out udp: –out mcast:

Launch Pi3-10 and Pi3-11 that read position from Leader Multicast address
Follower Pi3-10
./arducopter –uartA mcast: --model quad --master tcp: --out udp:

Follower Pi3-11
./arducopter –uartA mcast: --model quad --master tcp: --out udp:

Why are we starting ./arducopter --uartA mcast: ?
We feed the multicast message directly to the simulated vehicle by connecting to the console port (5760) and map mavproxy to uartC (5763) in order to publish on the GCS:
Starting sketch ‘ArduCopter’
Starting SITL input
Using Irlock at port : 9005
UDP multicast connection
bind port 5762 for 2
Serial port 2 on TCP port 5762
bind port 5763 for 3
Serial port 3 on TCP port 5763
Home: -35.363262 149.165237 alt=584.000000m hdg=353.000000
Smoothing reset at 0.001
validate_structures:411: Validating structures

On Dev PC, connect to RPI4 and start mavproxy
mavproxy --master=udpin: --console --map

As explained before, get into each of the Pi3 sessions and Switch to Guided - Arm - Takeoff - and switch to Follow
Back to Dev PC Powershell MavProxy, select SYSID 1 : Guided - Arm - Takeoff - Guided using Map and enjoy the fly :slight_smile:

In the example below I have connected the Pi3 to Mission Planner. Note the link quality is quite acceptable considering the added Multicast signal.

INTEGRATION on QuadCopters

These pictures show how I installed and connected the Companopn Computers on my Vehicles

Flamewheel 450 with RaspBerryPi 4
this is the old “mule” that flew on so many experiments. It is cheap an ugly but it works just fine. The Pi is powered by a 5A Ubec located on left side of the CUBE and for this configuration, a connection on TTYAMA0 to Telemetry1 at 921600 Bauds (see Part 2 how to disable the bluetooth patch). The installation allows insertion and removal just by sliding ZipTies and transparent tubes and for easy connection to Keyboard - Monitor - Ethernet if needed.

Flamewheel 330 with RaspBerryPi Zero,
this is a collection of Hardware, Software*… and Tupperware…* as the protector is made of a Lemonade Jar :-). The RPI Zero is fixed using double sided foam tape with a FTDI siting on top with the same technique. This allows for interconnection to TELEMETRY or other devices like ESP-01 or SIK or XBee using AMA0 or USB0 at sppeds up to 921600 Bauds.

This type of installation is well suited for making different experiments as it allows for fast and easy modifications. I use a lot of doubleface foam tape, zip ties and transparent heatshrink that let you visually inspect connections and confirm signal by looking at the FTDI LEDS for example.

Visual BEACON,
for some of the SCRIPTING experiments (next Chapter) I can visually confirm that the Leader Position Signal is received and processde by the Follower. This is done by “deadbug” installation of a MOC8050 Photodarlington Optocoupler driven by RPI Zero GPIO 21 with 2.2 kOhm current limiter and driving a high power multi facetted 12 Volts LED.

This concludes the first part of this series of Blogs, where the existing methods of communication have been demonstrated and tested. A special thank to Tridge for his guidance, making my researchs for solutions more efficient.

In the next series, we will explore more specific techniques for Smarming communication and infrastructure. As usual, I am open for comments and explanations.

Other links of this series of blog:
Part 1
Part 2
Part 3
Part 4


@ppoirier I don’t want to connect any companion computers like raspberry Pi on the quadcopters, I am connecting mavesp directly as telemetry and I am able to get data from multiple quadcopters by directly connecting all mavesp modules to Ubiquiti Access point router, I find no issues with that, but when broadcasting commands to multiple quadcopters from GCS I am finding that some messages are getting dropped, is it due to cause of mavesp exchanging messages via UDP ?

Is there any way I can ensure if I am broadcasting any command to multiple quadcopters then atleast all receive that command even with slight delay with my current setup ?


As I wrote in Capter 1, UDP does not garantee delivery , it is based on "Best Effort’’:

For multiple signals , You need to reduce traffic an transmit only what is really required at the appropriate speed. You can read about it on Chapter 4 under: The fine art of data stream profiling

Servers by jDrones