Notes 7.4.2020

This meeting stemmed from the following discussing on GitLab: https://gitlab.com/aruw/code-2019-2020/aruw-mcb/-/merge_requests/144#note_371350887

Drivers architecture

Key points:

• Pass a non-static instance of the Drivers to Subsystems and other Drivers (i.e. the classes inside the Drivers class), as well as potentially Commands. For example:

Drivers drivers;

/* define subsystems --------------------------------------------------------*/
TurretSubsystem turret(&drivers);

ChassisSubsystem chassis(&drivers);

// ...

/* define commands ----------------------------------------------------------*/
ChassisDriveCommand chassisDriveCommand(&drivers, &chassis);

ChassisAutorotateCommand chassisAutorotateCommand(&drivers, &chassis, &turret);

WiggleDriveCommand wiggleDriveCommand(&drivers, &chassis, &turret);

// ...

• The name "Drivers" is a bit too specific to hardware related code. Instead we will rename it to "Context" or similar. For the initial changes, we'll keep the name the same but eventually we should think about changing the name.
  • We could also maybe split apart hardware and architecture stuff but for now we will just keep everything together.
• We must handle the case where multiple instances of the Drivers class is instantiated. Since we don't have exception handling, we can do the following:
  • First just add error to error handler.
  • Try to do something at compile time that catches multiple instances.
  • Maybe add script (grep Drivers) to insure there is only one instance of the drivers class.
• We decided to currently leave the property table outside of the drivers class.
  • This means we don't have to pass around the Drivers class to everywhere a property is used.
  • There will be a single instance of the PropertyTable, most likely just stored
  • This will likely lead to complications if we do want to integrate the property table into system tests, but for right now we won't worry about that.
• The main instantiation of the Drivers class will be stored in <robot_type>_control.cpp and will be accessed by main via a getter.

Unit tests

• Look into mocking framework. If possible and doesn't require complete rework, it would be worth doing.