Skip to content

Comms_2022_October_Structure

Bennett Petzold edited this page Oct 1, 2022 · 1 revision

Architecture

diagram_comms_structure

ControlBoardThreadManager

The public API other packages will use to communicate with the control board. Handles async threaded operations using the operations provided by ControlBoardCommunication. Owns a ControlBoardCommunication. Acts as a wrapper for the public ControlBoardCommunication methods by offering a threaded version of each.

Sending Messages: Takes in parameters, returns nothing. Creates a thread for the operation. Thread returns true on success, false on failure. The thread is put on a thread pool which is checked by another module.

Reading Messages: Usually takes in no parameters, returns a thread. Creates the thread for the operation and returns the formatted data the user is expecting (mode, inversion, speed, etc).

ControlBoardCommunication

Not called outside the package. Uses SerialCommUtility. Contains methods that synchronously generate specific messages to the control board. This includes setting motor speeds, inversions, etc. Only class that directly communicates with the serial port.

SerialCommUtility

Not called outside the package. Contains only static methods. Used to wrap and unwrap messages sent to the control board. See the ControlBoard spec for details.

Branch Structure

Main in the branch all subteams feed in to.

Comm is the branch all comm features feed into.

Individual features are built in individual branches. commboard is one feature we will be writing. Other features, like testing and additional improvements, will get their own branches. They will be merged up into Comm, and comm will be integrated into main when we submit our work to the robot "for real". Merging to main requires a reviewed PR, while merging to comm does not.