Create development.xml and seed with MISSION_CHECKSUM

[hamishwillee]

Fixes #1172
Replaces #1172

Under the new governance model xml definitions don't get accepted into standard set until they have been prototyped on one flight stack and at least one other key stakeholder stacks have agreed to implement them. To ease development this PR creates development.xml (includes standard.xml) and imports it into all.xml. This is where proposals to the standard set should be added before being implemented and proposed.

In addition, this adds the MISSION_CHECKSUM message which was agreed in #1172.

As discussed in devcall - @auturgy @LorenzMeier @julianoes
FYI @IamPete1 @holmnikolaj @amilcarlucas

[hamishwillee]

Self merging, as agreed by the dev call.

[peterbarker]

I don't suppose there's a sample QGC WPL file around with an expected checksum?

[hamishwillee]

@peterbarker Not as far as I know - is the description not sufficient/ambiguous - or do you just want to check this?

• The checksum uses the same CRC32 algorithm as MAVLink FTP (https://mavlink.io/en/services/ftp.html#crc32-implementation).
• It is run over each item in the plan in seq order (excluding the home location if present in the plan)
• It covers the following fields (in order): frame, command, autocontinue, param1, param2, param3, param4, param5, param6, param7.

@holmnikolaj @DonLakeFlyer have you looked at implementing this for PX4 yet?

[peterbarker]

On Tue, 4 May 2021, Hamish Willee wrote: @peterbarker Not as far as I know - is the description not sufficient/ambiguous - or do you just want to check this?

Description seemed clear enough to me, but really wanted a separate check that an implementation was correct according to spec.

[hamishwillee]

Description seemed clear enough to me, but really wanted a separate check that an implementation was correct according to spec.

Fair enough. I would want that too. I'm hoping @holmnikolaj say he's working on the QGC implementation too - that would give us a baseline that both ArduPilot and PX4 could be compliant with in this respect.

[holmnikolaj]

Fair enough. I would want that too. I'm hoping @holmnikolaj say he's working on the QGC implementation too - that would give us a baseline that both ArduPilot and PX4 could be compliant with in this respect.

I don't. At Sky-Watch we use our own drone manager: https://sky-watch.com/products-services/software/

[peterbarker]

On Tue, 4 May 2021, Nikolaj Holm wrote: Fair enough. I would want that too. I'm hoping @holmnikolaj say he's working on the QGC implementation too - that would give us a baseline that both ArduPilot and PX4 could be compliant with in this respect. I don't. At Sky-Watch we use our own drone manager: https://sky-watch.com/products-services/software/

Sweet. So if I were to get it wrong that would still be canonically correct ;-)

[hamishwillee]

Sweet. So if I were to get it wrong that would still be canonically correct ;-)

Sadly, yes, provided you use the documented algorithm and crc :-(. If discover any ambiguity as you implement let me know and I'll update the docs to match what you did.

Are you planning on doing the implementation in QGC and/or Mission Planner, and do you have an ETA? If you're targeting QGC then I can try get a parallel PX4-side done at the same time.

[peterbarker]

@hamishwillee I have no intention of making patches to either of MissionPlanner or QGC at this time.

I do intend to do a MAVProxy implementation - non-trivial as I couldn't find the equivalent CRC algorithm in the pymavlink Python bindings so far.

My PR against ArduPilot (https://github.com/ArduPilot/ardupilot/pull/17370/files) contains checksums for 4 different missions, the QGC WP files also being present in the PR.

[peterbarker]

Oh, I should note that in that PR I copied the message definition over to common.xml - that was pure laziness on my part as I didn't want to work out how to include the development messages into our process at this point.