Troubleshooting Complete Failures¶
There are a number of things that can cause your robot to do completely the wrong thing. The below checklist covers some common mistakes.
My robot doesn’t move.
Are you actually outputting to your motors?
MalformedSplineExceptiongetting printed to the driver station? If yes, go to the
Is your trajectory very short or in the wrong units?
My robot swings around to drive the trajectory facing the other direction.
Are the start and end headings of your trajectory wrong?
Is your robot’s gyro getting reset to the wrong heading?
Are your gyro angles clockwise positive? If so, you should negate them.
My robot just drives in a straight line even though it should turn.
Is your gyro set up correctly and returning good data?
Are you passing your gyro heading to your odometry object with the correct units?
Is your track width correct? Is it in the correct units?
I get a
MalformedSplineExceptionprintout on the driver station and the robot doesn’t move.
Do you have two waypoints very close together with approximately opposite headings?
Do you have two waypoints with the same (or nearly the same) coordinates?
My robot drives way too far.
Are your encoder unit conversions set up correctly?
Are your encoders connected?
My robot mostly does the right thing, but it’s a little inaccurate.
Go to the next section.
Troubleshooting Poor Performance¶
This section is mostly concerned with troubleshooting poor trajectory tracking performance like a meter of error, not catastrophic failures like compilation errors, robots turning around and going in the wrong direction, or
This section is designed for differential drive robots, but most of the ideas can be adapted to swerve drive or mecanum.
Poor trajectory tracking performance can be difficult to troubleshoot. Although the trajectory generator and follower are intended to be easy-to-use and performant out of the box, there are situations where your robot doesn’t quite end up where it should. The trajectory generator and followers have many knobs to tune and many moving parts, so it can be difficult to know where to start, especially because it is difficult to locate the source of trajectory problems from the robot’s general behavior.
Because it can be so hard to locate the layer of the trajectory generator and followers that is misbehaving, a systematic, layer-by-layer approach is recommended for general poor tracking performance (e.g. the robot is off by few feet or more than twenty degrees). The below steps are listed in the order that you should do them in; it is important to follow this order so that you can isolate the effects of different steps from each other.
The below examples put diagnostic values onto Network Tables. The easiest way to graph these values is to use Shuffleboard’s graphing capabilities.
If your odometry is bad, then your Ramsete controller may misbehave, because it modifies your robot’s target velocities based on where your odometry thinks the robot is.
Set up your code to record your robot’s position after each odometry update:
Lay out a tape measure parallel to your robot and push your robot out about one meter along the tape measure. Lay out a tape measure along the Y axis and start over, pushing your robot one meter along the X axis and one meter along the Y axis in a rough arc.
Compare X and Y reported by the robot to actual X and Y. If X is off by more than 5 centimeters in the first test then you should check that you measured your wheel diameter correctly, and that your wheels are not worn down. If the second test is off by more than 5 centimeters in either X or Y then your track width (distance from the center of the left wheel to the center of the right wheel) may be incorrect; if you’re sure that you measured the track width correctly with a tape measure then your robot’s wheels may be slipping in a way that is not accounted for by track width–if this is the case then you should run the track width characterization and use that track width instead of the one from your tape measure.
If your feedforwards are bad then the P controllers for each side of the robot will not track as well, and your
DifferentialDriveVoltageConstraint will not limit your robot’s acceleration accurately. We mostly want to turn off the wheel P controllers so that we can isolate and test the feedforwards.
First, we must set disable the P controller for each wheel. Set the
Pgain to 0 for every controller. In the
RamseteCommandexample, you would set
(Java only) Next, we want to disable the Ramsete controller to make it easier to isolate our problematic behavior. This is a bit more involved, because we can’t just set the gains (b and zeta) to 0. Pass the following into your
Finally, we need to log desired wheel velocity and actual wheel velocity (you should put actual and desired velocities on the same graph if you’re using Shuffleboard, or if your graphing software has that capability):
Run the robot on a variety of trajectories (curved and straight line), and check to see if the actual velocity tracks the desired velocity by looking at graphs from Network Tables.
If the desired and actual are off by a lot then you should check if the wheel diameter and
encoderEPRyou used for characterization were correct. If you’ve verified that your units and conversions are correct, then you should try recharacterizing on the same floor that you’re testing on to see if you can get better data.
Verify P Gain¶
If you completed the previous step and the problem went away then your problem can probably be found in one of the next steps. In this step we’re going to verify that your wheel P controllers are well-tuned. If you’re using Java then we want to turn off Ramsete so that we can just view our PF controllers on their own.
You must re-use all the code from the previous step that logs actual vs. desired velocity (and the code that disables Ramsete, if you’re using Java), except that the P gain must be set back to its previous nonzero value.
Run the robot again on a variety of trajectories, and check that your actual vs. desired graphs look good.
If the graphs do not look good (i.e. the actual velocity is very different from the desired) then you should try tuning your P gain and rerunning your test trajectories.
Make sure that your P gain is nonzero for this step and that you still have the logging code added in the previous steps. If you’re using Java then you should remove the code to disable Ramsete.
If your accuracy issue persisted through all of the previous steps then you might have an issue with your constraints. Below are a list of symptoms that the different available constraints will exhibit when poorly tuned.
Test one constraint at a time! Remove the other constraints, tune your one remaining constraint, and repeat that process for each constraint you want to use. The below checklist assumes that you only use one constraint at a time.
If your robot accelerates very slowly then it’s possible that the max voltage for this constraint is too low.
If your robot doesn’t reach the end of the path then your characterization data may problematic.
If your robot ends up at the wrong heading then it’s possible that the max drivetrain side speed is too low, or that it’s too high. The only way to tell is to tune the max speed and to see what happens.
If your robot ends up at the wrong heading then this could be the culprit. If your robot doesn’t seem to turn enough then you should increase the max centripetal acceleration, but if it seems to go around tight turns to quickly then you should decrease the maximum centripetal acceleration.
Check Trajectory Waypoints¶
It is possible that your trajectory itself is not very driveable. Try moving waypoints (and headings at the waypoints, if applicable) to reduce sharp turns.