pic: Encoders and AndyMarks, 341 Style

[Billfred]

loading photo ...

[Kyle Love]

The TechnoKats used the gear tooth sensors last year in our gearbox, I'll look to see if I have any pics of it. Basically we mounted it to the gear box and covered the top of the gearbox with lexan.

[Lil' Lavery]

If you use live axles, you can mount it on the drive axles.
If you run chain, you can add an extra sprocket along the length of the chain and an encoder to that (http://www.chiefdelphi.com/media/photos/25474).

[OZ_341]

Just as a side note this system worked very well, so we did it again on our 2006 machine. We used the encoder data for automatic shifting and for steering adjustment.

Just wanted everyone to know that they were looking at a configuration that works.

Thanks!

Al Ostrow

[dlavery]

Originally Posted by OZ_341

Just as a side note this system worked very well, so we did it again on our 2006 machine. We used the encoder data for automatic shifting and for steering adjustment.

Just wanted everyone to know that they were looking at a configuration that works.

Thanks!

Al Ostrow

Al -

I jsut want to check to be sure I am understanding the photo. It looks like the sensor is mounted on a tab attached to the top of the shifting gearbox, and the tab is angled so that the teeth of the gear mounted on the encoder mesh with the driven gear at an angle (i.e. the gears do not mesh across the full face width, but only at the corner of the driven gear). Is that correct? That also appears to be one of the Greyhill encoders. What is the rotational resolution of the encoder you used?

-dave

[OZ_341]

Originally Posted by dlavery

Al -

I jsut want to check to be sure I am understanding the photo. It looks like the sensor is mounted on a tab attached to the top of the shifting gearbox, and the tab is angled so that the teeth of the gear mounted on the encoder mesh with the driven gear at an angle (i.e. the gears do not mesh across the full face width, but only at the corner of the driven gear). Is that correct? That also appears to be one of the Greyhill encoders. What is the rotational resolution of the encoder you used?

-dave

The answer is yes to the configuration question. We had acceptable contact between the gears, but not great. We saw some wear due to this intentional misalignment, but there was not much force on the encoder gear so it was not too bad.
The answer is also yes to the Greyhill question.
I will have to look up the resolution or ask one of our kids on the programming team. Its probably on the spec. sheet. I am a hopelessly mechanical kind of guy!

I'll ask and report back.

[dlavery]

Originally Posted by OZ_341

The answer is yes to the configuration question. We had acceptable contact between the gears, but not great. We saw some wear due to this intentional misalignment, but there was not much force on the encoder gear so it was not too bad.
The answer is also yes to the Greyhill question.
I will have to look up the resolution or ask one of our kids on the programming team. Its probably on the spec. sheet. I am a hopelessly mechanical kind of guy!

I'll ask and report back.

OK, thanks. The reason I asked about the rotational resolution of the encoder is that with enough encoders at a high-enough resolution, they can generate an interrupt stream fast enough to overwhelm the RC if you tried to keep up with every encoder count. I am curious about what you found to be a reasonable balance between resolution and RC response time.

-dave

[OZ_341]

Sounds like a good question for Jared, our programming mentor.

I'll let you know.

[Kingofl337]

Team 40 ran 4 128 Line Greyhill Encoders direct drive with four 8" mecanum wheels we had a max speed of 10 FPS last year and it didn't seem to overwhelm the processor. We probably could have gotten away withe 64 line units and have been accurate enough to accomplish most positioning goals.

We also used the camera for aligning with the target. Which generates allot of interrupts while running I think I heard in the range 11520 a second.

[Alan Anderson]

Originally Posted by Kingofl337

We also used the camera for aligning with the target. Which generates allot of interrupts while running I think I heard in the range 11520 a second.

You heard wrong. Stop repeating this misinformation. It's only a few hundred characters per second at full tilt.

[Mike Bortfeldt]

Dave,

For the past 2 years we have used an identical setup in our transmissions that works fairly well. We have a 128 count quadrature encoder on the output shaft of each transmission interrupting on the A channel, rising edge only. Free spinning speed equates to around 2400 interrupts/sec, but under load is only around 2000 interrupts/sec at maximum speed. With the wheel diameter we have used the past 2 years, this gives about 190 counts/foot traveled. When calculating speed each 26.2 millisecond loop, we get an "instantaneous" velocity resolution of around 2 inches/sec. Just from a personal standpoint, I would like a little better resolution (without averaging over a longer period of time) of closer to 1 inch/sec, but I can't really say I've seen any problems with the current setup (maybe around 3000-3200 interrupts/sec would be "ideal" for us).

As far as RC loading, our 2006 bot had around 12,000+ interrupts/sec worse case without a problem (gut feel of around 20-30% cpu loading max due to interrupts - drive encoders, shooting wheel encoder, internal 250 microsecond clock, analog port scanner, serial port communication). While the number of interrupts/sec is certainly a factor in RC loading, more important ones are the interrupt context saving and the amount "work" performed in the ISR. Having to save the .tmpdata or MATH_DATA sections can add a significant amount of execution time to each interrupt and should be avoided if possible.

Mike

[BrianBSL]

Originally Posted by Alan Anderson

You heard wrong. Stop repeating this misinformation. It's only a few hundred characters per second at full tilt.

But the baud rate is still 115k - which is 14400 characters per second (rate). The total number of characters you get in one second is irrelevant, because for the period you are getting a message from the camera you are getting interrupts at that rate if that is the defined serial rate. Over an entire match it may not average this - but average doesn't count for ISR's if when it happens once (say at the same time you are getting a lot of encoder interrupts) when it matters most.