Chief Delphi - calculating distance

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - calculating distance (http://www.chiefdelphi.com/forums/showthread.php?t=45039)

calculating distance

My team needs to be able to calculate distance, We first used a shaft encoder, we later learned that the shaft dosn't turn with the wheel. So any ideas?

Re: calculating distance

trial and error . . thats what we did.

(edit)
if your talking about shooting that is.

Re: calculating distance

.. because of your phrasing im not sure if your talking about shooting distance or the distance your robot travels in autonomous mode.

If I'm correct in thinking that your talking about driving distance in autonomous mode, there are quite a few options to find the distance your traveling, the first is encoders, which you say your having trouble with.

You can also try to use timer interrupts, but if your having trboule with that, you can just count program loops. Each loop is 26 milliseconds, so depending on you robots speed you can estimate the loop count you need to travel a certain distance, and then jsut test your autonomous mode to perfect it.

Re: calculating distance

If you are talking about distance driving or distance shooting, and a shaft encoder doesn't do the trick for you, here are some options that my team has explored in the past in similar situations:
1) Try mating the encoder to a different part of your drive train.
On my teams robot, rather than attaching the encoder to the axle that supports the wheel, we used our encoder to count revolutions of a gear in our transmission.
2) Optical encoders.
Because the shaft doesn't turn with the wheel, measuring the shaft, as you pointed out, wouldn't help much. However, you can, for a slightly less accurate measurement, use an optical encoder and some reflective tape.
3) Trial and Error with timers
As noted, possible, but time consuming in the "lets-try-it-out" department. An option not to be discounted, but not what I'd take as my first route.
4) Hall-effect sensors.
FIRST does include hall-effect sensors, which can count gear teeth, but I've heard mixed results about their implementation.

If you are trying to calculate driving distance, you only need the encoder and a known starting position (use a 3-position switch to accommodate for each starting box). Also, keep in mind that in their most simple implementation, these sensors act as courters; they are independent of direction. Hope this helps.

-Mike, Team 341

Re: calculating distance

Well, because you didn't state what you wanted to calculate the distance to, I'm going to assume it is the center goal.
If you are using a camera, track the light and use the camera's tilt angle (and a bit of trig) to determine the distance.
i believe the formula was

Code:

distanceToTarget = heightOfLight*tan(camTilt);

Re: calculating distance

If you're talking about distance to the target, you can use the camera tilt angle (not very reliable or accurate), or you can use the camera's reported blob size.

If you take an average of the camera's blob size over several cycles (2-3 seconds of summing), you can get a pixel count that is effectively accurate to about 0.01 pixels. Once you know, for example, that you can see 5.27 pixels from your current position, you can plug that into an empirically derived equation to determine your distance in whatever units you want.

So here's what you can do:
1. Write code that sums up the blob size over the last 100 robot cycles
2. Have the code print out the sum of the last 100 cycles, and record this value
3. Measure the distance your robot is from the target, and record that value next to the value from step 2
4. Write the distance and sum down, and repeat for varying distances
5. Put all these (sum,distance) pairs into excel, and have it generate a matching function for you (our best fit was a polynomial).

Example data:

Code:

Pixels        Distance

5.27        8m

5.70        7m

5.95        6m

We ended up collecting five pixel sizes for each distance, and spaced the distances 25cm apart from 8m to 4m.

Once you have this polynomial function, you can use it to take a sum or average of blob sizes and turn it into a measured distance with great accuracy.

The problem with trig is that moving 1 foot when you're 10 feet away doesn't change the angle very much, and as such, you won't get a very accurate distance measurement. We tested this method, and it's accurate to about 10 centimeters. You can also make it variably accurate, depending on how much time you have to measure the blob size. The problem with the blob method is that when you're off to the side, the blob will be artificially smaller without decreasing the distance. However, if you're so off to the side that that is a big issue, you probably won't make the shot anyway.

Re: calculating distance

We used a gear tooth sensor on a wheel sprocket. Then divide the circumference of the wheel by the number of teeth to get "inches per count"

Then Easy C made it easy to program. :)

Re: calculating distance

I was talking in general, we needed the shaft encoder to find the distance to a point in autonomus mode. We used the Gyro to find direction, y-accelemoter to find tilt angle, and tried to use the shaft encoder to find distance to a point on the field.

Re: calculating distance

Quote:

Originally Posted by sur2124

why didn't you use another gyro to find the tilt angle? it makes things a bit easier :)

anyway, if you want to calculate distance (without using the camera), you might want to use that encoder.
the encoder counts can be extremely useful, (AFAIK) they count more times per revolution then a GTS can, and (once again, AFAIK) they miss less counters then a GTS.

anyway, what you have to do is figure out the amount of counts per revolution, and then how far each revolution makes the robot go. as far as I'm concerned, this is simple math.
once you have figured that out, assign a PWM value and count up to that value. you might have to use a bit of PI or PID to make sure that the robot will STOP at the desired length, but counting the encoder output is definitely a good idea.

If you are trying to discover position, then you would have to take into account the GYRO angle. By doing this (and a bit of trig i think) you can determine the position of the robot on the Field.

Re: calculating distance

Quote:

Originally Posted by sur2124

That should be pretty easy then. All you need to do is find out how many encoder ticks you get per revolution of the wheel. With that information, you can convert that to ticks per inch. From there you should be able to determine how many ticks you need to go a certain distance.

Edit: This is similar to what Uberbots posted. Should have read more carefully

Re: calculating distance

As far as saving your encoders- try mounting a small sprocket onto the encoder shaft, and let it run right with the chain.

Be careful though - from what I've heard, encoders don't exactly take kindly to side loads...