Increase MAVLink IMU data stream rate

I try to find IMU data via mavlink.

master = mavutil.mavlink_connection('udpin:0.0.0.0:14550') message_imu = master.recv_match(type='SCALED_IMU', blocking=True).to_dict()

but it doesn’t return any message.
When I change SCALED_IMU to SCALED_IMU2, IMU message can be found.
However the frequency of that is 10Hz.
(I cannnot also capture other high frequency data(bar presuure sensor data, attitude data etc…) in high frequency.)

Could you tell me how to get this data in more high frequency?

Hi @yuki,

ArduSub sends its IMU data via SCALED_IMU2 MAVLink messages, and does not currently use SCALED_IMU by default (it’s listed as requestable, but I’m not sure what data it would have if you did request it). The SCALED_IMU2 message is sent as part of the SRn_RAW_SENSORS stream group, and the frequency is controlled by the corresponding SRn_RAW_SENS parameter.

Note that increasing the telemetry rates can cause bandwidth issues, and may overwhelm the code you’re using the parse the messages. The autopilot has access to much higher sensor data and output control rates (and with significantly lower latency), so if you’re doing this because you want some form of stabilisation control over the vehicle then it’s likely better to implement that as a flight mode in ArduSub rather than via an external program using MAVLink communication (assuming the feature(s) you want aren’t already available within ArduSub’s existing flight modes, of course).

Do you know any idea to record these data (IMU, attitude) more in more high frequency? (possible by any method other than MAVLink communication)

I said that I could record IMU data at 10Hz in the former post.
However I tried to record these data during or after using the QGC the frequency is reduced to 5Hz.
In addition, I can record ony one data (ex. only IMU(acc,gyro,mag)) when I tried to record these data(IMU, attitude etc…) separately at separate program in the same situation. (all data can be captured separately before using QGC)

Record, or stream?

If it’s ok to retrieve the data after a dive then you can likely get it from dataflash logs (.bin) stored on the autopilot*. We don’t currently have reference documentation for the dataflash messages supported by ArduSub, but they should be similar to those for ArduCopter.

*Note: If you’re using a Navigator you can access dataflash logs from the BlueOS Log Viewer. With a Pixhawk they’re currently only fetchable via QGroundControl/MAVProxy.

You can configure telemetry stream rates in QGroundControl via Application Settings / MAVLink:

I’m not certain what you mean by this. This comment may be of interest / relevance.

I would like to stream in real time.

I would like to run program1.1 and 1.2 at the same time.
It is successfull before I boot QGC, but failed after boot.

・Program1.1

master = mavutil.mavlink_connection('udpin:0.0.0.0:14550') 
message_imu = master.recv_match(type='SCALED_IMU2', blocking=True).to_dict()

・Program1.2

master = mavutil.mavlink_connection('udpin:0.0.0.0:14550') 
message_posi = master.recv_match(type='LOCAL_POSITION', blocking=True).to_dict()

I have one more question.
I would like to run program2.1 and 2.2 at the same time.
Is it possible?

・Program2.1

master = mavutil.mavlink_connection('udpin:0.0.0.0:14550') 
message_imu = master.recv_match(type='SCALED_IMU', blocking=True).to_dict()

・Program2.2

MAVProxy/MAVProxy/mavproxy.py --master 192.168.2.1:14550 --console --baudrate 57600 --out udp:127.0.0.1:14550

I don’t see why QGC would stop either of those messages from being sent, but you can check the group stream rates in QGC, as I covered in my previous comment.

For the implementation, I would be more inclined to have a single program, with a single mavlink connection, that receives and handles both message types as relevant (without blocking, as discussed in the comment I linked to).

If you want to run both programs independently then that may also work, but I would expect it to require using different UDP ports instead of both using 14550.

It should be possible to run mavproxy and a pymavlink program at the same time, sure. Since you’re seemingly setting an output port to the loopback IP then running both of those on the onboard computer should allow the pymavlink program to connect to and communicate with mavproxy.

As in my first comment though, I’m not sure what data ArduSub would send if you request SCALED_IMU, if it sends anything at all.