Increasing stream rate of sensor data

Hi all

I’m using the PixHawk running ArduSub which is used together with the MAVROS package. Is it possible to increase the stream rate of the sensor data? Currently I have only accomplished to transfer IMU data with a rate of 10 Hz.

The command I have tried is:
rosrun mavros mavsys rate --raw-sensors 20
but it is limited to 10 Hz.

Best Regards,

Stream rates are limited in ArduSub to 50Hz max:

10Hz is the suggested maximum stream rate, if you go above this you may experience weird/undefined behavior due to the increased time spent transmitting messages.

If you connect to qgc, you can change the stream rates to more than 10Hz by looking at the SR parameters and clicking force save (you will get a message that 10 is the maximum).

If you can’t adjust in mavros to more than 10, I suspect that mavros is limiting it internally.

If you are using mavproxy, the stream rates will revert to mavproxy’s configured stream rates, regardless of what you change them to:

Hi Jacob

Thanks. I will try to change the stream rates through qgc tomorrow. Will let you know if it works.



What I want to achieve, is to bring control system design into ROS, rather than having it implemented on the PixHawk layer. At the moment, I was thinking about putting the ROV in a manual mode and then using ~/rc/override for sending direct thruster commands.

Do you think this is possible given the limitations in sensor frequency and potential jitter, or are there better ways of doing this?


What is your goal? Do you want the vehicle to be stabilized by code running in ROS? If that is the case, I think you should go without the pixhawk and get an IMU and something to generate the pwm signals (microcontroller or PCA9685). It may be possible to use the PixHawk and ROS like this, but I’ve never heard of this being done.

If you simply want to maneuver (autonomously or not) the vehicle with ROS, you can use mavros and let the pixhawk take care of all the stabilization stuff.

The APM code on the pixhawk prioritizes control and INS over communications, there will be at least some latency in the imu readings and ros communications. I don’t know if the latency will be great enough to pose an issue. I think you might run into issues that can only be solved by becoming intimately familiar with the APM code (takes a long time) and making significant modifications (takes a long time) and subsequent debugging issues with the APM code (takes a long time).


Hi Jacob

That was a very helpful answer. The thing is that I want as much control over the controller design as possible, including the stabilizing part. I dream about being able to run it all from something like MATLAB Simulink using the ROS msg interface, but that might seem a bit unrealistic. I guess the best thing would be to let the pixhawk take care of the low-level stabilization, and then use ROS for the high-level maneuvering part. As you can confirm, my experience is that its pretty difficult to make changes in the APM code as it takes a long time to debug and get familiar with.

Btw, I tried to increase the streamrate. The problem was in the baud-rate, that I was currently running with 57600 bps. Increasing this to 115200 bps, has allowed me to go beyond the 10 hz limit, but only up to 25 hz. But I have experienced some wierd behavior in the message receive rate in ROS. If I specify a stream-rate of 20 hz, I get 25 hz. And sometimes it drops to a very low value.

Do you know what is the maximum workable baud-rate on the pixhawk when using TELEM2 and a FTDI serial-to-usb?

Also, do you know what is the maximum rc-override frequency?



The 20/25Hz thing happens because the timing is calculated with integer math: ardusub/GCS_Common.cpp at master · bluerobotics/ardusub · GitHub

I have communicated with pixhawk uarts setup for mavlink at 1.5Mbs, I don’t know what the limitations on the ftdi chip are.

I’m not sure how quickly you can stream the RC_OVERRIDE messages to the pixhawk and have them all make it through.


@jwalser I want to run some visual odometry algorithm on the tethered laptop. I am working on running gstreamer with ROS. I am pretty close to that. But I am having problems getting high-resolution IMU data.

Can you point me to any viable direction? Looks like I may not need mavproxy after that at all and use mavros instead.


Hi @bjoshi

I’m not sure if you mean real resolution or just a higher frequency.
For a higher frequency, try requesting a higher rate of RAW_IMU and SCALED_IMU2 , the functionality seems to be already in mavros.

For an increased resolution, you would need to change the message fields from int16_t and rebuild pretty much everything (ardupilot, mavros, pymavlink…)

I meant high frequency. Thanks for the input.