Ardupilot: SET_MESSAGE_INTERVAL not supported

[defreng]

Hi!
It would be helpful if the new message interval feature would be supported to have more fine-grained control over individual message sending rates

[guglie]

Any news about this?
What means NeedToChangeGCS?
Can it support both SRx_ parameters and SET_MESSAGE_INTERVAL?

I'm surely missing something...

[peterbarker]

@guglie This is where I'm up to with supporting message intervals:
https://github.com/ArduPilot/ardupilot/pull/7234

The SRx_ parameters would probably be retained to give initial values for the message intervals. Storage for individual message intervals continues to be a problem to be resolved.

[guglie]

Thanks @peterbarker, I'll look at your changes to understand it better.

Is storage for individual intervals a problem for persistent or temporary storage? Or both?

If the problem is only for persistent maybe we can just handle it as a volatile setting...

Or we can support only a fixed number of "settable interval messages" storing the message ids and their interval.

Are these two solutions breaking the mavlink protocol?

[magicrub]

I'd like to work on this a little bit too because I'd like certain values at 50 Hz (or higher where possible)

[OXINARF]

Storage for individual message intervals continues to be a problem to be resolved.

@peterbarker In my opinion we shouldn't store that. From my understanding the SET_MESSAGE_INTERVAL message was done precisely so that autopilots don't have to store stream rates and it is up to the GCSs to ask for it for each message.
Obviously this will be a problem for any GCS that doesn't support the new message, so I think we should comply with the stream rate parameters until we get a SET_MESSAGE_INTERVAL command.

[guglie]

Wonderful @OXINARF, this is exactly what I was thinking about.
So the GCSs will have time to implement the new command, if needed.

[peterbarker]

On Thu, 16 Nov 2017, guglie wrote:

Is storage for individual intervals a problem for persistent or temporary
storage? Or both?

Both, to one extent or another. Persistence is the main problems, but
there seems to be some agreement that persistence isn't required.

Temporary storage is currently at 14 bytes per message, and we currently
stream out ~30 messages (at least in SITL!). So that's 520 bytes.

Or we can support only a fixed number of "settable interval messages"
storing the message ids and their interval.

That may have to be the case.

Are these two solutions breaking the mavlink protocol?

I don't believe so.

[guglie]

Thank you @peterbarker for the detailed answer.

Temporary storage is currently at 14 bytes per message, and we currently
stream out ~30 messages (at least in SITL!). So that's 520 bytes.

This is true if we receive a SET_MESSAGE_INTERVAL for every message, but having some default group settings with stream rates and (temporary) setting the interval for a few messages seems a reasonable scenario that enhances the flexibility of this multipurpose project.

But I'm new here and surely there are a lot of more experienced people to discuss this 😅

[peterbarker]

@guglie It's an interesting problem, actually.

With this fine-grained control, GCSs may be tempted to implement a policy of setting things up exactly right for them. For example, if they see a message they don't want, they send back a message setting the interval for that message to 0. If they're not seeing a message at the rate they want, they send a message changing the interval.

For this reason I think we need to allow specification of rates for all the messages that we stream. At the moment the code initialises those rates from the Stream Rates.

Going to be fun watching various bits of equipment stop working (e.g. OSDs....) because a GCS has decided that it really doesn't need a message that the OSD does and turns that message off...

[guglie]

Just reporting,
here are some interesting issues discussed by @peterbarker and @OXINARF:

The chief one is priority; with the streams stuff we currently have we (apparently not according to the original design!) drop further streams when we hit gcs_out_of_time stuff.

I would say it would have to be different, no deferred messages, it either can send it when it is time or it can't. I know this can bring an issue of never sending a message, but I think the SET_MESSAGE_INTERVAL message puts that responsibility even more in the hands of the GCS/user.

The other problem that occured to me is precision; microsecond resolution is a little over-the-top and may complicate implementation

Yes, I agree. But I think the idea is that over a period of time the average interval is of that milliseconds - so if you are late sending, you schedule it to send again like you were on time. Regarding the minimum interval, I think we can reject the command if it has an interval smaller than what we are capable of doing.

And these are two requirements discussed in the dev call:

• Need to preserve stream rate adjustments based on radio status
• Should be able to do this with very little memory consumed

[WickedShell]

This has been done, and the issue was just never closed.