Hi everyone!
I am using mavros to connect to apm, uploaded on a pixhawk and I need IMU data as fast as possible on my computer. but in mavros maximum rate that I could set, using set_streamrate service, was 50 hz but I do need more than that ( at least 200 hz). what could be the source of this limitation? is this something related to apm firmware or it is mavros that limits stream rates?
1 Like
I am using mavros to connect to apm, uploaded on a pixhawk and I need IMU
data as fast as possible on my computer. but in mavros maximum rate that I
could set, using set_streamrate service, was 50 hz but I do need more than
that ( at least 200 hz). what could be the source of this limitation? is
Curent streamrate stuff won’t do more than 50Hz.
this something related to apm firmware or it is mavros that limits stream
rates?
You might like to try my message-interval branch - it can go faster, and
you can limit it to specific messages to avoid processing overhead.
Hi Peter,
I am looking for a solution to publishing IMU at 200hz for a long time. Could you tell me where I should look to modify into Ardupilot to enable it or where is it your message-interval branch? I looked into your fork of APM with no luck.
Thank you in advance.
This is all merged into master.
Usually one wouldn’t push up IMU data - if you want high-rate IMU
externally you’d usually get your own sensors 
In MAVPRoxy you can manipulate the streamrates like this:
long SET_MESSAGE_INTERVAL 27 10000
where 27 is a mavlink message ID
Peter
This is very handy. It appears that we are still limited to 80% of the main loop rate which limits those of us on rover with default settings to 40Hz. Any work around for this?
param set SCHED_LOOPRATE 400
Yes that would be an obvious solution however in our case we are reaching the bandwidth limits of our CAN bus and increasing the motor controller output rate beyond 50Hz would cause issues.
There’s not a lot of point getting the message at >40Hz if you’re only
getting new data at 50Hz anyway (sensors obviously gather it much faster
but it is the main loop which calculates the values you will see in the
message. Further, the vehicle will obviously not react on that data
you’re seeing anyway, so it would really only be useful for external
purposes rather than any sort of diagnostics.
Perhaps we need an ESC_RT to match the SRV_RT parameter to help with the
bandwidth problems?
Definately take your point regarding data rates vs control rates. In our case we are using the raw sensor data to compare against EKF performance for use in SLAM (lidar). Granted, this is not your typical use case.
Hi,
When I am using this command my stream rate is set to 333hz no matter what time interval I send
thanks