Forward USV Messages To Spotter

[matt001k]

What changed?

Forwards messages of interest from Bristlemouth MAVLink integration to the network co-processor (in this case Sofar Ocean's Spotter).

Makes sure both parts of the message exist before packaging it to be sent to Spotter, will timeout if only part of the 2 messages are sent.

How does it make Bristlemouth better?

Bridges USV integration into Bristlemouth! 😉

Where should reviewers focus?

Because the Ardupilot flight controller publishes all Mavlink messages at a default rate of 1Hz, the two messages of interest would arrive at the same time. But these publishing rates can vary depending on how the flight controller is configured for each of these messages, which has me concerned. So my question is:

Should the bm_serial message be broken up into two separate messages, one for each of the MAVLink messages

• It would be nice to keep this as a single message to prevent adding more messages to bm_serial

• Maybe the struct for the bm_serial message can look like:

  typedef struct {
    bool has_imu;
    bool has_power_control;
    struct {
      // USV realtime accelerometer readings
      int16_t xacc;
      int16_t yacc;
      int16_t zacc;
      // USV realtime gyroscope readings
      int16_t xgyro;
      int16_t ygyro;
      int16_t zgyro;
      // USV realtime magnetometer readings
      int16_t xmag;
      int16_t ymag;
      int16_t zmag;
    } imu;
    struct {
      // USV speed
      float groundspeed;
      // USV engine throttle
      uint16_t throttle;
    } power_control;
  } __attribute__((packed)) bm_serial_usv_metrics_t;

  And the timeout can be used to determine when to send the message, i.e. if the second part does not arrive.
  Would love feedback on thoughts around this!

  (edit: I have went through and implemented the above)

Checklist

• Add or update unit tests for changed code
• Ensure all submodules up to date. If this PR relies on changes in submodules, merge those PRs first, then point this PR at/after the merge commit
• Ensure code is formatted correctly with clang-format. If there are large formatting changes, they should happen in a separate whitespace-only commit on this PR after all approvals.

[towynlin]

What's the semaphore guarding? Right now it's not used anywhere other than here, so a new message could come in and be in the middle of a write to ctx.metrics while you're sending. Do you want to add it to the write side in package_and_send_usv_metrics?

[matt001k]

This function may be called from the RTOS timer thread (from metrics_timer_cb), or in the middleware task (package_and_send_usv_metrics) this is protecting the ctx.metrics variable.

Yes! This mutex also has to protect ctx.metrics when they are being assigned in package_and_send_usv_metrics, which it is not right now. I will add that in.

[victorsowa12]

Looks good to me! I think this is a good approach! If we miss either part we will still send the data so decisions can be made upstream based on partial data.