[Jared]

If you're doing something similar to what 254 did in 2014, where you're planning ahead and creating a table of how far each wheel should have traveled and the heading of the robot at every point in time, I would recommend using a gyro.

Our team tried this last year, and I found that even though the encoders would stay on target during the path within a few percent of where they should be and ended within less than an inch of where they should, the robot would often be misaligned by more than 10 degrees at the end of an s-curve. It always turned less than it should.

One way to make this better was to generate a path for a robot that was an inch or two wider than the actual robot, so the wheels would rotate more during a turn. However, we found that there wasn't one width that would work well for every path - we had to guess and check to find different widths for different paths, which defeated the purpose of motion planning.

Our final solution was to use an additional PID controller for a gyro to keep the robot on the right heading. The gyro greatly increased our accuracy and also made the robot less vulnerable to oscillating/going off path when disturbed. The gyro never made it on our final robot because our path was simply a line, but if we did anything more than that, we would have used a gyro.