Increase tolerance interval when leaving the interval for tangible/computer vision input

[brettfiedler]

From Google Doc:

Can we 'stickify' the feedback points?
Bias user intention toward “important parts” - e.g., parallelogram, right angles, equal side lengths
When using the tangible, make it harder to break of a tolerance than it was to get into - assume user intent to achieve those states
Want a feeling that I am in a state, increasingly important that a learner does not pop in and out of a state, it seems to matter more when you are in a notable state.

[brettfiedler]

Specifically,

Let's try increasing the tolerance interval for angleToleranceInterval, shapeAngleToleranceInterval, and lengthToleranceInterval (when the tangible is attached OR when using OpenCV) when within the tolerance.

e.g.,

NOT A PARALLELOGRAM:
angleToleranceInterval = 0.01

IS A PARALLELOGRAM
angleToleranceInterval = 0.03

or

UNEQUAL SIDE LENGTHS
shapeAngleToleranceInterval = 0.01

EQUAL SIDE LENGTHS
shapeAngleToleranceInterval = 0.03

Does this make sense? Or is there another way to implement "widening" the window when the particular state has been achieved?

[jessegreenberg]

Yes, makes sense. We might have something to play with in #20, Ill try adding these once that is ready.

[brettfiedler]

This was done in RaP for MediaPipe in phetsims/ratio-and-proportion#465

[jessegreenberg]

This was easy for angleToleranceInterval because of the work done in #108 which made it easy for the tolerance interval to be dependent on whether the shape is currently a parallelogram.

We probably need to do something similar for the other tolerance intervals.

[brettfiedler]

I am getting the sense that we might go ahead and bias the approximate shapes a bit more for computervision (and probably this will apply to the tangible too).

Let's go ahead and raise the minimum for each tolerance a bit too. Perhaps 0.02 for the minimum (entry), 0.04 for the maximum (break out)?

Or perhaps we can make it adjustable at this stage? Query parameter?

EDIT: I say this because I'm finding there a lot of balance between really level camera/marker placement that can skew these, but things do not need to be quite as precise in this space where we're really leaning on the feedback to tell us we're correct. I feel like the error in manipulating things in this environment is more forgiving when things aren't PERFECTLY 90 degrees or PERFECTLY equal. Would be good to know if others feel the same.

[jessegreenberg]

@marlitas and I worked on this a bit and got it working where the tolerance interval widens when connected to a device. It works like this:

If connected to a device and two sides are parallel, the angleToleranceInterval increases to 0.03. If connected to a device and a shape name is detected, the shapeLengthToleranceInterval and the shapeAngleToleranceInterval are increases to 0.03 from the default value of 0.01.

We should be able to modify the initial or increased values as requested in #116 (comment) next.

[jessegreenberg]

I wanted to point out that we are already doing something like this when moving more than one vertex at a time.

        else if ( numberOfVerticesPressed >= 2 ) {

          // Two or more vertices pressed at once, increase the tolerance interval by a scale factor so that
          // it is easier to find and remain a parallelogram with this input
          toleranceInterval = QuadrilateralQueryParameters.angleToleranceInterval * QuadrilateralQueryParameters.angleToleranceIntervalScaleFactor;
        }

The default value for angleToleranceIntervalScaleFactor is 10. Can we use that value for this as well?

[jessegreenberg]

OK this is ready for review @BLFiedler, here are the changes so far:

1. When device is connected, default angleToleranceInterval is query parameter ?deviceAngleToleranceInterval Default value is 0.2. When the pair of parallel sides are parallel angleToleranceInterval value is ?deviceAngleToleranceInterval * ?toleranceIntervalScaleFactor. Default value for scale factor is 10. Otherwise `angleToleranceInterval behaves like angleToleranceIntervalProperty creates inconsistencies for determining isParallelogramProperty value #26 (comment).
2. When device is connected default shapeAngleToleranceInterval is query param ?deviceShapeAngleToleranceInterval. Default value is 0.02. When there is a shape name, values becomes deviceShapeAngleToleranceInterval * ?toleranceIntervalScaleFactor
3. When device is connected shapeLengthToleranceInterval values is ?deviceShapeAngleToleranceInterval. Default value is 0.02. Value is deviceShapeAngleToleranceInterval * ?toleranceIntervalScaleFactor when there is a shape name.
4. I added a readout for shapeAngleToleranceInterval and shapeLengthToleranceInterval to the ?showModelValues panel.
5. You can pass query params from the opencv prototype to the sim now like https://phet-dev.colorado.edu/html/jg-tests/opencv-test/?showModelValues

[brettfiedler]

Having these options is great! I am not sure exactly what the best settings for each is yet, but I think we'll find them. Leaving this open and assigned to me to locate good default values.

I had a set late last week that I neglected to write down, but as a note, JG used these most recently: https://phet-dev.colorado.edu/html/jg-tests/opencv-test/?showModelValues&deviceShapeAngleToleranceInterval=0.05&deviceShapeLengthToleranceInterval=0.03&toleranceIntervalScaleFactor=6