General drone setup

If you work with multiple drones, first of all, make sure that each of them has a unique ID (set by the MAV_SYSID or SYSID_THISMAV parameter, depending on the ArduCopter version you use - the former got introduced in version 4.7).

If you have more than 250 drones, we recommend to setup multiple WiFi networks and also use our custom SHOW_GROUP parameter and setup different values for each subset of 250 drones. The latter allows you to address all your drones individually in our Skybrush-specific custom MAVLink messages through Skybrush Sidekick and the secondary radio channel as well.

On setting up large fleets, see Skybrush server documentation for more details.

We require to use MAVLink 2 protocol instead of MAVLink 1 in all serial channels where MAVLink is used:

where x is the number of the channel you configure.

MAVLink 2 is required for the serial wifi channel and for MAVLink-driven LED support, too.

To disable excess communication on the wifi channel, please disable all unwanted messages:

where x should be the number of the serial channel of your wifi connection.

Please note that Mission Planner and other GCS software tend to change these parameters permanently without notice, which might result in bandwidth shortage if many drones are used.

Drone shows require accurate horizontal and vertical positioning of the drones. The horizontal positioning is provided by GPS in outdoor shows and some beacon-based navigation system in indoor shows. The vertical positioning is a bit more complex as there are usually two possible altitude sources in a drone: the pressure sensor and the GPS. The pressure sensor provides altitude above home level (AHL), and it is assumed to be zero at takeoff. The GPS provides altitude above mean sea level (AMSL). Autopilots usually maintain an assumed offset between the two altitude sources and they fuse the two measurements, assigning a higher weight to the pressure sensor because GPS-based altitude readings are not very accurate if you do not use RTK corrections.

The preferred set of parameters is different, based on whether you want to fly without RTK corrections or with RTK corrections. Without RTK corrections, the pressure sensor should be the primary source of altitude and Skybrush Live must be configured to control the show based on AHL because this is what the pressure sensor provides. In this setup, GPS altitude will be blended into the altitude reported by the pressure sensor, but only with a relatively low weight:

The above settings instruct the drone to use GPS for velocity and horizontal position, but to use the pressure sensor for vertical position.

If you want to fly with RTK corrections, the primary source of altitude should be the GPS. Our firmware is smart enough to use the GPS as the altitude source only if RTK corrections are present (and it falls back to the pressure sensor in case of loss of RTK corrections). The preferred settings should be:

Skybrush uses the built-in position and waypoint controllers of the ArduCopter firmware, and it sends updated setpoints to these controllers at a high frequency (several times per second). The default settings of the controllers are better suited for use-cases when setpoints are changed infrequently, and the controllers themselves have a tendency to shape or limit the inputs they are provided with. In order to avoid the firmware code to alter Skybrush’s commands significantly, the limits of the position and waypoint controllers should be raised. A reasonable set of default settings for most mid-sized show drones is as follows:

If you are using an older version of our firmware, it might happen that some of these parameters do not exist yet; feel free to ignore these.

Note that you can also alter the sharpness of the response to the changes in the desired show trajectory with our custom SHOW_VEL_FF_GAIN parameter, which determines how much velocity feed forward should be mixed into the position control during a show. Higher values will react to high desired acceleration more abruptly and thus reduce the delay between the desired and actual position, but will also reduce the smoothness of the drone motion.

At show start drones first arm their motors and spin them at low speed, then take off only after a few seconds. To prevent the drone from disarming its motors before takeoff, set the following:

Any value higher than 10 is OK, but do NOT set it less than 10.

It is useful to enable logging of all incoming RTK correction messages on the drone; this allows you to get an idea about the quality of your wifi and radio link during a show as a function of distance (assuming that you are transmitting RTK corrections continuously from the ground station). However, ArduPilot seems to log the detailed state of the RTK message parser only if RTK corrections are detected on more than one telemetry stream (i.e. wifi and radio). It is therefore useful to force ArduPilot to log these messages all the time, even if only one telemetry channel is used for RTK corrections:

Note that GPS_DRV_OPTIONS is a bitmask so if you have any other bits enabled in this parameter, then simply make sure that bit 6 is also enabled.