Best Method for Controlling Distance in Autonomous

VEX V5 Technical Support
1

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.

Which is the most consistent? Which do you use?

2

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.

3

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.

4

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.

5

Just thought this point needed some additional comments. The simplest implementation of an accelerometer is pretty easy to implement.

xPos=0
xVel=0


xAccel = SensorValue[accelX] / CONSTANT;
xVel += xAccel * dt;
xPos += xVel*dt;

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.

6

Agreed. Even resetting with touch sensors against the field perimeter was not nearly adequate for usable data.

I’m still working on my inertial nav side project (using ONLY an accelerometer and gyroscope).

7

@tabor473 is it possible to create a threshold to limit the accumulation of the accelerometer?

8

I was merely saying that the accelerometer would be far easier to bolt onto the robot than a quad encoder :slight_smile:

However, I didn’t realize that it was that poor of an option.

9

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)

https://play.google.com/store/apps/details?id=com.kircherelectronics.accelerationexplorer&hl=en

10