Migrate constants to JSON files

[jkleiber]

Purpose
The purpose of this issue is to make configuration management better by refactoring our current Constants.java constants into JSON files that can be read at init. This would make it such that we don't need to re-compile if changing just one variable.

Some constants are sim or robot specific. Some may be specific to shop vs competition. Some constants are common to all configurations. A file structures that makes sense should be used to manage these differences.

A new class (or an update to Constants.java) should be made that loads in the appropriate configuration files and makes the parameters available to the software stack.

Project Scope

• Migrate current constants into JSON files
• Create a reasonable file structure for managing parameters
• Create a class or modify Constants.java to manage the loaded parameters

[aidnem]

@jkleiber would you prefer to have this still be type-safe (keep the existing constant type definitions but read values on init from JSON files)? I'm planning out how I could implement this. Also, I've looked into it and it looks like WPILib depends on Jackson for JSON parsing. Can you think of any reason this wouldn't be suitable for our needs?

[jkleiber]

@aidnem keeping type safety is probably best since we're using Java.

I don't really know what Jackson is tbh. I'll give you the design freedom to do whatever you think is best and scalable, and we can iterate on it as needed

[aidnem]

Potential file structure:
One JSON file per object from Constants.java. I think we should have a standard folder for the constants as previously defined. Additionally, we should add a sim folder containing one file per object, just like in standard. However, only constants that need to be overwritten in sim need to be included, the rest will use the default values defined in their standard counterparts. The tree can be seen below:

src/main/deploy/constants
├── sim
│   ├── CANDevices.json
│   ├── ConversionConstants.json
│   ├── DriveConstants.json
│   ├── EndgameConstants.json
│   ├── FeatureFlags.json
│   ├── FieldConstants.json
│   ├── IOConstants.json
│   ├── IntakeConstants.json
│   ├── LEDConstants.json
│   ├── ScoringConstants.json
│   ├── SensorConstants.json
│   ├── TunerConstants.json
│   └── VisionConstants.json
└── standard
    ├── CANDevices.json
    ├── ConversionConstants.json
    ├── DriveConstants.json
    ├── EndgameConstants.json
    ├── FeatureFlags.json
    ├── FieldConstants.json
    ├── IOConstants.json
    ├── IntakeConstants.json
    ├── LEDConstants.json
    ├── ScoringConstants.json
    ├── SensorConstants.json
    ├── TunerConstants.json
    └── VisionConstants.json
    ```

[jkleiber]

@aidnem I like this concept, and it's given me some ideas:

1. We should make a common folder for constants that don't change based on sim/robot/HITL (i.e. conversion constants)
2. We should migrate feature flags to their respective subsystem constants JSON. Since your framework has constants separated out based on deployment platform (sim/robot). This would have the added benefit of solving Make feature flags multi-level rather than boolean #188 by design rather than using some complicated enum set-up. The only potential problem here is that we could have repetitive constants files for sim/robot depending on the subsystem, but I think we can refactor that as needed (resisting premature optimization lol)
3. CANDevices isn't currently used, and we have the seemingly similar IOConstants and SensorConstants. I recommend making all of these into one JSON: DeviceConstants.json
4. In support of Adds shop mode #157, it might be best to have a folder for field environments. I also added a file to the structure called "ConfigurationConstants.json" that could theoretically be used to differentiate sim from HITL, and select which field layout we want, etc.

src/main/deploy/constants
├── common
│   ├── ConfigurationConstants.json
│   └── ConversionConstants.json  
├── env
│   ├── shop
│   │   └── FieldConstants.json
│   └── official
│        └── FieldConstants.json
├── sim
│   ├── DeviceConstants.json
│   ├── DriveConstants.json
│   ├── EndgameConstants.json
│   ├── IntakeConstants.json
│   ├── LEDConstants.json
│   ├── ScoringConstants.json
│   ├── TunerConstants.json
│   └── VisionConstants.json
└── robot
    ├── DeviceConstants.json
    ├── DriveConstants.json
    ├── EndgameConstants.json
    ├── IntakeConstants.json
    ├── LEDConstants.json
    ├── ScoringConstants.json
    ├── TunerConstants.json
    └── VisionConstants.json

[aidnem]

@jkleiber Awesome. One question, in your system will constants default to be from robot and then only be overwritten if they exist in sim, do you plan to define every constant in both places?

[jkleiber]

@aidnem maybe we could define default constants in common and then modify in robot or sim as needed. i.e. use the platform specific constant if it is defined, otherwise use common

[aidnem]

I'm super swamped with AP review at the moment, so I'm not sure if I'll have time to implement this before school is out. If somebody else wants to take it, I can help get started, as I'm already in the process of planning how it could be done.

[jkleiber]

@aidnem school comes first of course - with your file structure and some reading of the docs I'm sure someone else can do the implementation. If not, the work will always be here waiting

[jkleiber]

Discussion in person: We should use a non-wpilib library that loads in files based on a schema (i.e. something like protobuf, flatbuffers) in order to maintain static typing while also being able to change constant values without needing to recompile