Software

The main function of the BOAT is controlled by the communications state machine, which handles all the primary data sent between the BOAT and BOSYN. At startup, the BOAT starts in the Pairing state, where it awaits a proper pairing signal from a controller which is then processed in the interrupt. Once decoded, the BOAT switches to the Paired state, which it will regularly send Status Frames at the 5Hz cadence. If the balloon is popped, an unpair signal is received, or a timeout occurs where no command frames have been sent, the BOAT switches back to the pairing state as it awaits another pairing frame. 

The BYTER also uses a simple state machine to manage the three different states required for gameplay. When a toggle chomp command is sent from the controller, this is process by the communications state machine which will send ES_CHOMP to the BYTER state machine. If in the waiting state, and no timing limitations are in place (maximum 3 byters per 24 seconds), the BYTER will activate and start another 4 second timer. 

If another chomp event or timeout is received, the Byter will then switch to a 3 second cooldown in which it is not allowed to be activated again. When this cooldown is complete, it will then switch back to the waiting state.

In addition to the above mentioned state machines, a services and HALs are used for hardware control and movement. Descriptions of each are as follows:

• DCMotor_HAL.c: Includes commands to actually control each individual DC motors PWM values and duty cycles.

• PropellerService.c: Converts controller thrust and yaw commands into actual propeller values to drive the boat.

Our controller-side operation is dictated by two states: pairing and operating. Upon system start up, the controller is in the pairing state, and attempts to pair to whichever team is selected by the team select dial. The controller then sends out a pairing frame every 0.2 seconds to the selected team. All received messages are ignored except for a Pair ACK frame, which indicates successful pairing and that the system may proceed into the operating state. 

Within the operating state exists a regular send-receive cadence of command and status frames at the 5 Hz cadence. The system remains operating unless a boat initiated unpair (caused by popped balloon) or controller initiated unpair (caused by rotation of the team select dial) occurs. Additionally, a no-receive timeout (caused by missing 5 anticipated status frames) also puts the system back into the pairing state.

A series of supporting services exist to help with controller operation. These services help read sensor, translate raw values into useful outputs, and operate user visual feedback. A brief description of each is included here:

• JoystickHAL.c: Reads raw thrust and rotation potentiometer values and translates into one byte command frame values.

• GaugeService.c: Operates the weapon feedback servo gauge, showing the user if the weapon is in cooldown, active, or ready to deploy.

• KachowService.c: Reads microphone inputs and checks for fitting to Kachow cadence, generating a Kachow event if necessary input conditions are met