The CKCM log format turned out to be documented in a file deleted from
Parrot's ulog repository in 2017, so it is cited rather than claimed as
reverse engineering, with four points the capture settled that the source
leaves open or states wrongly.
The COMMANDS tag is deliberately NOT resolved to protocol commands: measured,
only 4 of 11 symbols match the XML by name, covering 3.5% of the tag, and a
resolver would read as authoritative while guessing, with its silence on the
rest reading as 'not a command'.
Tested on the aircraft. A second ARSDK handshake is accepted and telemetry is
redirected to it; the first session's frames stop while it still reports
connected = True. So the claim inherited from pyparrot's error text, which had
reached our error messages, tool descriptions, simulator behaviour and a test
name, was wrong in the most misleading direction: a refusal would be loud, and
this is silent.
The simulator now models the takeover by default; refusal stays available
because a client must handle a non-zero status anyway.
15 commands go on the unacknowledged buffer, so acked=false is their normal
outcome rather than a failure. Reporting it bare made a working camera move
look broken; the note now says to confirm with get_state instead.
list_dir and fetch take a name and resolve it themselves; the tools layer
resolved it first and handed over the object, so every call failed with
'No FTP area named Area(...)'. Found by calling the tool for real.
Acknowledge on data type alone, never on buffer id. A live Bebop 2 sends
DATA_WITH_ACK on buffer 126 and plain DATA on 127, the opposite of what the
buffer names imply, so requiring both to agree meant nothing was ever
acknowledged. The drone resent its state instead of continuing: 35 telemetry
keys where there should be 192, and a connect that took 4 s instead of 1.7.
Record argument-less events. Eight events carry no arguments and their
arrival is the whole message, including AllStatesChanged and
AllSettingsChanged, which mark the end of a state dump. Keying only by
argument decoded them to an empty dict and lost them.
Wait for those terminators instead of a quiet period. The drone streams
attitude at about 5 Hz throughout, so the link is never quiet and the wait
always ran to its timeout with a partial burst.
Also: preflight no longer reports ready when a blocking check has no data.
It answered 'ready' on an aircraft it knew almost nothing about, which is
worse than refusing to answer.
Ryan Malloy