There are four main tasks that the robot should do regardless of what its current goal.

1. Driving
   • Unless we run into any problems with this approach, there should be three states that the drive task can be in:
     1. Pathfinding mode
        • In this mode, the robot should simply achieve its target position. This will involve obstacle avoidance (especially the center goal) and a standard PID loop. The loop shouldn't exit, since in this mode we expect the robot to be always trying to achieve the target position. The error values should be accessible outside of this thread so that we can intelligently update the state of the drive thread and otherwise react to specific error values (e.g. know when we are within an acceptable radius of the target position).
     2. Ball searching mode
        • When the robot is in ball searching mode, it should do several things. When it receives a target ball position from the Jetson Nano, it should turn so that the center x-coordinate of the target ball is centered in the camera's field of view. At the same time, it should drive forward and check if a ball is detected in the robot. If there is no target ball being sent by the Jetson Nano, the robot should simply turn around 360° in each quadrant of the field one by one until it intakes a ball.
     3. Move-making mode
        • When the robot is in move-making mode, the drive task should stop controlling the drive. This will allow other threads to do simple maneuvers like aligning with goals without interference.
2. Asking the Jetson Nano for data
   • This task is pretty simple — every 100 milliseconds or so, send a request to the Jetson Nano for data.
3. Receiving data from the Jetson Nano
   • This task's job is to read incoming data and set variables based on what it receives. To do this, it will first wait until it reads a certain indicator byte from the input buffer. Once this happens, it will read some number of bytes and put them in a byte array that is one element of a c++ union. Another element in the union will be a struct that includes all of the necessary variables with the correct data type. Because the byte array and the struct are stored using the same memory, the variables can be read like normal once the byte array is updated. This cycle will repeat as long as the robot's program is running.
4. Status indication
   • This is mainly for testing purposes, but it is also nice to have some idea what is happening with the robot's code during matches. The idea here is that useful information will be displayed on the screen of the v5 Brain, the screen of the controller, and in various other forms such as LED's and speakers. This will allow for easier debugging both before and during the competition.

With the help of these four threads running at all times, the robot can intelligently find balls, drive to goals (which are at known positions), score balls, etc. There will be interaction and isolation functions that get called at the during the match, which will update the state variables and do the simpler things that tell the tasks what to do.