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 (Auto-populated when message instance is created)

  • 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) = 20 bytes

• 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?

  • No need for this since we only send 1 MAVLink message (packet) at a time, thus ordering is kept and we can determine which message it belongs to through the order and the below defined protocol.

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

  • No need for this since we only have 1 queue and send only 1 MAVLink message (packet) at a time, thus ordering is kept and there is no need to track/reconstruct the correct order.

• MESSAGE SENDER ID → To determine whether we (the RPi) sent the message or if it was a system message sent by the Pixhawk or some other process.

Message sending order

Some Rules:

• (For accuracy/reliability over speed) For each MAVLink message sent, we will require ground station to send a message back saying it received it (A NAMED_VALUE_INT as acknowledgement). If not received after MAX_WAIT seconds, then try again up to MAX_RESENDS amount of times. After that, error out saying connection lost.

  • Have a “send” function that takes care of all of this

  • Have a “receive” function that sends a NAMED_VALUE_INT with value TRUE or whatever back after it receives

• Sender (Airside) has a 16-bit ID (0-65,536), Reciever (Groundside) has a different 16-bit id (0-65,536) which are to be put into the name field as a string to each message.

  • Implement this as part of the “send” function

  • Implement this as part of the “receive” function

Protocol (Assuming the “rules” above are implemented and done in between these steps)

1. Send ID (which worker sent this message) in a NAMED_VALUE_INT

2. Send SEVERITY in NAMED_VALUE_INT

3. Send TIMESTAMP in NAMED_VALUE_FLOAT

4. Send number of STATUSTEXT messages needed (for DEBUG MESSAGE)

5. Send all of the STATUSTEXT messages

   1. Set id to the airside’s “password”, something non-zero

   2. Set chunk_seq to be increasing starting from 1

   3. Make sure the last chunk has a '\0' terminator at the end of the string/data

6. Send number of DEBUG_VECT messages needed

7. Send all of the DEBUG_VECT messages

   1. All of time_usec, x, y, z to be used as data, in that order. 20 bytes total (8, 4, 4, 4)