What I know isn’t going wrong:
I ran frc-characterization to get the right constants, and I generated several simple paths (like a smooth curve) using PathWeaver. I’ve quadruple checked units (everything, including characterization and all encoder counts, is done in meters). The gyroscope readings are correct. There are no MalformedSplineExceptions.
Problem:
But when the Romi starts following the generated trajectory, it will only go part of the way before it shuts off, assuming it is done following the path. Ex. for a path about 7 meters in distance, it stops after traveling about 3 meters.
Code:
The code I’m using is very similar to
but is modified to use meters as encoder units. I linked an image of the PathWeaver trajectory I’m using for testing.
Last bit of info:
PathWeaver calculates how long each path should take to traverse. The robot runs for exactly as much time as the calculated trajectory traversal time. Unfortunately, the Romi appears to not be able to move as quickly as PathWeaver calculates that it should. Is the Trajectory class shutting down the Romi at the end of the allotted time?
Yes, you can try outputting the current pose data from your odometry object to the dashboard (or console). When you travel a metre forward, does it report you travelled a metre?
7ft is just over 2 metres, could it be a unit conversion issue?
Definitely seems to stop after a certain period of time. It seems to stop as soon as the “calculated time to follow trajectory as defined by Pathweaver” has elapsed. It doesn’t stop at any specific waypoints on the trajectory and it doesn’t seem to stop after a certain set of distance.
I looked at your PathWeaver project and it looks like you have Velocity and Acceleration set to 3 Meters/second. For a normal FRC robot that is pretty common but that is WAY too fast for the Romi!
I haven’t done a lot of testing with it. I would plot the velocity (in m/s) and then run the Romi at max speed. That will give you an upper bound. I would adjust down from there based on the type of trajectory you are running.
In the example you linked above it looks like ZQ uses:
public static final class AutoConstants {
public static final double kMaxSpeedMetersPerSecond = 0.8;
public static final double kMaxAccelerationMetersPerSecondSquared = 0.8;
To add to this, for now, we have cut that speed in half based on the recommendation from @veg We are using 0.4. We may be experiencing some similar behavior, but I am not sure it is consistent yet. I tried to run an iscoelese triangle, and though it goes perfectly through the apex point (I cannot put into words how impressive that is to watch), it continues past the second turn almost every time. I just need to do more testing to see if I am doing something wrong or if it is a similar issue.
