imdunne8
commented
8 years ago The Poofs implementation of this is really slick! Finally got a chance to really look through it and I like it a lot. It's definitely very complex (more than I would expect most students to understand) and very similar functionality could be achieved without using reflection (how Java looks at it's own code/finds the static variable names) but I think using this is still our best bet. For anybody working on this, it's worth paying attention to where the Poofs code actually instantiates the Constants class - it's part of their web server which we don't currently have specific plans to use.
gerth2
To facilitate easy re-tuning of software without actually changing code, we should create a set of classes which form a "Calibration" infrastructure. This is loosely based on the architecture the famous Team 254 uses (check out https://github.com/Team254/FRC-2015/blob/master/src/com/team254/lib/util/ConstantsBase.java for reference, but don't just copy their code blindly :smile: )
First Pass Spec
Classes to implement:
Calibration
The constructor should take the following:
Internally, the class must store the present value of the calibration, as well as the default value.
The class should provide a getter for the present value (.get()) and for the default value (.getdefault()), and a setter. It is anticipated the setter should be used only by the CalWrangler. The setter should check that the override value is within the allowable range. If not, print a warning to screen and saturate the set value at the min/max range. Finally, some sort of getter should exist to get the name of the calibration.
The expectation is that for every value to be tuned (shooter RPM, P/I/D constants, etc.), a new instance of Calibration should be instantiated. All of these should be instantiated in a common robot calibration class, which is specific to each year. Then, when a controls method needs to use a cal, it references the calibration object within the robot calibration class, and uses the .get() method to get the actual present cal'ed value.
CalWrangler
No need to do anything special on instantiate (besides usual stuff for setting variables)
The wrangler should support a registration method where a calibration object may "register" itself inside the calibration wrangler. Registration means that some reference to the calibration is contained within the wrangler's data structures. The driving constraint is that, upon request, the wrangler must be able to iterate over all calibrations present in the system.
The wrangler must support a cal override method. This will be called during autonomous and teleop init methods. During the cal override method, the wranger must open a specific CSV at a specific location on the RIO's filesystem (location and name may be hardcoded). It must then parse this csv to determine which calibrations need to be overriden. Note not all calibrations in the system may have an override in the csv specified. Note also the csv might provide extra, unknown calibrations. A warning should be printed to screen, but otherwise the cal should be ignored. For each cal override specified in the csv, the wrangler must find the appropriate calibration object instance, and call its setter function with the override value.
The wrangler should also support setting all calibration values back to default, and producing a report (printed to screen?) of all cal values in the system, their names, ranges, and whether or not they have been overridden.