SERIALX_OPTIONS - Don’t forward mavlink to/from

[lthall]

SERIALX_OPTIONS - Don’t forward mavlink to/from is intended to:

• prevent mavlink messages from all sources other than the autopilot from being sent to this port and
• messages entering this port from being sent anywhere other than the autopilot.

The change here:

https://github.com/ArduPilot/ardupilot/pull/14742

is intended to prevent messages entering a serial port from being sent to all other ports and using up bandwidth.

The unintended consequence of this PR is it also prevents the autopilot from sending any debug or text messages to this port.

[khancyr]

Hello,

On which hardware and which port did you get the issue ? I can test this quickly, but from memory I didn't had this issue at least on 4.1 serie

[WickedShell]

@khancyr stuff like this: https://github.com/ArduPilot/ardupilot/blob/17ad710866b0e72aedb760051330ee1cc0114503/libraries/GCS_MAVLink/GCS.cpp#L97 will pretty clearly break it, and is old.

I've been having some discussions with @peterbarker and it's a bit messy because there's actually two scenarios that we really want to handle here, one is don't forward to/from or volunteer to send anything to the port because it's a waste of time (IE an ADS-B in receiver), then there's the case of here's a full MAVLink port, just don't forward anything, which is the case that Leonard's trying to handle above. I suspect we may actually need a new option, where we have private ports as the former, and no forwarding ports as the latter. We have a bunch of code that currently only does the former scenario at the moment.

[lthall]

On which hardware and which port did you get the issue ?

Peter was able to reproduce this in SITL so this behaviour is on all boards.

there's actually two scenarios that we really want to handle here, one is don't forward to/from or volunteer to send anything to the port because it's a waste of time

If you take this approach then you would use different settings for each device because a solo gimbal doesn't need the same information as a ADS-B receiver.

I think this is really simple. This bit stops text messages being sent to the port, not just forwarded from other ports. As far as I know there is no problem with text based messages being sent from the autopilot.

[WickedShell]

If you take this approach then you would use different settings for each device because a solo gimbal doesn't need the same information as a ADS-B receiver.

I imagine this scenario turns into don't send anything except what we have a programmatic driver to send. This is actually what the solo gimbal driver does already. It programmatically sends out the messages it cares about without sending out everything we send to a MAVLink stream.

I think this is really simple. This bit stops text messages being sent to the port, not just forwarded from other ports. As far as I know there is no problem with text based messages being sent from the autopilot.

It's not just text messages though, it's also param changes, avoidance, airspeed cal, and I'd believe it also disables a bunch of other things.

[lthall]

My understanding is that the only problem with the solo gimbal was messages coming from other sources, not the autopilot. So as far as I know we don't have a situation where we need an option other than the "don't forward to/from", we just need that to do what it says on the box.

Am I missing something here?

[WickedShell]

Am I missing something here?

The general desire I have to not send any more data then we have to is driven by just saving processing time (and DMA bandwidth) from a link where I know it won't help. IE with a PingRX sending it anything is a waste of processing time. None of this matters as much on the newer flight controllers, but on older hardware it definitely helps.

[lthall]

I can see the justification of minimising bandwidth but we can't do that for a generic output because we can't assume what data the consumer wants and does not want.

If a solo gimbal or a PingRX has it's own drivers or custom settings that could be used to turn specific messages on or off but not for a generic consumer.

Ok, so my understanding so far is that we don't have any reason (other than to limit bandwidth) to disable any messages from the autopilot when we turn on "Don’t forward mavlink to/from".

Is that right?

[WickedShell]

Ok, so my understanding so far is that we don't have any reason (other than to limit bandwidth) to disable any messages from the autopilot when we turn on "Don’t forward mavlink to/from".

Is that right?

I don't know if on the SoloGimbal had issues with any of the normal autopilot messages or not. At this point we probably need someone to actually test it, because I haven't heard anyone really know at this point. I've heard some suspicions that it does and some that it doesn't matter.

I also think there's a slight complication that's being overlooked on saying just that it's less bandwidth. Crucially less bandwidth means more CPU time for working on the other MAVLink channels (very relevant for quadplanes and copters that are running at 300Hz or faster on Cortex-M4's). It also means not taking up time from serial DMA channels that doesn't matter (much less of a pain point then it used to be).

Finally it can help external devices spend less time and ensure that we have the bandwidth we need for the dedicated messages (such as solo gimbal), but frankly I think that is more okay to push towards needing other devices to have enough CPU to keep up.