Peter Barker

This PR is against a repository which contains generated commits; it should be against the generator instead. One issue with that patch is that I don't believe we currently have...

Well, they're all wrong, unless you're still on EKF2 :-)

On Thu, 11 Aug 2022, Hamish Willee wrote: > Therefore this adds extension fields for target_system and target_component, which allows robust determination of the intended recipient, and timesyncing to specific...

ArduPilot's treatment of these messages differs based on vehicle type, with varying degrees of support. `SET_POSITION_TARGET_*` and `POSITION_TARGET_*` are essentially orthogonal. The vehicle having received `SET_POSITION_TARGET` does not necessarily mean...

On Mon, 19 Aug 2019, Don Gagne wrote: > a command then you should use a COMMAND_LONG/INT variant which has ack capability built in. In the specific case of SET_POSITION_TARGET...

On Mon, 19 Aug 2019, Don Gagne wrote: > FYI: All of which explains in more gory detail my request for ArduPilot to support MAV_CMD_DO_REPOSITION. It does in Plane :-)

On Mon, 19 Aug 2019, Edwin Hayes wrote: > @DonLakeFlyer - MAV_CMD_DO_REPOSITION is only good for WGS84 frame; AFAIK there are no equivalents for other frames (for instance, local)? Bleh....

This is a repository for generated code only; actual repository is pymavlink for this stuff. Bug was fixed long ago.

https://docs.typo3.org/typo3cms/extensions/sphinx/2.5.1/AdvancedUsersManual/RenderingPdf/Index.html

I've created https://github.com/ArduPilot/ardupilot/pull/15331 to validate and correct the `@User` field. I've created https://github.com/ArduPilot/ardupilot/pull/15330 to canonicalise the @Values field before attempting to validate it and further parse it in the various...