Convert strings to unicode before passing to pymavlink

[peterbarker]

Avoid the need to specify the encoding of a string when using the message command by simply converting any passed-in-string to bytes before passing to pymavlink

This fixes the same problem as in ArduPilot/pymavlink#1225

This is basically, "give pymavlink what it wants", which is unicode.

[tridge]

Automated review note — AI-generated (Claude), validated against the live diff. Please sanity-check before acting.
Full report: https://uav.tridgell.net/DevCallReviews/2026_09_01_AIReview/devcall_pr_reviews.html#prMAVProxy-1703

Reviewed at head 2e843dcdef. COMMENT — the change itself is correct; it's the coverage that's incomplete.

Verified correct: the direction matches pymavlink's contract (it now annotates these parameters text: bytes), the isinstance(..., str) test makes double-encoding impossible since bytes pass through untouched, and indexing fieldtypes positionally is right.

Four sibling call sites raise TypeError today and aren't fixed here. Confirmed against pymavlink 2.4.49 — MAVLink_statustext_message.__init__ does text.split(b"\x00", 1), so a str raises TypeError: must be str or None, not bytes (a confusing message; it's the str.split(bytes) failing). I ran it, and read each call site at this head:

• mavproxy_park.py:92
• mavproxy_movinghome.py:153
• mavproxy_smartcamera/__init__.py:143 and :151

movinghome is doubly broken — line 152 is message2.encode(bytes), which raises TypeError: encode() argument 'encoding' must be str, not type before the send is even reached, and its result is unused anyway. Both of my review passes independently landed on the same four, so I'm fairly confident that's the complete remaining set.

Two notes. Encoded text is truncated at the field width by struct.Struct("<B50sHB") without error, so multi-byte text can be cut mid-codepoint and fail to decode on the wire — not introduced here, but the message command makes it reachable from arbitrary user input. And a trap for anyone extending that loop: fieldtypes is in declaration order (which is why indexing it with i is correct), but array_lengths is in wire order — PARAM_SET has array_lengths = [0,0,0,16,0] with param_id at fieldnames index 2 — so a length check must not reuse the same index. Might be worth a comment.