Commands.none() causes erratic path

[tom131313]

The robot heads at high speed toward the edge of the Earth when running an auto path that includes Commands.none() as the second argument of a Commands.either(). The complex auto path is of the form:

.
.
.
        {
          "type": "path",
          "data": {
            "pathName": "N2 to N1"
          }
        },
        {
          "type": "named",
          "data": {
            "name": "Autonomous Finish Intake"
          }
        },
        {
          "type": "path",
          "data": {
            "pathName": "N1 to Center Line"
          }
        }

.
.
.

The named Command, say "Autonomous Finish Intake" is of the form: Commands.either(long_complicated_command, Commands.none(), a_boolean_supplier);

The path runs correctly with the TRUE leg. The robot heads straight at high speed to parts unknown when running the FALSE none() leg.

Replacing the Commands.none() with waitseconds(0.1) is a good circumvention of the problem and then the robot works perfectly.

PP version is the one before the recent update. Windows 10 Java development PC and roboRIO v2 and WPILib all up to date.

I apologize for a poor submittal without proper MRE. We don't have time and thought a poor submittal could be better than none.

[mjansen4857]

Would need some more info on what the paths you are trying to run look like. Not sure exactly what's happening.

[tom131313]

I suggest closing this issue for lack of details. Its objective has been accomplished - a data point that may or may not be in a pattern. If you haven't already, you could add an either( , none(), ) to your test suite as a potential edge case for a possible timing problem. Except for this glitch our 4-Note auto was reliable and highly useful - Thanks.

[mjansen4857]

What I'm assuming was happening was an issue with replanning if you had disjoint headings on your path-path transition. The none command would cause it to start the next path immediately without slowing down and do some weird replanning. The effect of current velocity on replanning was reduced recently, so this may not be as much of an issue anymore.

You can close this if you'd like, but if you want to keep it open and can provide some more info I might be able to help more.