This is the code made for makerfaire 2023

Feature (RPI)

pygame window for status:
- flexion (Left)
- extension (right)
- Compressor status
- Pneumatic flexion-extension
Simple keyboard input to control the leg
- W: activate valve for pneumatics (let go of the button to extend)
- A: flexion
- D: extension
- T: Step sequence (a preprogrammed sequence of movement currently to make one step)
- Q: Quit the game (This is the proper way of quiting on a non-RPI or dev environment as multithreading is used)
Fully coded muscle controller
Fully coded pneumatic
Fully coded pressure handshake
Partially coded motor controller
Fully coded mock classes for gpiozero classes that can not be initiated on non-RPI machines
Partially coded step sequence demo

Feature (Arduino)

Due to our need to differentiate machines from RPI and non-RPI machines you will need to create a .env file
Create a .env file in the raspi directory and add the following on the first line ENV=prod for RPI. ENV=dev for non-RPI
If you need to change the pins for pneumatics, handshake, or the compressor, you can access it from src/raspi/pinconfig.json
You can also tie different pins for different muscle in that folder (for more info read here)
Once all of setup is complete run the command catbot start -D. Make sure you are at the root repository.

You may encounter that your catbot command is missing. Do not worry just run the command npm install -g. If you do not have npm then read the readme file in the root repository and complete the setup
You may encounter an error that says the main file is missing. Also, run the following command npm install -g.
You may encounter an error that says the index of 'ENV' is none or missing then make sure you have your .env file in the correct spot.

You may also realize that handshake, compressor, valve, and class methods of muscle class are missing.
- This is on purpose to reduce repetition and headache of tracking objects around the main program. I, Hiro, have converted OO architecture to more procedural code (functional programming). We will discuss more about this architecture decision, and why I believe this is for the benefit of higher-level programming as well as 'cleaner' code. It is currently not optimized for performance however we can achieve peak performance with more testing and refactoring.
- The architecture of the motor class is similar to OO due to the different authors of the code however that is most likely to change whether we decide to keep going with OO or FP.

closes #19