Hi,
I set the stream rate to 10 Hz for all streams. When The quad is on the ground, I do indeed get 10 messages per second, but when in flight, the stream rate become irregular and on average I get something like 6 messages per second. Is this behavior known? any way to get around it?
Thanks!
I think the issue is likely going to either be CPU load or (more likely) bandwidth restrictions (i.e. the serial buffer is getting full).
I think it would be good to try using the ChibiOS builds to see if that helps. If it does then it’s more likely that the issue is CPU load.
It’s perhaps not immediately helpful but in Copter-3.7 (and plane, rover, etc) we’ve added support for “Message Intervals” which allows more precise control of what messages are sent (and their rate). This will (eventually) help if the issue is bandwidth because there are probably a lot of messages being sent with info that you don’t care about.
So I tried chibiOS, it didn’t help.
I will try the 3.7 Dev version with set message interval.
How much dat rate can your radios handle ? How much from it are you using ?
Try to use https://github.com/ArduPilot/pymavlink/blob/master/tools/mavtelemetry_datarates.py to answer the second question.
I might not have been clear, but I am streaming over uart to a companion computer, not over radio.
regardless or radio, or direct serial link, there is a data rate limit!!!
hello,
what is your companion computer software ? Generally, GCS are overriding the streamrate reculary, check that you software isn’t doing that or that you don’t have a GCS on that channel that is doing it
Thanks, I am aware of GCS overriding rates. That is not what is happening here (I wrote my own GCS and I set the stream rates, there is no additional GCS in the loop).
The limit is board dependent?
The issue is that the rate drops during flight.
If I look at the time difference between arrival times of a given mavlink packet, say attitude- when on the ground I get a steady 100ms interval. When in flight the time differences are scattered anywhere from 0 to 200ms, sometimes even more.
Why would the data rate change?
Try plotting the packet sequence numbers. My guess is loss (remember
mavlink is lossy!)
Check RAD.rssi and RAD.noise (and RAD.remrssi / RAD.remnoise)
Is not board dependent. It is obviously dependent on the baudrate set on your serial port.
I set the baud rate to 1500.
I will look at the sequence numbers. However 30% packet loss seems ridiculous. I would think mavlink is more reliable than that. Also, why should I loose anything over a direct serial connection?
If your baud rate is set to 1,5 Mbaud, but you are trying to send around 1,95 Mbaud, guess what is going to happen?
So … did you calculate the rate that actually gets used using the python tool described above? If yes what are the results?
mavtelemetry_datarates.py says I’m using 81840 bits/sec
Obviously 1.5mbaud is gross overkill. Any ideas?
Hello Daniel,
I am also having a very similar issue.
I’m trying to send ATTITUDE and LOCAL_POSITION_NED messages to the companion computer (Jetson TX2) and I need to send them at a reasonably high rate in order to use it with mavros. Currently with default settings arducopter is not able to send these two messages through Serial 2 port whose stream rate is supposedly configured by SR2_x parameters. I have set SR2_POSITION and SR2_EXTRA1 parameters to 10 but this stream rate apparently is not fast enough for my applicaton, and also Ardupilot is limiting the rates even if I set them to 10 so I can’t really get 10.
Also I need to send these topics at higher rates (at least at 50Hz) and I’m seeking for solutions to enable this within arducopter. I’ve come up with some ideas but wondering if they would really work or break anything related to the internals of ardupilot. Your problem might also be solved by these @danielh if they do not completely break the code or somehow throttle the CPU and crash the copter.
/ardupilot/ArduCopter/ArduCopter.cpp file’s line 139 from SCHED_TASK(gcs_data_stream_send, 50, 550),
to
SCHED_TASK(gcs_data_stream_send, 100, 550),
SR2 parameters, I’ve overridden the persist_streamrates() function by adding bool persist_streamrates() const override { return true; }
to /ardupilot/ArduCopter/GCSMavlink.h
Would these changes together or independently break anything? @peterbarker Thank you in advance!
Hi Deniz,
As far as permissible rates, it is theoretically possible to set the data rate up to 50 Hz via the mavlink set stream rate command (As opposed to mission planner that limits you at 10Hz). In practice, I wasn’t able to obtain this during flight. I prefer not to intervene with the ardupilot code at the moment.
Randy, are there any precautions I should take before trying 3.7 dev?
Thanks!
… since you’re hacking the code anyway, I suggest you use master, and
Randy’s patches to ROS to use them. master allows the user of
SET_MESSAGE_INTERVAL, and Randy’s ROS stuff uses it.
Would these changes together or independently break anything? @peterbarker Thank you in advance!
Let me know if there’s a good reason you can’t use master for this and
I’ll stare at things for you. However, we did implement
SET_MESSAGE_INTERVAL for a reason 
Thank you for your quick response. I was using Copter 3.6.5 for my tests. @danielh I figured out that when I request all data streams at 50 Hz using
rosrun mavros mavsys rate --all 50.
ardupilot tries to send all of them at 50 Hz. But since the main loop that controls all of the stream rates runs at 50 Hz, I observed that it can’t handle sending all of them at 50 Hz. So I’ve reduced some of the streams and individually changed two streams to 50 Hz and it seems that it works like this. But of course I have to do this every time I reboot the FCU.
#startup.sh
rosrun mavros mavsys rate --all 5 #Without this line /mavros/state is connected but no other topics are published by mavros
rosrun mavros mavsys rate --extra1 50 #for ATTITUDE message
rosrun mavros mavsys rate --position 50 #for LOCAL_POSITION_NED message
@peterbarker
I will definitely switch to master and take a look at the SET_MESSAGE_INTERVAL related code and try to get these messages on master since the aforementioned mavros commands are only workarounds. Thanks a lot!