Scripting/GCS_MAVLink: scripts may receive corrupted mavlink messages

[rmackay9]

During preparations for this's years' Japan Innovation Challenge (JIC) we noticed that the copter-slung-payload.lua script (running on a CubeOrangePlus running AP-4.7.0-dev) could receive corrupted GLOBAL_POSITION_INT messages with impossible lat, lon and alt values from a Here4 (running Copter-4.6).

The result was at best the script would fail with this error:

Lua: /APM/scripts/copter-slung-payload.lua:185: bad argument #1 to 'alt' (out of range)

.. but even worse, in some situations the values were within range but crazy leading to unexpected copter movements.

This issue only occurred when the telemetry connection was overloaded. In this situations Mission Planner's mavlink connection would show the GLOBAL_POSITION_INT updates from the payload were slower than the configured 10hz rate which suggests to me that Mission Planner was rejecting the corrupt messages while the AP script was being fed the corrupted messages

[IamPete1]

This is done explicitly here:

ardupilot/libraries/GCS_MAVLink/GCS_Common.cpp

Lines 1974 to 1980 in ae038a5

	else if (framing == MAVLINK_FRAMING_BAD_CRC) {
	// This may be a valid message that we don't know the crc extra for, pass it to scripting which might
	AP_Scripting *scripting = AP_Scripting::get_singleton();
	if (scripting != nullptr) {
	scripting->handle_message(msg, chan);
	}
	}

The goal was to allow unknown messages to be used in scripting. The intention was that the Lua MAVLink parser would check the CRC, but that has never been added.

[IamPete1]

I looked at the blame, it was me. I actually did add support to checking the crc in lua. ArduPilot/pymavlink#983

I think we just need to update the parser which is in tree to a freshly generated one.

Edit: in fact the parser is up to date, we just need to update the message definitions to provide the crc extra.