Big picture Goal

To give each worker the ability to send [MAVLink] messages to the ground station. This is for enhanced debugging, information, and more.

Objectives

• Architecture: How do the messages get sent between workers?

• Architecture: What do these messages look like? What do they contain? etc.

• Architecture/Implementation: Message sending protocol: How do we send these messages?

What should a message look like?

• A Universal “Message Class” that we send to Flight Interface Worker

  • a string field – DEBUG MESSAGE → For Mission Planner output (empty means don’t print to mission planner’s output)

  • enum/int (0-7) – SEVERITY → Indicate how severe this message is

  • Worker class? – ID → for who sent this message

  • date time field? – TIMESTAMP → When this message was sent

  • Object field – DATA → supporting sending any object

Flight Interface Worker: How to receive messages from other workers?

• Have 1 “Message Queue” shared by all workers

  • All workers place messages into Message Queue

  • Flight Interface Worker takes messages from Message Queue

  • NOTE: Message Queue must be large enough to handle many incoming sources

  • But easier to manage than each worker having its own message queue

Implementation details

MAVLink messages that work (from drone to ground station)

• MEMORY_VECT (249) – Untested: Sends raw controller memory (reads pixhawk’s memory)

• DEBUG_VECT (250) – Sends 3 floats (32bit) + 1 unsigned long (64bit)

• NAMED_VALUE_FLOAT (251) – Sends 1 float (32bit)

• NAMED_VALUE_INT (252) – Sends 1 int (32bit)

• STATUSTEXT (253) – Sends 1 C string (without null terminator)

• DEBUG (254) – Untested: Sends 1 int (8bit) and 1 float

• MAX Message rate is 10Hz (For STATUSTEXT)

How to convert from “Message Class” to MAVLink messages?

Message class field mappings

Don’t need to be separated into many packets:

• SEVERITY → NAMED_VALUE_INT: and also embedded in STATUSTEXT if needed

• ID → NAMED_VALUE_INT: enum (similar to common repo’s worker enum)

• TIMESTAMP → NAMED_VALUE_FLOAT: send Unix/POSIX timestamp in UTC (aka use time.time())

Will need to be separated into many packets:

• DEBUG MESSAGE → STATUSTEXT: or multiple STATUSTEXTs if required

• DATA → DEBUG_VECT: first, pickle the object into bytes, then send over DEBUG_VECT, then reconstruct object with pickle again.

Extra data per packet / per MAVLink message

• MESSAGE ID → Which Message Class does this MAVLink message correspond to?

• PACKET ORDER ID → For data fields that need to be separated into many packets, which one is this?

Message sending order

• TODO: Discuss later exact ordering of MAVLink messages to be sent, and maybe how many MAVLink messages need to be sent

• Basic idea: sender sends a thing

• Reciever gets it

• Reciever sends a message saying I got it

• Repeat (sender sends next thing)

• If sender doesn’t get anything back in a long time, send it again (up to N tries, before saying failed, connection died)