I am new to using odometry and currently have a differential drive with encoders and a gyro working great in the simulator. Running trajectories, teleop, etc. wroks great and I am planning to present this as the way to code autonomous for our team this year. However, how do I go about coding in the charge station as an obstacle? I really want to drive over the charge station in autonomous and possibly in path-assisted teleop routines to get over to the grid. Since it is raised, it will change the readings on the encoders, leading to our autonomous routine being off.
Is the only way to overcome this to code in offsets for the autonomous paths that bring you farther to compensate?
I was thinking of using 3D PNP via AprilTags for visual odometry, and maybe I can replace the encoder readings with that pose and clear the encoders after I go over the charge station?
Any help would be greatly appreciated, my team’s only experience with odometry is with a Romi.
I am not the right person to answer the bulk of your question, but in addition to the path length being longer over the charge station you are likely to see different wheel slip on the polycarbonate vs carpet. This has been talked about on a couple of the drivetrain threads for this season.
Just sticking that extra variable into the mix if you hadn’t already planned for it.
The path is longer going over the charge station, but that’s because you’re moving in 3D. If you have a 3D IMU and your wheels don’t slip, the odometry and pose estimator classes could be extended to work for that use case. Might be hard to implement for those not familiar with the internals though (that’s why we write library abstractions).