Hello everyone! I have implemented the new Ramsete Controller and did the usual S Curve path. However, even though it follows the path pretty accurately, the heading error is around 20 degrees (+/- 5) at its final position.
We are using 6" mecanum wheels and I was wondering if that could be the issue. I am using a differential drive odometry to be able to use the Ramsete Controller for now but I think the slip caused by mecanums’ rollers might be the issue.
I tried to play around with the gains and I noticed that small changes caused it to have either a great heading error at the right x and y point. Changing it caused to have a much better heading error (12 degrees) but less precise x and y coordinates. I will look further into fine-tuning it but I am still not sure if there is anything else causing such a great heading error. Any help would be greatly appreciated.
(We are using Pigeon IMU and four Mag SRX Encoders. We are using the average of both sides to get a more accurate data. Our encoders, gyro and motors are inverted correctly and checked.).
Do not use RAMSETE or differential drive odometry on mecanum. RAMSETE is intended for non-holonomic robots, which is not what you have. The RAMSETE controller can be replaced by a simple PD controller on X, Y, and theta, which is exactly what this example does.
From what I remember, the Ramsete Controller just uses a Pose2D object, which you can get from a Meccanum Odometry class. Granted it probably won’t matter as you are not taking advantage of the holonomic features of meccanum (as @Oblarg mentioned), it would probably pay to use the meccanum version so that you can have it track sideways movement in the future.
Granted this probably won’t solve your initial problem though.
Thanks for the advice! One of the things I thought of was if the slip caused by holonomic wheels might have caused the differential drive odometry to update the pose incorrectly. I was not sure if having a mecanum odometry and the Ramsete Controller would make a difference, but I sure will give it a try. Also, as for the example @pietroglyph mentioned, are there any downsides of running individual PD controllers on x,y and heading with mecanum odometry VS. Ramsete Controller?
So wheels slipping will cause your pose to drift somewhat, I’ve not tried it myself so I don’t know how bad it actually is. I expect under high acceleration tracking will be pretty bad, but you have the same problem when you do a burnout with a skid steer base.
Any autonomous driving I would personally keep the acceleration low to minimise the slipping.
As for running individual PIDs for your X, Y and heading, I don’t see any reason why that wouldn’t work, especially because you have a holonomic base. It could possibly work better than the ramsete, so long as your setpoints are achievable by your robot.
Thinking about it, this is how I would do it initially.
The advantage of a RAMSETE controller is that it is able to ‘cleverly’ correct x, y, and heading errors using only the two DoF that a differential drive robot has. With a holonomic drivebase (such as mechanum), you do not have this DoF constraint, so there isn’t really a reason to use RAMSETE.
That being said, if it is considerably easier/faster to drive forward than it is to strafe with your drivetrain, there may still be a speed or accuracy benefit to using RAMSETE, if you can get it to work.
A very simple mistake that I’ve seen a couple people do is construct a Rotation2d object and provide degrees, not radians. The constructor of Rotation2d wants an angle in radians; to get an angle in degrees, you can use Rotation2d.fromDegrees.
About trackwidth, changing the actual trackwidth in the characterization tool did not change any of my values. (I encountered this very early in the season and have not checked since.) Was this a known issue or was I doing something wrong?
We’re having a similar issue, albeit with a tank drive rather than mecanum, but we have tried track width with both the value given by the characterization suite and our actual track width measured with a tape measure, but it is still ending off. Is there some sort of reason that having the navx not centered on our robot cause an issue, or having two omniwheels on the front of the robot?
This could cause your center of rotation to be located in a different place than you expect it, which can have some odd effects. Keep in mind that all trajectories are relative to the robot’s center of rotation.