Mission protocol extension: Start by adding a receive example

[LorenzMeier]

@DonLakeFlyer This allows to extend the complete mission protocol according to your proposal. You can run this against QGC on your Mac by running:

make posix jmavsim

It should lend itself as a pretty good reference implementation as its self-contained.

[LorenzMeier]

@DonLakeFlyer Any updates on this?

[DonLakeFlyer]

Gonna be a while before I get to this. Wrapping up 3.1 right now so mostly bug fixes and missing existing features. On Dec 9, 2016, at 11:15 AM, Lorenz Meier <[email protected]<mailto:[email protected]>> wrote: @DonLakeFlyer<https://github.com/DonLakeFlyer> Any updates on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#5779 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFmsc354kqspv1RL-otxQJscaa36hr-kks5rGajcgaJpZM4KkcrH>.

[LorenzMeier]

@DonLakeFlyer Our need for this is getting very quickly much more urgent. Any chance to have a look at this in the next days?

[DonLakeFlyer]

Still closing down 3.1 fixes/changes.

[LorenzMeier]

@DonLakeFlyer This would also benefit from running at higher priority.

[DonLakeFlyer]

I don't get how this code is supposed to work:

		unsigned mission_type = 0;
		bool write_failed = false;

		dm_item_t dm_item;

		switch (mission_type) {

mission_type is always 0. Where is mission_type supposed to come from to get it to write fence or rally points?

[DonLakeFlyer]

Also what am I supposed to write for a rally/fence point? The current FENCE_POINT and RALLY_POINT items are ardupilot dialect only.

[dagar]

Trying to remember what we discussed here, but I think mission_type would be a field added to the existing mavlink MISSION messages.

[DonLakeFlyer]

If that's the case then it's going to need to be coordinated with ArduPilot folks unless it can be changed in a way that doesn't affect them.

[dagar]

@LorenzMeier should respond with what he intended, but wouldn't it work if mission_type was an extended field (mavlink v2)? Mavlink v1 would default to the current behaviour only allowing you to sync regular waypoints.

[DonLakeFlyer]

I'm quite confused by the current state of mavlink 2. As far as I know it won't work with the current SiK Radio firmware and it won't work with the current WiFi firmware. Hence I don't see how anyone is actually using Mav 2? So if this is mavlink 2 only, i don't see how anyone gets the feature?

[magicrub]

This commit here looks like MAVLink2 was added to SiK radios in May 2016
ArduPilot/SiK@3e4f55d

[DonLakeFlyer]

I was having a discussion with tridge on how to implement mav 2 with respect to the capability bit where this radio thing came up. Maybe he was concerned about the fact that most radios wouldn't have updated firmware as opposed to it not being possible.

[LorenzMeier]

Don, this is an example. I think you lost all the context from your own proposal, do. let me bring it back to you:

• You proposed to add Fence and Rallye into the current mission setup by either including a separator item or by choosing an appropriate MAV_FRAME id (the latter seems better suited)
• the same can be done for planned home to disambiguate it from a waypoint
• we would add a MAV_CAPABILITIES flag to indicate support for this

On the MAVLink 2 front: Anything that is not legacy is using it. Or in other words: Anybody actively contributing in APM or PX4 needs it and might even already depend on it.

[DonLakeFlyer]

I get that. But I was kind of expecting some sort of implementation of that. I'm not going to have time to implement the firmware side as well. Also if it's going to be a new thing then we need to discuss across with ArduPilot folks as well for common usage.

Two options:

1. Move fast: Just implement to ArduPilot spec and move messages to common. Then move to Step 2.
2. Move slower: Discuss/Design new thing.

[DonLakeFlyer]

It's going to be harder for me to complete a #2 discussion/implementation in the next couple weeks. Since I'm currently sitting in the back of my van in the Florida Keys I have very limited discussion bandwidth. But I still do have decent coding bandwidth.

[dagar]

@DonLakeFlyer if you wanted to pursue mavlink/mavlink#626 it wouldn't take much more work to make this PR functional. I could help on the firmware side if it would unblock you.

Previous discussions for reference.
mavlink/mavlink#626
mavlink/mavlink#617

[DonLakeFlyer]

@dagar Yeah this would be good. If everyone is ok with it waiting about a week to re-kick this discussion to completion. I can't really respond until I get home and get more bandwidth.

[dagar]

Superseded by #6888