road-runner-quickstart VS road-runner

Roadrunner is a motion control library that is mostly commonly used with the roadrunner quickstart:https://github.com/acmerobotics/road-runner-quickstart

If you are using the roadrunner quickstart, the file should be the same as this: https://github.com/acmerobotics/road-runner-quickstart/blob/master/build.common.gradle

I suspected that I might have screwed something up in the code that I shouldn't have touched yet, so I freshly redownloaded the roadrunner quickstart from https://github.com/acmerobotics/road-runner-quickstart, but the problem persisted.

All of it is on GitHub. Here is the Road Runner source code, and Here is the quickstart code.

The default SampleMecanumDrive provided by the quickstart has a 5 degree follower breakout condition. If you look at this line: https://github.com/acmerobotics/road-runner-quickstart/blob/066da2b854b1f939fceaf7e5439470fde1ddd853/TeamCode/src/main/java/org/firstinspires/ftc/teamcode/drive/SampleMecanumDrive.java#L121 (Line 121 on the github link), you'll see that there's a Pose for the second to last argument. This is the "admissible error" meaning the follower will stop following if it is within that tolerance. You can see that the default admissible error allows for 5 degrees of tolerance which matches up with your reports. You can lower this number for further accuracy. It may just take a little longer to reach that.

RoadRunner does not come with built-in support for omni wheel drives. To get RoadRunner to work with omni wheel - and be able to strafe - it would require implementing Drive.kt with kinematics for this wheel configuration. Alternatively, you could attempt to treat your robot as a tank drive - but this would require modifying the built-in tank drive code (probably), and you'd lose the capability to strafe. See https://github.com/acmerobotics/road-runner/tree/v0.5.5/core/src/main/kotlin/com/acmerobotics/roadrunner/drive

The other responses have linked to good general resources. I just want to give some more details on "spinning splines." Such a path can be created by pairing a spline curve with a linear heading interpolator. Most users manipulate these objects through a higher-level API like the builders' method splineToLinearHeading(). However it's made, a trajectory produced from that path gives a complete description of the robot's pose (2D position and heading) and their change over time relative to the (stationary) field. Perhaps these functions are what you're after, but the proof of the trajectory is in its tracking. One could conceivably track the trajectory with a feedback controller regulating the pose error to zero, though the controller would often lag behind and press on constraint boundaries. An integral feature of Road Runner is descent spline following without feedback. Using the pose velocity of the robot in its body frame, one can compute wheel velocities (and motor powers) that will (approximately) trace out the trajectory under ideal conditions (i.e., according to the robot model). Feedback can then build on these base commands for higher accuracy.

There's a paper written by the developer of roadrunner about splines in fact in case you wanna learn more about it: https://github.com/acmerobotics/road-runner/blob/master/doc/pdf/Quintic_Splines_for_FTC.pdf

There's this one I made by using print in onshape and then just cropping it to size.