search

RobotCasserole1736 / CasseroleLib

Common Libraries used year-to-year for FRC robot code
MIT License
6 stars 1 forks source link

Website Calibration state feedback #18

Open gerth2 opened 7 years ago

gerth2 commented 7 years ago

At present, the usage of calibrations is a bit underdefined.

Originally, calibrations were designed to be a one-shot deal - A calibratable value was defined in software, users could override the value, and any new values had to be taken by software immediately.

Some parts of software don't want to take the value immediately though. Remember a cal value could be applied at any time (teleop, auton, disabled, etc.). For things like a PID, you don't want to change the gains until you're stopped (perhaps in disabled mode?). Although software could be implemented not to read from the cal until this is true, the user has no feedback to know whether the software has accepted their cal value or not.

We should add this feedback, and unify the "cal change used" logic along the way.

Here is the scope of the change requested:

  1. Modify the cal website "Overriden" column as such:
    1. Name = "State"
    2. Values:
      1. "Default" - use same text color as the rest of the page.
      2. "Pending" - use bright yellow
      3. "Ovrd" - use bright green
    3. The colors are designed to make for quick analysis to see at a glance the state of each cal

Meaning of each state: . Default - Robot is currently using the default value assigned in software . Pending - Robot has received a command to update the value of the cal, but has not yet utilized the new number . Ovrd - The new value for the cal has been acknowledged and is in use in the robot.

Each calibration object should support this same state definition (feel free to remove previous "acknowledged" boolean and related logic, as this supersedes it). At boot, all calibrations should start in the default state. Whenever the user sends a value from the website, or the cal value is updated from the text file, the state should go to "Pending".

For the transition out of "Pending" , there are two possibilities I think we need to support:

  1. auto-transition - as soon as the get() method is called, the calibration assumes the user took the value and did something useful with it. This is the behavior today, and should be the default behavior of a calibration.
  2. no auto-transition - The user may call .get() as much as they please, with no change to state. The user must explicitly call the acknowledge() method to transition the cal state out of Ovrd. This is when the cal must go through more complex logic before we can report to the user that we're actually using the value they asked for. An additional constructor should be added which has a boolean to explicitly choose between auto-transition on or off. The old constructors should be kept around and the transition method should default to auto-transition on.

Whenever the transition condition is hit, "Pending" should change into Default or Ovrd, depending on whether the user requested to apply a new cal value, or reset to default.

Go ahead to make and test these changes on the 2017 robot (the PID gains for the shooter should need to use this pending logic, while intake speed shouldn't need to use it - these are your two testcases). We'll move the code deltas over the casserole lib when they're finished.

gerth2 commented 6 years ago

Here's the next debugging steps for the issue we saw at the end of last meeting: the website was displaying "PENDING", but never "OVRD".

1) Launch the test website in debug mode. Verify that when you apply an override from the website, the calibration does in fact go to the OVRD state once the get() function is called (which it should be very often)

2) Analyze the logic of the websocket handler for the robot code. This function is what gets called whenever the website sends data to the robot - This data could be "set this cal to this value", "reset this cal value", or "save values to file". All of its input comes from the website's javascript calls to dataSocket.send() (see here for example).

Notice the java socket handler always calls the broadcastData() method after handling a website request. This is the operation that makes sure that whatever the website did to the robot, the changed robot state is reflected in what is displayed to the user.

However,

The logic, as-is, makes the assumption that all state changes occur right when the user asks for them. This is no longer the case. (The state change from PENDING to OVRD happens whenever get() is called, which is not synchronized with user interaction (nor may you assume it ever will be)).

So, I have an answer in mind. But I'll wait to say it. What's your thoughts? How do we get the website to update properly in all cases?