Which is the best method for controlling distance in autonomous? IMES are simple to implement but suffer from slippage and static. An undriven wheel with a quad encoder would be more accurate but add more weight. Integrating the values from an accelerometer would be light simple to implement on a robot, and insusceptible to static, but accumulate drift. Timing is the easiest but depends on voltage and batteries. We currently have timing, but battery level makes a huge difference in our Programming skills runs. We had experimented with encoders, but different encoders gave us different readings.
You might consider a combination. Having three encoders and using the average, or the two that agree the most, might give you more avcurate results. In addition, the other available sensors might be helpful in some cases. Consider line followers as a way to tell when you have crossed the halfway point. Even if this is not the entirity of how you measure, you can use it as a reset point on another method, giving less time for error to build up.
Don’t forget about using the line trackers as light sensors! With the field grid of white lines on the grey tiles, commonly you may be able to use the light sensors to have your robot stop at a particular point on the field. A combination of sensors, as mentioned previously, is normally a good idea too. Ensuring a fail-safe or redundancy is wise if something fails.
Bumping against the field perimeter (and possibly having buttons on the sides of your robot to detect this) is a good way to reset accumulated error from accelerometers or encoders. It’s very easy this year with the fence, as you can basically reset one axis every time you dump and hit the fence.
This will most likely reach the either side of the field in under a second of sitting still. And reach the moon within 10 seconds of driving. The simple implementation is so bad that it isn’t worth counting. Which then means that only implementation worth doing is actually really difficult and complicated.
So limiting the acceleration with a constant threshold wouldn’t work. The issue is that sometimes you accelerate quickly for short bursts. Every value on its own is a real possible value. Now imagine if i told you the acceleration was alternating between 0.5m/s^2 and 0 m/s^2. 0.5 and 0 are both possible values. But seeing them in like that makes you think that it is only noise.
You really need a filter that looks at past data.
If you want to see how a filter like this would turn out download this app, its kinda cool. You can see the noise with the raw and the filtered data. Filters will slow down your reaction to change though. (you will think crazy change is noise when it isn’t)