iNavFlight
Add Guided mode handling to Mavlink telemetry
This PR adds a simple check for BOXGCSNAV in the mavlink mode mapping switch caes to either return GUIDED if GCS NAV is active or LOITER if not, i tested it working using X-plane HITL.
I think a fundamental decision needs to be made about the mavlink integration. You can choose to pretend to be an ArduPlane. The current mavlink implementation basically already does that, by the mode mapping. It's the quickest (and dirtiest) way to mavlink functionality.
However I think the 'proper' thing to do, is to stick as much as possible to the generic protocol. The generic protocol also supports "custom_mode", which is something autopilot-specific. The mavlink common dialect should add type MAV_AUTOPILOT_INAV (like there are constants for every other type of firmware). The ground station software should then handle the custom modes accordingly.
However this is significantly more work of course, because it requires work on the mavlink protocol and the ground station software. Personally I don't really mind mimicking ArduPlane for the time being, but it would be nice to kick off some efforts into supporting INAV properly.
It depends on the overhead on the flight controller. There is only a small amount of space. IMHO, INAV is not a MAVLink platform. It is an MSP platform. The right solution would be MSP GCS. Space is much more abundant on computers. MVPTools is an option.
You raise an interesting point. It made me look up the design choices for MSP, which includes this statement:
I thought first about an implementation of Mavlink, but I think it's not what I was looking for. Even with a partial implementation, the predefined structures are not light enough for what I have in mind. Some messages are however inspired from mavlink structure.
Mavlink is still very tempting though, especially because of the compatibility, all the tools, ground stations and things like mLRS.
If Mavlink is really desired, perhaps it's "better" to run a protocol translator on the computer. Except that you can't use mLRS in that case, so we would need "mspLRS" too.
INAV is not aiming at providing feature parity between MSP and Mavlink and will remain a MSP first platform for the time being.
I have no issues with this change, but overall expectations need to be aligned.
Using Mavlink will not magically turn INAV into ArduPilot or PX4 and you certainly should not expect INAV to care about random Mavlink messages or to be able to setup INAV from scratch using Mavlink.
to be able to setup INAV from scratch using Mavlink
I think that's a useful distinction. Setup / configuration vs flight. There's no need to do configuration via Mavlink. I didn't think there's a need to substitute for INAV Configurator.
That significantly reduces the number of messages that matter.
Except that you can't use mLRS in that case, so we would need "mspLRS" too.
I think mLRS already supports MSP, i've seen people talking about using it (i don't have mLRS hardware yet), in any case it's in active development and if it doesn't fully support it stable it will soon enough so that's a plus.
to be able to setup INAV from scratch using Mavlink
I think that's a useful distinction. Setup / configuration vs flight. There's no need to do configuration via Mavlink. I didn't think there's a need to substitute for INAV Configurator.
That significantly reduces the number of messages that matter.
Configuring INAV with Mission Planner? Good lord, no. The configurator is one of the best things about INAV. We only have to look at the flight related messages of Mavlink, which does cut down immensely on the number of things that need to be implemented and is actually quite manageable and won't take up that much space. INAV will always be configured with MSP (thank god), when people talk about Mavlink support they almost exclusively mean telemetry, control and missions.
Full feature parity with Mavlink is not something that can, or should, be contemplated.
@bartslinger
I think the 'proper' thing to do, is to stick as much as possible to the generic protocol. ... MAV_AUTOPILOT_INAV
I'm not that familiar with Mavlink and surrounding topics.
We do want to decide on an overall strategy / plan, and I think we're slowly working toward that. Does this PR need something like MAV_AUTOPILOT_INAV, or would this specific field in this particular message be the same anyway? In other words, does this particular field match up closely between INAV and Ardupilot anyway? If we can dispose of this PR without committing one way or the other on the larger plan, perhaps we can do that.
My wording may sound like I'm suggesting an answer to the question, suggesting that we can merge this PR without deciding the bigger questions. I don't mean for it to sound like that; I absolutely don't know. I am truly asking because I don't know.
This change does not require a change to the MAV type/dialect per se, it will work as is and will just reflect a more accurate mode. Actually handling guided mode commands is more involved and is detailed here #10426 and my fork branch and is where a decision will have to be made regarding a new inav dialect or skinwalking as ardupilot.
Sorry, it's been a while since I last looked into this. Since multiple people mention that INAV is an MSP-first flight controller, which makes sense, I wouldn't bother too much about creating a custom mavlink dialect. I would only do that when striving for complete mavlink compatibility/integration. Relatively small/simple changes like proposed here by @xznhj8129 can make INAV more usable for those that want to run a Mavlink GCS.