In NOMAD-Base, constants files are per-subsystem. Each subsystem or major functionality area gets its own *Constants interface. For example, autonomous driving has an additional AutoConstants interface beyond DriveConstants. These interfaces specify getters for every constant that the subsystem needs. This includes control loop constants, hardware ports, etc. It can also include utility objects that need a single instance.

Usage

To use a constants file in the project, create an implementation of the interface and provide method bodies for the getters, returning your specified value. If your constants depend on constants in another file, then in the constructor of your constants class, require the other file to be passed in as a parameter. Be careful not to create circular dependencies. In RobotContainer.java, declare an instance of the constants interface, and then instantiate that instance with your specific implementation in RobotContainer.createConstantsFiles. Example below:

//When declaring variables
//Constants Files
  private AutoConstants autoConstants;
  private DriveConstants driveConstants;
//In RobotContainer constructor
  public RobotContainer() {
    createConstantsFiles();
    createSubsystems();
    createControllerProfiles();
    createControllers();
    createCommands();
    configureButtonBindings();
    configureDefaultCommands();
  }

  /**
   * Creates the constants files for each subsystem.
   */
  private void createConstantsFiles() {
    driveConstants = new DriveConstantsKRen();
    autoConstants = new AutoConstantsKRen(driveConstants);
  }

See RobotContainer for more info on how RobotContainer is set up.

Dependency Injection

The constants classes are designed to be passed in to the objects that need them. As an example, a drive command would likely have a constructor parameter of DriveConstants. This is consistent with the subsystem dependency injection in the new command-based framework.