Architecture - Dutton-Christian-Robotics/Learning-to-Code GitHub Wiki

Progressively Better

The way we design and construct our code is important. Steps towards better architecture:

  1. All we have is the OpMode. All our functional code is written out each time in the OpMode.
  2. Still only have the OpMode, but now we wrap commonly used code in reusable functions/methods. (DRY)
  3. Take functional code and put it in its own class (i.e. a Robot class). Any code that asks for specific things to happen (namely, the OpMode) uses that class. (Separation of Concerns)
  4. Make the existing code more modular, which has the following benefits: (Separation of Concerns, Single Responsibility)
    • Competition situations frequently require: 1) quick changes and tweaks; or 2) entirely new code to be written on the fly.
    • Almost any change can be a "breaking change." Additional modularity reduces how widespread the impact of changes will be. This improves "Mean Time To Recovery (MTTR)".
    • By reducing the impact of change, it's easy to experiment and improve functionality.
  5. Change the focus of how OpModes are written to use event or command based programming.

What does this mean in terms of code for our robot?

  • Code in the OpMode should be focused on using the rest of our codebase to perform specific actions.
  • Isolate tune-able, tweak-able, or performance constants in a properties configuration file.
  • Separate out robot subsystems: e.g. drivetrain, sensors, navigation, manipulators
  • Use a robot base class that makes it easy to "add" systems and have systems talk to each other.
  • Subclass the robot for specific configurations of systems (and, thus, capabilities).