Open jdbott opened 4 months ago
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
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.
Hello,
Thank you for your reply. Instead of drive.pose in their action builders what should teams use?
Thanks, Philip Young FTC Team 4348
From: Ryan Brott @.> Sent: Sunday, September 22, 2024 1:00 PM To: acmerobotics/road-runner-quickstart @.> Cc: Philip Young @.>; Comment @.> Subject: Re: [acmerobotics/road-runner-quickstart] Unexpected Behavior When Switching Trajectories Using Sequential Action (Issue #376)
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.
— Reply to this email directly, view it on GitHubhttps://github.com/acmerobotics/road-runner-quickstart/issues/376#issuecomment-2366939878, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK4NPLQFT6QZCLHOKIDVJEDZX4OWBAVCNFSM6AAAAABHPTR44GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRWHEZTSOBXHA. You are receiving this because you commented.Message ID: @.***>
actionBuilder()
when the starting pose is known (e.g., the very first action builder)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.
Thank you very much for your help. We'll try fresh() right away.
And by the way, the new tuning procedures for Roadrunner 1.0 are a huge improvement. I'm sure a lot of work went into this.
Phil Young 4348
From: Ryan Brott @.> Sent: Sunday, September 22, 2024 1:36 PM To: acmerobotics/road-runner-quickstart @.> Cc: Philip Young @.>; Comment @.> Subject: Re: [acmerobotics/road-runner-quickstart] Unexpected Behavior When Switching Trajectories Using Sequential Action (Issue #376)
See the updated tutorialhttps://rr.brott.dev/docs/v1-0/guides/centerstage-auto/ for more details on how this works.
— Reply to this email directly, view it on GitHubhttps://github.com/acmerobotics/road-runner-quickstart/issues/376#issuecomment-2366953350, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK4NPLWMKO6HGZ2KXWOALSLZX4S45AVCNFSM6AAAAABHPTR44GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRWHE2TGMZVGA. You are receiving this because you commented.Message ID: @.***>
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