2023-02-16 - ZP-Jetson Communication Robustness

Change Description <Filled out by requestor>

Description of Change

Increase the robustness of ZP-Jetson communication by adding IDs to messages.

Implementation

Message format changes:

• Movement request (type 1):

  • Change request to ID [uint8_t] integer

• Relative Movement Command (type 2):

  • Add ID [uint8_t] integer

• Landing Initiation Command (type 3):

  • Change request to ID [uint8_t] integer

Relevant documentation: Communication & Message Formats

Communication changes:

• ZP is the master device and Jetson is the slave device. Therefore, Jetson does not time out waiting for ZP messages.

• ZP sends Movement request (type 1) with ID of either 0, 1, or 2. Jetson responds with Relative Movement Command (type 2) or Landing Initiation Command (type 3) with the same ID.

  • Movement request ID starts at 0. This indicates to Jetson to discard any previous search work, allowing resets.

  • Movement request ID then alternate between 1 and 2. This allows ZP to either request a new command or a previous command (in case of communication error).

  • Prerequisite: Drone is not moving and its xy-location is at the start location. Specific z-location is not required.

• ZP timeout: If Jetson does not respond to a Movement request (type 1) within the timeout (to be determined by EFS), the request has timed out and ZP will resend.

• Jetson failure:

  • ZP considers the Jetson to have failed if any of the following occur:

    • A number of consecutive timeouts (to be determined by EFS).

    • ZP receives an invalid command (e.g. a movement that will bring the drone outside of the height limits).

      • Landing Initiation Command (type 3) with ID of 0.

  • ZP must handle the Jetson failure case (e.g. by switching to operator override).

Relevant documentation: ZP-Jetson Communication

Reason for Change

Increase robustness to prevent desynchronization and/or failure rate.

Priority

Medium

Impact of Not Responding to Change

ZP and Jetson may desynchronize, causing Jetson to believe the drone to be in a location it is not actually at, resulting in invalid commands (e.g. flying into obstacles, landing at incorrect location).

What Groups, People, Sub-teams Need to be Notified?

• Director: @Jinghao Lei @Anthony Luo

• Firmware EFS: @Aaditya Chaudhary

• CV: @R D @Matthew Keller

Change Impact <Filled out by requestor>

Additional Parts/Resources Required and Costs

Development time.

Impact on deadlines

1-2? weeks, mostly on ZP side for message verification.

Alternatives and Recommendations

Somehow shoehorn the behaviour into existing message formats. CV side could verify current location with Odometry Data (type 0) received from ZP.

Comments

N/A

Change Request Sign Off <System Integration>

Status

Accepted / On Hold / Rejected / More info Requested

Comments

Signatures/Name