Requirements

This page lists some basic requirements in the style of FURPS+. In this document, "PC" refers to the embedded computing solution which runs the AI, computer vision, and control systems code. The PC is managed by the high-level software team, from which the embedded team is separate.

Functional

Requests are initiated by the PC.

1. Must command each actuator to set a new goal position upon request
2. Must transmit sensor data to the PC upon request
3. Any activities independent of PC communication must function with or without a connection to the PC

Reliability

1. Must implement a hard fault handler that is capable of restoring the system to a working state
2. Time-critical functions must meet their deadlines
3. Must be impossible for the software to hang without recovering

Support

1. All code written by the embedded systems team should be well-documented using Doxygen
2. All files written by the embedded systems team must contain a Doxygen-style comment with the @file tag and @author data supplied for tracability

Performance

1. Must be capable of moving all motors to their goal positions and transmitting fresh sensor data to the PC in less than 10 milliseconds (less than 5 milliseconds is preferred). Let fresh indicate data that is no older than 2 milliseconds

Implementation

1. Must use C++ as the application code language, with C permitted for third-party libraries
2. Must use the FreeRTOS OS
3. Must use ST's HAL or LL libraries for interfacing with hardware modules on microcontroller, unless there is an issue in which case a workaround can be reviewed and implemented post-approval and documentation (as comments or in Doxygen)

MCU to PC Interface

1. Both transmitters (microcontroller and PC) must attach an error detection code in the payload for each frame. This allows the application layer to do a quick check for transmission errors, which is particularly important in the case of communication via UART. TODO: Requirements for the PC communication interface go here, as well as which data the embedded systems need to be capable of sending back to the control systems, and which commands the embedded systems need to be able to respond to. Also, consider sending angles as uint16_t. We could map values in [0.0, 300.0] to [0, 2^16 - 1]. This would roughly half our communication latency while introducing an insignificant error (0.0046 deg/bit resolution).

PC to High-Level Software Interface

1. Must accept goal positions from the high-level software as a vector of 32-bit floating-point numbers. Element 0 of the vector corresponds to the goal position for motor 1, element 1 corresponds to that for motor 2, and so on. This vector will always contain 18 entries
2. Must send current positions to the high-level software as a vector of 32-bit floating-point numbers, following the same convention as above
3. Must send x-, y-, and z-acceleration and x-, y-, and z-angular velocity to the high-level software as an Imu object (soccer msgs). Acceleration units are m/s^2 and angular velocity units are degrees/s.