PX4 MAVLink Stream Rates

If you are feeding a companion computer — running MAVROS, doing visual-inertial odometry, or logging IMU data for analysis — the default PX4 stream rates are often too slow. This page covers the three ways to change them, and why the rate you ask for is not always the rate you get.

MAVROS topic rates are set on the flight controller

A MAVROS topic is a republished MAVLink message. MAVROS does not decide how often it arrives; it publishes what the flight controller sends. So there is nothing to configure on the ROS side — change the MAVLink stream rate on the flight controller and the topic follows.

The example throughout is HIGHRES_IMU, because it is the one most often raised: it carries accelerometer, gyroscope, magnetometer, pressure and temperature, and VIO pipelines want it fast.

First, see what you are getting

QGroundControl → Analyze Tools → MAVLink Inspector lists every message arriving, with its measured rate.

Use it before and after every change. The rate you asked for and the rate you get are different numbers often enough that measuring is not optional.

Method 1 — the console, for trying things

The fastest way to experiment, and it takes effect immediately.

Connect the flight controller, then open QGroundControl → Analyze Tools → MAVLink Console and type:

mavlink stream -d /dev/ttyACM0 -s HIGHRES_IMU -r 100

Argument	Meaning
-d	the device — which link to change. /dev/ttyACM0 is USB
-s	the stream name, exactly as the inspector shows it
-r	the rate in Hz. 0 turns the stream off, -1 restores the default

So that line sets HIGHRES_IMU to 100 Hz on the USB link, and nothing else changes.

Device names are per board

USB is /dev/ttyACM0 everywhere. Serial ports are not consistent:

Board	TELEM 1
MicoAir H743	/dev/ttyS0
NxtPX4 V2	/dev/ttyS1

Check your board's documentation. The command fails against a device that is not there, and the failure is easy to miss in the console output.

Three things that make this command fail

The port must already be running. mavlink stream configures a running instance. A serial port with no MAVLink instance started on it — because MAV_x_CONFIG was never set to it — cannot be configured, and the command reports a failure.

Serial links need Onboard mode. For a companion computer, set that instance's MAV_x_MODE to Onboard rather than the default Normal. Normal mode carries the message set a ground station needs; Onboard is the profile intended for a computer on the aircraft, with the higher-rate streams MAVROS work depends on.

It does not survive a reboot. Everything set this way is gone on the next power cycle. That is the point of method 2.

Method 2 — the SD card, for keeping it

PX4 runs a startup script from the SD card if one is present, which makes the change permanent without recompiling anything.

Create /etc/extras.txt in the root of the flight controller's SD card:

mavlink start -d /dev/ttyACM0 -b 921600
mavlink stream -d /dev/ttyACM0 -s HIGHRES_IMU -r 200

The first line starts a MAVLink instance on the device at a given baud rate; the second sets the stream rate on it. Put the card back, power up, and PX4 runs the file once at boot.

Verify in the MAVLink Inspector.

The USB port starts only when something plugs into it

This catches people, and the symptom is that the file appears to do nothing.

A serial port that has been configured through its parameters starts at boot whether or not anything is connected, so a command aimed at it works.

USB does not. The port comes up when a computer or companion computer is plugged in. If the flight controller boots first and the cable goes in afterwards, the commands in extras.txt ran before the port existed and failed.

Power the flight controller with the USB cable already connected, or target a serial port instead.

Method 3 — firmware defaults, for a fleet

If you are building your own firmware anyway, the rates can be baked in. Worth it when you are flashing more than a couple of aircraft, or shipping an image to other people.

1. Set up a PX4 build environment following PX4's own development documentation.

2. Edit the stream tables in the MAVLink module's main source file. Each MAVLink mode has its own table of stream names and default rates:

   • MAVLINK_MODE_ONBOARD — what a serial link to a companion computer uses.
   • MAVLINK_MODE_CONFIG — what the USB link uses.

   Find the stream and change the number beside it.

3. Build for your board. The MicoAir H743 and NxtPX4 V2 board definitions are in the upstream PX4 repository, so a stock checkout can build them:

   make micoair_h743_default

   make hkust_nxt-dual_default

4. Flash the resulting firmware through QGroundControl and verify in the inspector.

Why you may not get the rate you asked for

Two hard limits sit underneath the number you typed.

Link bandwidth. HIGHRES_IMU is a large message. At 200 Hz it is a substantial data rate, and a serial link at 57600 baud cannot carry it at all. USB or a fast serial link is the only way to high rates.

Processing time. The flight controller is flying an aircraft. Packing and sending messages competes with that, and flying wins.

In practice, asking for 200 Hz on HIGHRES_IMU can land around 185 Hz on real hardware. That is not a fault.

The lever that helps

IMU_GYRO_RATEMAX caps the rate at which the gyro control data is published — the inner loop rate for the rate controller and the outputs. It defaults to 400 Hz and accepts 100, 250, 400, 800, 1000 or 2000. A reboot is required.

Lowering it frees processing time, which can let a MAVLink stream get closer to the rate you asked for.

The trade is real but smaller than it sounds:

• The rate controller runs less often, which at some point costs control performance on a twitchy aircraft.
• Sensor data is still read and filtered at the full raw rate regardless of this setting — commonly several kilohertz. This parameter changes the control publication rate, not the sampling rate.

So on a research airframe where high-rate IMU data out is the point, dropping the inner loop from 400 Hz is often the right trade. On an aggressive quad it is not.

Measure before and after. The MAVLink Inspector is the only thing that tells you whether it helped.

Which method to use

Situation	Method
Trying a rate, finding what the hardware will do	Console. Instant, and lost on reboot, which is what you want while experimenting
One aircraft that needs the setting every flight	extras.txt on the SD card
Several aircraft, or firmware you distribute	Firmware defaults

A reasonable order: find the working rate with the console, write it into extras.txt, and only build custom firmware if you are doing it to more than a couple of aircraft.

Easily confused points

MAVROS does not set the rate. It publishes what arrives.

The requested rate is a request. Bandwidth and CPU both cap it.

IMU_GYRO_RATEMAX is the control publication rate, not the sampling rate. Sensors are still read and filtered at full speed.

Device names are board-specific. TELEM 1 is not the same device on every board.

Console changes do not survive a reboot.

USB does not exist until something plugs in, which is why extras.txt can appear to do nothing.

Serial links to a companion computer want Onboard mode, not the default Normal.

Related guides

• PX4 Build & Configuration Walkthrough
• PX4 FAQ
• NxtPX4 V2 — User Manual
• PX4 — Telemetry Setup Guide
• Flight Controller Firmware Flashing Guide

Where to buy

Flight controllers that run PX4, shipped from Canada with free Canada-wide shipping:

• NxtPX4 V2 — the 20 × 20 mm PX4 research board, built for companion-computer work
• MicoAir H743 V2 — a full-size alternative that also runs PX4

---

Written and maintained by the Robofusion engineering team.