Configuring Telemetry Rates in Ardupilot

This post is an explainer on the telemetry datarates in ArduPilot, plus information and data on how to configure the datarate to fit in lower-bandwidth radio systems.

Typical Datarates

Telemetry radios used in Ardupilot

All datarates in this article are averages and are rounded to 1 decimal place. Does not include actions such as downloading parameters or waypoints. All datarates are in the Vehicle → GCS direction.

ArduPilot telemetry is a series of MAVLink messages output from a UART (or serial) port on the flight controller.

The MAVLink messages may be a streamed message (message is emitted at some regular rate), such as the vehicle’s GPS position or hardware status. Other messages are emitted in response to a command or query from the ground station, such as downloading parameters or a confirmation of a flight mode change.

The following table shows the average datarate of the default streamed messages from the different ArduPilot firmwares at the default rate of 4Hz. Note the datarate whilst the vehicle is armed is slightly higher, as additional streamed messages (such as NAV_CONTROLLER_OUTPUT) are active. The datarate will vary depending on the vehicle hardware and configuration, as additional sensors (such as a 2nd GPS) will increase the datarate.

FirmwareDatarate when disarmedDatarate when armed
Plane3.5 kbytes/sec4 kbytes/sec
Copter3.5 kbytes/sec3.7 kbytes/sec
Rover3.4 kbytes/sec3.9 kbytes/sec

On a typical 57600 baud RF telemetry radio, this equates to 59%-69% of the available radio datarate being used.

Lowering the Datarate

If you are using a lower baud RF link, then ArduPilot’s streaming datarates may need to be trimmed down. There are several methods to do this.

The easiest method is to lower the rate of the streams. By default, a GCS will ask ArduPilot to stream at 4 Hz. This can be changed in Mission Planner in Config→Planner→Telemetry Rates or in MAVProxy via the --streamrate=n commandline option.

So, lowering the streamrates down to 1Hz gives the following average datarates:

FirmwareDatarate when disarmedDatarate when armed
Plane0.9 kbytes/sec1.0 kbytes/sec
Copter0.9 kbytes/sec0.9 kbytes/sec
Rover0.9 kbytes/sec1.0 kbytes/sec

Taking this further, streams can be disabled. For example, you may not want raw sensor readings or RC channel values. In that case, set the “Sensor” and “RC” streams to “0” in Mission Planner. At this time, MAVProxy does not support setting individual streamrates.

If preferred, these streamrates can be set on ArduPilot instead of the GCS 3.

The average datarates are now:

FirmwareDatarate when disarmedDatarate when armed
Plane0.7 kbytes/sec0.8 kbytes/sec
Copter0.6 kbytes/sec0.7 kbytes/sec
Rover0.6 kbytes/sec0.8 kbytes/sec

Individual Message Control

If finer grained control of which MAVLink messages are streamed is desired, the individual messages and rates can be controlled. There are a few methods for doing this.

For this example, a file containing the message ID’s and rate (in milliseconds) is placed in the SD card’s root directory:

message-intervals-chan0.txt

33 200
1 1000
74 2000

The above file tells ArduPilot that chan0 should stream

Rpanion-server 0.8 Released

We are happy to announce the release of Version 0.8.0 of Rpanion-server!

Rpanion-Server is an Open-Source software package for a managing the companion computer (such as the Raspberry Pi and NVIDIA Jetson) connected to an ArduPilot or PX4-based flight controller. It will run on most Linux-based systems.

Rpanion-Server consists of a node.js webserver for the user interface and mavlink-router for routing MAVLink telemetry from the connected flight controller. GStreamer handles low latency video streaming from any connected cameras. There are also modules for managing network connections, NTRIP streaming and viewing hardware information.

Version 0.8.0 adds the following major new features:

  • Add UDP video streaming
  • Support for Ubuntu on the Raspberry Pi and NVIDIA Jetson
  • Add fps option for video streaming
  • Ad-hoc wifi support
  • Wifi channel selection in AP mode
  • TCP server for MAVLink telemetry
  • NTRIP streaming support
  • UI more consistent

The documentation and pre-built disk images for the Raspberry Pi are available at https://www.docs.rpanion.com/software/rpanion-server.

The source code can be found in GitHub, at https://github.com/stephendade/Rpanion-server.

New Product – RoverBase

We are proud to announce the release of the Roverbase board!

The RoverBase integrates the following into a single board:

  • 18650 battery power supply in a 2S2P layout (4 batteries required)
  • 2x 5V, 3A power supplies.
  • Voltage and current monitoring
  • 2x 7.4V, 1.7A brushed DC motor controllers
  • Power switches for major subsystems
  • Battery charging port

These features make the RoverBase ideal for small skid-steer ground rovers, such as the Pololu Romi or Bogie Runt Rover.

Head on over to the webstore to purchase one!

AprilMAV – Using a Raspberry Pi for Indoor Robot Navigation

There are now many options available for indoor navigation, from devices such as the Intel T265 to UWB or Lidar systems. The objective of this project is to create a (relatively) cheap and accessible indoor navigation system via Apriltags.

Apriltags are well-used in the robotics community and are able to have their pose (position and orientation) relative to the camera calculated.

Aprilmav uses ceiling-mounted Apriltags as navigation markers. A Raspberry Pi will capture and process the images of the Apriltags, then calculate the camera (and thus the attached vehicle) location and orientation relative to the Apriltags.

The positions of the Apriltags do not need to be known in advance. The vehicle will begin at the (0,0,0) location and (0,0,0) orientation. Each detected Apriltag will be given a position and orientation relative to this when first detected. Each subsequent detection of the Apriltag will use the delta position/orientation to determine the vehicle’s movement.

Hardware

I used the following components:

The Romi has wheel encoders, which were also connected to ArduPilot for additional velocity measurements.

The ArduCam OV9281 was chosen because it’s a cheap global shutter camera. It’s very important that a global shutter camera is used, in order to reduce image distortions.

The Raspberry Pi Camera was trialled, but gave very poor results due to motion blur.

In terms of the flight controller, any ArduPilot flight controller would work, as long as it has 2Mb of flash. Since I was using brushed DC motors and wheel encoders, I needed 8 PWM outputs (4 for the motors, 4 for the wheel encoders), so the Pixhawk worked well.

Any single-board computer will work, but it should be powerful enough to run the Apritag detection at 5fps. I found that the Raspberry Pi 4B could do this, but not the earlier Pi models.

Software

The Raspberry Pi ran the Aprilmav scripts for detection and processing, plus Rpanion-server for telemetry routing.

Aprilmav captured images from the camera, detected any Apriltags and then calculated the Vehicle’s position/orientation based on the position and orientation of the tags.

Aprilmav then sent the HEARTBEAT, SET_GPS_GLOBAL_ORIGIN, VISION_POSITION_DELTA and VISION_POSITION_ESTIMATE messages to ArduPilot. These in turn were consumed by ArduPilot’s EKF3 to generate a final position/orientation of the vehicle.

The full Aprilmav source code is at https://github.com/stephendade/aprilmav

Performance

Given the low-cost hardware involved, accuracy was only 10 cm. This was enough for most indoor navigation tasks.

It should be noted the Apriltags do not have to be placed on the ceiling. They can be placed anywhere, but the best accuracy was obtained when the tags were on the ceiling, as the vehicle was always 90 degrees to the tags (Apriltag pose accuracy goes down it the slant angle is <90 degrees).

Additionally, a well lit environment is required, so the camera can clearly see the features of the Apriltags.

In terms of frame rate performance, >5fps is

Rpanion-server 0.7 Released

We are happy to announce the release of Version 0.7.0 of Rpanion-server!

Rpanion-Server is an Open-Source software package for a managing the companion computer (such as the Raspberry Pi) connected to an ArduPilot or PX4-based flight controller. It will run on most Linux-based systems.

Rpanion-Server consists of a node.js webserver for the user interface and mavlink-router for routing MAVLink telemetry from the connected flight controller. GStreamer handles low latency video streaming from any connected cameras. There are also modules for managing network connections and viewing hardware information.

The web-based user interface provides access to view and manage all features. This makes it easy to manage common functions such as network connections, flight logging, telemetry streaming and configuring video streams.

Version 0.7.0 adds the following major new features:

  • Support MJPEG cameras for video streaming
  • Added button to disable all Wi-Fi adapters
  • GUI overhaul, using the Bootstrap framework

The documentation and pre-built disk images for the Raspberry Pi are available at https://www.docs.rpanion.com/software/rpanion-server.

The source code can be found in GitHub, at https://github.com/stephendade/Rpanion-server.

Pi-Connect Lite 1.2 released

We are proud to announce the release of the latest version of the Pi-Connect Lite board.

The major new feature is an EMC filter in the power input. This filter is designed to be compliant to the CISPR 22B standard. This gives a level of assurance that the Pi-Connect Lite will not radiate harmful interference nearby devices. This is particularly important in UAV’s, where sensitive electronic equipment is often placed very close to power converters.

ESD protection is enhanced too, with dedicated ESD protection for the external switch.

There is also a 5.1V power output port to make it easier for additional devices to be powered off the 5.1V/3.5A power supply to the Pi.

The Pi-Connect Lite V1.2 is now available for purchase in the webstore.

Rpanion-server 0.6 Released

Rpanion-Server is an Open Source software package for a companion computer (such as the Raspberry Pi) on autonomous vehicle. It provides a web-based interface for configuring the network, telemetry (MAVLink) routing and logging from a connected flight controller.

Also included is a low-latency video streaming server.

Documentation, source code and pre-built disk images for the Pi are available at https://www.docs.rpanion.com/software/rpanion-server.

New in 0.6 is:

  • Dataflash (bin) logging from flight controller
  • Better MAVLink routing performance
  • Improved GUI messages

Companion Computer Trends 2020

I recently ran a survey to determine how and where companion computers were being used by the ArduPilot community.

This was done as part of research into a successor to my Pi-Connect board, but the results are also of interest to the community.

I would caution that I did not get as many responses as I had anticipated (53 respondents). The results presented below should not be taken as precise numbers. They should be interpreted as general trends instead.

Results and Observations

Most ArduPilot users do use (or plan to) companion computers. I would point out that this being a “companion computer survey”, many people who do not use them may have elected not to complete the survey.


There is a generally equal split between hobbyist, commercial and R&D work; but with a slight bias towards hobbyists. Respondents could select multiple answers here if they wanted.


No clear winner here. This shows how varied and flexible companion computer usage is. Respondents could select multiple answers here if they wanted.


It is very clear here that the Raspberry Pi and Nvidia Jetson are by far the popular companion computers. Respondents could select multiple answers here if they wanted.


Over a third of users are creating their own software using libraries such as pymavlink, dronekit or MAVSDK.

There’s a lot of development going in here, with 73% of respondents doing some level of bespoke development.


Python and C/C++ are by far the most used programming languages for software development. Javascript wasn’t as popular as I expected, possibly indicating that web-based GUI’s (Javascript’s typical use case) are not a commonly developed tool. I would be interested to see what proportion of the Python and C/C++ users are using ROS though, as it’s not clear if the ROS users answered as ROS or using Python/C++.

Respondents could select multiple answers here if they wanted.


Looking at the top desired features here, it links back to why the Raspberry Pi and Nvidia Jetson are so popular. Respondents typically want something small with a powerful CPU, plenty of existing software libraries and good community support – which the Pi and Jetson excel at.

Summary

For ArduPilot users, most companion computer usage is centred on the Raspberry Pi and Nvidia Jetson. C/C++ and Python development of bespoke applications is typical on the software side, creating a wide variety of applications.

Companion Computer Survey

I’m running a small survey of the usage of companion computers in the ArduPilot community.

It’ll take less than 10 minutes to complete.

Even if you don’t use a companion computer, please respond (it’ll take less than 5 seconds) so we have an idea of what proportion of users are or are not using companion computers.

The results of sections 1 and 2 of the survey will be published online so developers in our community can focus their efforts accordingly. Sections 3-4 I’ll be using to narrow down options for a successor to my Pi-Connect board.

The survey is at https://forms.gle/77pXu1mJ5psUwQcs9