OBC Intro
The on board computer (OBC) houses most of the mission critical code for our system. This project will introduce you to a stripped down version of the OBC, attempting to mimic the core functionality of the production obc.
We primarily control the tasks of the OBC through a state machine (ticks) with memory (mission state).
Mission State
The mission state is the object that holds all of the shared data for the system. This information persists across ticks, and provides information for the rest of the system to work with (e.g. what the current tick is).
The mission state is a singleton, meaning that there is only one instance of it at any time (in this case, across the lifetime of the program). Furthermore, the mission state is mutable in any tick, and the ticks will often both read and update the information in the mission state.
Tick Architecture
The OBC runs on a tick architecture, kinda like a flow chart (or a finite
state machine if you're familiar). For each tick, the OBC will perform a certain
function, and then change to a different tick for a new function (e.g. taking
off or dropping payloads). In this project, there will be 5 ticks: Prep
,
Switch
, Camera
, Verify
, CVLoiter
, Done
. Below is the tick diagram
that you will be implementing.
However, you will initially only be given the following:
The purpose of each tick is described in the following table:
Tick | Purpose |
---|---|
Prep | Initialize the mission state, and waits for some time |
Switch | Switches between the camera of verification ticks (camera first, and then verify after first loop) |
Verify | Asks the user to verify the type of image taken by the camera (checks against computer name) |
Done | The terminal tick, does nothing and ends the program |
Through the following tasks, you will implement the missing ticks and their corresponding functionality.
Before Starting to Code
Follow the README
for the onboarding obc project to set up your environment.
Run the code (using make
and make run
) to ensure that the code compiles and
runs without issues. If there are any issues, please reach out to a software
member.
Think about what you see when you run the obc. Does the state machine behave like intended?
Full File Structure:
Here you can see the full file structure of the onboarding OBC. We use
include/
for header files and src/
for source files. The subdirectories
inside these files are organized by functionality.
You will primarily be working in
- Ticks: The state machine of the obc
- Camera: The camera interface and mock camera
- Network: The gcs interface and routes
While the other two are
- Core: The mission state and obc main loop
- Utilities: Helper functions
Since you will be writing new ticks from scratch, I have highlighted some files that might be useful references.
OBC
├── images
│ └── (Images for the camera)
├── include
│ ├── camera
│ │ ├── interface.hpp
│ │ └── mock.hpp
│ ├── core
│ │ ├── mission_state.hpp <--------|
│ │ └── obc.hpp |
│ ├── network |
│ │ ├── gcs.hpp |
│ │ ├── gcs_macros.hpp |
│ │ └── gcs_routes.hpp |-- Reference these files
│ ├── ticks |
│ │ ├── end.hpp |
│ │ ├── ids.hpp |
│ │ ├── mission_prep.hpp <--------|
│ │ ├── switch.hpp |
│ │ ├── tick.hpp <--------|
│ │ └── verify.hpp
│ └── utilities
│ ├── base64.hpp
│ └── locks.hpp
├── Makefile
├── protos
│ └── onboarding.proto
├── README.md
├── src
│ ├── camera
│ │ ├── interface.cpp
│ │ └── mock.cpp
│ ├── core
│ │ ├── mission_state.cpp
│ │ └── obc.cpp
│ ├── main.cpp
│ ├── network
│ │ ├── gcs.cpp
│ │ └── gcs_routes.cpp
│ ├── ticks
│ │ ├── end.cpp
│ │ ├── mission_prep.cpp <--------|
│ │ ├── switch.cpp |-- Reference these files
│ │ ├── Tick.cpp <--------|
│ │ └── verify.cpp
│ └── utilities
│ └── base64.cpp
└── tests
├── integration
│ ├── gcs_status_integration.cpp
└── unit
├── mission_state_test.cpp
└── test_main.cpp