Migrate all content from mavlink.org with warnings

[hamishwillee]

The content on mavlink.org is of unknown quality. I have been unable to get support with reviewing it and determining quality.

Plan is to import all the content and add a disclaimer that it is unverified/may be out of date/needs checking. I may also group it all in a folder that reflects that status.

Also will delete anything I am able to identify as not useful or already ported.

General:

• Update top header bar so goes to correct new sites.

List of all remaining docs (checked means "dealt with")

• MAVLink Micro Air Vehicle Communication Protocol (Start page)
• Dev entry point http://qgroundcontrol.org/dev/start
• http://qgroundcontrol.org/users/joystick Joysticks
• http://qgroundcontrol.org/mavlink/crc_extra_calculation -
• http://qgroundcontrol.org/playground/playground -
• http://qgroundcontrol.org/mavlink/mavproxy_startpage
• Legacy user guide entry point (http://qgroundcontrol.org/users/start)
• http://qgroundcontrol.org/users/record_qgroundcontrol
• http://qgroundcontrol.org/users/matlab_import
• http://qgroundcontrol.org/users/models
• MAVLink File Transfer Protocol (FTP)
• Image Transmission Protocol
• Control Interface
• Create a new MAVLink Message
• MAVLink Generator (C/C++, Python)
• Downloading / Installing MAVLink
• MAVLink Mission Interface
• MAVLink Mission Library (missionlib)
• MAVLink Packaging
• Parameter Protocol
• MAVLink v0.9 to v1.0 Porting Guide
• MAVLink Python Bindings
• MAVLink Release 1.1 Compatibility and Features
• Waypoint Protocol

[mrpollo]

To be clear, by "unknown quality" you mean we aren't sure if the messages are being used and if the intention for such messages is unclear or undefined.

Another option would be to mark the parts we have support for in PX4 or APM (or any other consumer) it's a good idea because instead of focusing on what we don't know we are promoting the good parts, e.g.:

Message	Supported in
MAV_MISSION_TYPE_MISSION	PX4, APM
RANDOM_MAV_MSG_ONLYFOUND_IN_PX4	PX4
RANDOM_MAV_MESSAGE	(unknown support, we don't list PX4 as supported)

[hamishwillee]

No, to be clear the documentation I am referring too has little or nothing to do with messages. It is documentation about the protocol that was written a long time ago and that was not migrated. It may no longer be accurate or useful - no one knows.

[hamishwillee]

Another option would be to mark the parts we have support for in PX4 or APM (or any other consumer) it's a good idea because instead of focusing on what we don't know we are promoting the good parts, e.g.:

Yes, it would be good to mark supported messages by autopilot, but IMO that would best be added in the message xml somehow. @julianoes Is there any way to add autopilot support to the mavlink message format like a "comment" so that it will be ignored by toolchain(s) but can be picked up by docs toolchains?

[hamishwillee]

Today did the following updates:

• Remove http://qgroundcontrol.org/mavlink/crc_extra_calculation (already migrated)
• Remove http://qgroundcontrol.org/playground/playground - not needed
• Remove http://qgroundcontrol.org/mavlink/mavproxy_startpage - not needed on new site (fixed up link on home page to point to mavproxy site.)
• Updated start page (http://qgroundcontrol.org/start) to also point to mavlink.io entry point
• Updated top header bar so goes to correct new sites.
• Deleted unused dev entry point: http://qgroundcontrol.org/dev/start
• Removed http://qgroundcontrol.org/users/joystick -> already migrated to https://docs.qgroundcontrol.com/en/SetupView/Joystick.html#logitech-f710-gamepad
• Remove legacy user guide entry point (http://qgroundcontrol.org/users/start) - no longer needed now top links go to right place.
• Remove http://qgroundcontrol.org/users/record_qgroundcontrol (how to record QGC using generic screen tools. Note specific enough to be worth keeping.)
• Removed http://qgroundcontrol.org/users/matlab_import - the log format listed not supported.
• Removed http://qgroundcontrol.org/users/models - this list no longer used as place where models are imported from.

[julianoes]

@hamishwillee the problem with documenting if something is supported by the Firmware is that some messages and commands are partially supported. E.g. only some params of a command are supported such as a coordinate frame.

[hamishwillee]

@hamishwillee the problem with documenting if something is supported by the Firmware is that some messages and commands are partially supported. E.g. only some params of a command are supported such as a coordinate frame.

@julianoes True. For or ardupilot I did this manually and re-documented every single (cursed) MAV_CMD_ showing what was supported and not supported. Do not want to go there again!

We could do this by allowing an attribute to be added to any xml tag that takes some accepted values. So supported="px4-full, apm-partial"
Then for this say:

      <entry value="176" name="MAV_CMD_DO_SET_MODE" supported="px4-full, apm-partial">
        <description>Set system mode.</description>
        <param index="1">Mode, as defined by ENUM MAV_MODE</param>
        <param index="2" supported="apm-not">Custom mode - this is system specific, please refer to the individual autopilot specifications for details.</param>
...

Alternatively maybe a support tag and just have a description.

      <entry value="176" name="MAV_CMD_DO_SET_MODE">
        <description>Set system mode.</description>
        <supported stack="px4">Full Support.</supported>
        <supported stack="apm">Partial support - does not support X, Y, Z params</supported>
        <param index="1">Mode, as defined by ENUM MAV_MODE</param>
        <param index="2">Custom mode - this is system specific, please refer to the individual autopilot specifications for details.</param>
...

@mrpollo Any other suggestions? This is not easy!

[julianoes]

I think the support flags should live in the Firmware repo though, otherwise they'll be out of date, always.

[hamishwillee]

True. This discussion has hijacked this issue. I've spawned it off to #39 so it doesn't get lost, but I think possibly a too big problem/non priority for tackling right now

[julianoes]

My answer to share what is compatible is DroneCore 😄

[hamishwillee]

Everything migrated of interest. Closing this now.