I’m a new coder tasked with making our swerve drive work, and its autonomous just isn’t. I followed the tutorial from “Zero to Autonomous” and even though the robot is moving (even in autonomous), it isn’t going in the right direction (when I tell it to go to the x direction only it goes diagonally, even though our NavX is pointed correctly) and it doesn’t go the right distance either.
Teleop works perfectly, just autonomous isn’t going where I’m telling it to go. I’ve looked into other teams’ projects and nothing seems to work.
Additinally, when I rerun the autonomous after a previous run (and restarting the robot code) the swerve goes a different direction. At one point it was going straight, then it went at around 40 degrees from that, then more.
The autonomous code is in the RobotContainer file. If anyone can help out, that would be amazing.
While I’m not sure that this is the source of the issue, the trajectory that you are following is slightly concerning. It is trying to move 0.1 meters to the right while turning 180 degrees.
The robot most likely won’t be able to do that, so it could cause unwanted behaviors.
From reading the code, I’m not entirely sure what the error is off the top of my head. However, here are some tools for your toolbox to debug this:
When you move the robot a meter forward in teleop, does it move a meter forward according to the odometry? It’s easiest to check using Field2d. You can also put the trajectory on it to check what it wants to do. The Field2d Widget — FIRST Robotics Competition documentation
Is your forward correct? Again a odometry verification thing, because generally that’s going to be the largest deciding factor in whether your autonomous works.
The third thing is to make sure it’s actually possible to complete the trajectory in the way you specified. Be aware, SwerveControllerCommand uses the same type of trajectory as for a differential drive base, so it generates only trajectories that are possible for a differential drive. The largest issue with this that you’ll notice is that you have no control of heading independently of the translation and it will try to drive in splines instead of “point a to point b”. I usually use a trajectory of 3 meters forward first, then add a 90 degree turn afterwards for testing.
As a sidenote, you may want to run an auto formatter on your code. It’s a bit hard to read with the inconsistent indentation, and don’t be afraid of just a little bit of whitespace to allow your brain to break up chunks of code while reading.
Thanks for the response. Something I noticed was that the odometry was completely wrong. It would return values that were much too higher, so the field2d widget would fly out of the image the second I moved the robot. Instead of using the pose estimation from the odometry, I just inputted the displacement from the gyro (gyro.getDisplacementX() and getDispalcementY()), and the distance seems to be more accurate.
However, the robot is still sometimes going diagonally when it’s supposed to go in one axis.
Even in teleop mode, both x and y displacement values from the NavX go up when I only drive the robot in one axis. Is this anything you’re familiar with?
The reason for putting 0.1 meters was because the robot was going substantially farther than 0.1 meters. It went around 0.9-1.3 meters when I input that distance.
It is unwise to only use gyro input just so you know… I’d recommend figuring out how to fix the odometry (I’d imagine it’s likely in your gear ratios, but it could be a few other things)
The gyro will quickly drift away from the real values in a match, although it’ll work in the extremely short term. Feeding in the wheel positions is much better, because it isn’t as “far” from the real positions (your gyro is measuring acceleration, which is being used to calculate velocity, which is being used to calculate position, with a certain amount of error at each step, if I’m wrong someone please correct me).
Another odd detail I noticed is that your swerve module class is returning distance rather than velocity in getState
.
As in, you are using getSelectedSensorPosition
rather than getting the velocity. Changing that should fix the odometry problem, which should help you get to a better starting place.
Also, next year the odometry class will require module positions rather than their velocities, so the position will be something to revisit after the initial code release.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.