Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected Behavior When Switching Trajectories Using Sequential Action #376

Open
jdbott opened this issue May 9, 2024 · 5 comments
Open

Comments

@jdbott
Copy link

jdbott commented May 9, 2024

RR FTC Version

0.1.13

Observed Behavior

When creating trajectories, unexpected behavior happens when using sequential action when switching from one trajectory to the next. For example, I made a trajectory (trajOne), and another (trajTwo). When moving from trajOne to trajTwo using the sequential action, the robot moves erratically to the first position in trajTwo, changing heading and position wildly before getting to the correct position. If I put all the motions in trajOne, this doesn't occur.

Tuning Files

No response

Robot Logs

No response

@AusreisserSF
Copy link

Our team has seen exactly the problem you described. We started from the example in the Roadrunner 1.0 documentation - "Building a CENTERSTAGE Autonomous" - but our adaptation didn't work; the simple lineTo in the toSample1 Action causes the robot to stutter in place. The comments I have inserted in this shortened example explain why:
MecanumDrive drive = new MecanumDrive(hardwareMap, new Pose2d(14.76, -62.89, Math.toRadians(90)));

    // This is the first trajectory Action after the creation of the instance
    // of MecanumDrive so the use of drive.pose is ok here.
    Action toSubmersible = drive.actionBuilder(drive.pose)
            .splineToSplineHeading(new Pose2d(6.44, -35.0, Math.toRadians(90)), Math.toRadians(90))
            .build();

    // The field drive.pose is not actually used here. This Action is just a
    // placeholder.
    Action hangSpecimen = drive.actionBuilder(drive.pose)
            .waitSeconds(2)
            .build();

    // This Action depends on the ending pose of toSubmersible, not drive.pose as it
    // is captured here at the time toSample1 is constructed.
    Action toSample1 = drive.actionBuilder(drive.pose)
            .lineToY(-48)
            .build();

    Actions.runBlocking(
            new SequentialAction(
                    toSubmersible,
                    hangSpecimen,
                    toSample1
            )
    );

To get around this problem the students simply hard-coded the expected pose in toSample 1 instead of using drive.pose. There is another way of solving this problem by deferring the creation of the toSample1 Action until after toSubmersible has completed but it's somewhat more complex.
Phil Young
Software mentor, FTC Team 4348 Notre Dame High School, Sherman Oaks, CA

@rbrott
Copy link
Member

rbrott commented Sep 22, 2024

The CENTERSTAGE auto guide was using some bad patterns that I don't recommend. I've now updated it.

Teams should usually not use drive.pose in their action builders to avoid confusion like this and to avoid unnecessary variability in their auto paths based on odometry variation or, even worse, large external disturbances.

@AusreisserSF
Copy link

AusreisserSF commented Sep 22, 2024 via email

@rbrott
Copy link
Member

rbrott commented Sep 22, 2024

  • Use actionBuilder() when the starting pose is known (e.g., the very first action builder)
  • Use fresh() when a new action builder should begin at the end of the last one (this is similar to using end() if you're familiar with the old Road Runner API)

See the updated tutorial for more details on how this works.

@AusreisserSF
Copy link

AusreisserSF commented Sep 23, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants