Robot Configuration Manager

[KyleRAnderson]

We need to have some sort of method for easily accessing robot configurations, such as the button mappings for controllers as well as robot-dependent variables.

This is kind of like a merge between RobotConfig and RobotMap from last year.

The frontend portion of this needs to be easy to use.

[ryanlarkin]

I rewrote RobotMap in 1bca176, but I'm still not sure how to combine all of the different configuration systems into one. Do you have any ideas?

[KyleRAnderson]

I think it's something we need to discuss for sure because there are many ways to do it.

One way would be to use a JSON file to store the configurations and then just read the correct configuration. We could have "global" configurations for stuff that is not specific to a robot in particular (such as controller mappings) and then "local" configurations for robot-dependent settings.

I'll try and quickly write something to show you what I mean.

We could also do it using constants but I think that would be a little messier.

Since this is going to be used a lot I feel like it's important that we get it right.

[KyleRAnderson]

It would be cool if the configurations could be changed on the fly, from networktables or something. This would have to be done while disabled, but for things like fine-tuning PID or trying out different control schemes it could be useful to be able to change the settings so rapidly.

[KyleRAnderson]

Another question, do the variables need to be constants? As in what's wrong with having them as methods? Is it just less easy to do getCameraIp() every time you want the camera's ip address?

[KyleRAnderson]

Team Decision: We're going to use static constants for things which will never truly change, and then getters (and setters) for value which could potentially change.

[KyleRAnderson]

Fluid constants

We've decided on a couple of requirements for the fluid constants.

1. Fluid constants are temporary. The constants should be reset to the deployed version when the robot is rebooted to avoid differences between the version in code and the version on the robot. However, the constants should remain the same during the entire debug session.
2. Save constants at the end of a debug session. In case we find a nice configuration, we want to save the values that we try out so we can use them later
   • The entire configuration should be saved. In case we find a nice configuration for fluid constants, we want to be able to reproduce the entire thing later. All fluid constants should be saved even if they weren't changed during the debug session.
   • The current constants should be saved when the robot is disabled.
   • Values will be saved to a text file with the deployed value and the changed value displayed side by side for comparison.
3. Values should be editable on Networktables. For easy debugging, it's nice to have values that are put on networktables so the developer can easily change and view the values.
4. Values should not be editable while enabled. If you edit a constant while the code is running it ceases to be a constant, and it might break stuff. Don't let this happen.

[kevlam2706]

Guys, I'm impressed!

[KyleRAnderson]

Together with #18 and #20 this has been implemented and tested. Meets all of above requirements.