Encoder Code

[Kevin Watson]

Originally Posted by farmer

Kevin,
Does your encoder code work with the GTS provided this year (seeing you don't have specific GTS code posted yet). Reading thru your encoder code it sounds like you have programmed several of the things we wanted to do this year. Thanks for your help as always.

Yes, just use interrupts one and two and remove the phase-b sensing code.

-Kevin

[Jon236]

Originally Posted by Kevin Watson

Yes, just use interrupts one and two and remove the phase-b sensing code.

-Kevin

So, so much for the GTS sensing reverse direction.......we're using Hall effect sensors (paired with one slightly offset for phase-b) and they're working great

Jon Mittelman
Team236

[Astronouth7303]

Originally Posted by Jon236

So, so much for the GTS sensing reverse direction.......we're using Hall effect sensors (paired with one slightly offset for phase-b) and they're working great

The kit GTSs can do direction (different size pulse in each direction), it's just that the pulse is so short that I don't bother. Plus, we never expect our motors to go the wrong way. (Meaning: If they were, we'd have larger issues.)

[farmer]

Originally Posted by Kevin Watson

Yes, just use interrupts one and two and remove the phase-b sensing code.

-Kevin

Thanks a bunch! We will give it a try.

[tseres]

question: in the encoder code, how can it tell velocity? do i have to count the ticks over a certain time? an example is if i have an encoder on my two drive wheels and i want them to go the same speed. i would know how to adjust the motor speed, but how do i get the actual wheel velocity from the encoder?

[ericand]

Originally Posted by tseres

question: in the encoder code, how can it tell velocity? do i have to count the ticks over a certain time? an example is if i have an encoder on my two drive wheels and i want them to go the same speed. i would know how to adjust the motor speed, but how do i get the actual wheel velocity from the encoder?

ticks/time is the way to go. The velocity is a translation of ticks to wheel
circumference. It helps if you have a fair number of ticks/rev so you can keep the time interval short. Otherwise, it is hard to differentiate stopped (0 velocity) from very slow. A short interval also reduces issues raised by velocity change during the counting interval. The problem with large # of ticks though is you get flooded with interrupts if the robot is moving quickly.

You need to optimize based on what you want to accomplish. Understanding what you are using the velocity value for (and how accurate you need it to be) should be a driving factor in setting up your encoder code.

[tseres]

also, do i have to use kevin's code with all of the initialization? or could i make my own based upon the phase a and b on the digital inputs?

*EDIT*
is there also a way i could have the encoder counting in the background of my code? or does it do that already....if not, how (if possible).

from looking at the code, do i also have to reset the encoder count? do i also have to manually make the ENCODER_x_COUNT increment every time the encoder ticks?

[ericand]

Originally Posted by tseres

also, do i have to use kevin's code with all of the initialization? or could i make my own based upon the phase a and b on the digital inputs?

*EDIT*
is there also a way i could have the encoder counting in the background of my code? or does it do that already....if not, how (if possible).

from looking at the code, do i also have to reset the encoder count? do i also have to manually make the ENCODER_x_COUNT increment every time the encoder ticks?

You really want to use the interrupt capability (Digio 1, 2) for the Phase A.
I suppose you could do it without interrupts, but you would have a lot of overhead and I don't think you would be able to get the accurate counting that you need.

If you are not familiar with interrupt service processing, I would say use Kevin's code with as few modifications as possible. As you understand more about how it works, then experiment with changes.

Kevins code has the encoder tick counting handled at interrupt level, so it is done effectively "in the back ground". Note that the encoder count is incremented (of decremented) in the ISR. (Interrupt Service Routine)

The question about resetting the encoder count depends on what you want to do, and how many ticks you are expecting. I generally find that using a "long" to store the count will let me count for way more than the amount of ticks I could get during a match time. This does mean that you need to store copies in routines that are measuring an elapsed distance.

Note also that I use "long" and not "unsigned long" since the code counts backwards when (negative) when the drive is reversed. If you have a system with encoders where you can not detect rotation direction, you may want to zero the count whenever you stop.

To compute velocity, one of the timers can be used to provide accurate interval info. Based on the timer, you can run a routine periodically that computes the velocity over the time interval.

[AdamHeard]

I know it's been a while, but I'm designing the ratios for our prototype base now....

how many interrupts per second can the processor handle?

Our highest gear puts the encoder shaft at about 1500 rpm. We're using the grayhill 128's that Kevin reccomends (because we already have them) and that puts out a lot of counts per second , 1486.6 [rpm] / 60 [seconds/min] * 128 [counts/rev] = 3172 counts per second!!!, and that's only one side. That seems like way too much to me.

can anyone confirm this?

Just saw grayhill offers lower res in the same package. Both the 32/25 look good with 793 and 620 interrupts per second at full speed in high.

Still, I would like to know what the processor can handle.

[ay2b]

Originally Posted by AdamHeard

how many interrupts per second can the processor handle?

As I recall, it can handle somewhere in the 5000-7000 range. Keep in mind though, that your encoders will probably not be your only interrupt events. Serial communication (i.e. to the camera) & ADC conversions both also count as interrupts. You may also just have a clock running for other timing.

Originally Posted by AdamHeard

Our highest gear puts the encoder shaft at about 1500 rpm. We're using the grayhill 128's that Kevin reccomends (because we already have them) and that puts out a lot of counts per second , 1486.6 [rpm] / 60 [seconds/min] * 128 [counts/rev] = 3172 counts per second!!!, and that's only one side. That seems like way too much to me.

Something else to consider: where are you putting your encoder, relative to the motor, gearbox & wheel? I would suggest putting it close to the wheel.

Let's suppose you have 10" diameter wheels (fairly large by FIRST standards). That means you have a 31.4" circumference. If that's in a 1:1 ratio with your encoder at 128 ticks per revolution, that means you get an encoder tick every 1/4" of linear movement. That should be sufficient. (I usually aim for 1/4"-1/2" per tick, which has always been more than enough.)

Suppose instead, you have very small wheel - 12" circumference (about 4" dia), and a very fast robot - 20 ft/sec. That means you get 128 ticks per linear foot, and 2560 ticks per second (and 0.1" per tick) at full speed. Double that to count both sides, and you're only at 5k interrupts per second, assuming you're traveling at full speed with both wheels.

If your robot is at a more reasonable speed in the 10-14 ft/sec range, and your wheels are typical FIRST wheels in the 4"-8" dia range, and you have a 1:1 ratio between the encoder and the wheels, at 128 ticks/rev you'll have a good balance among ticks/second, ticks/inch and total interrupts.

[AdamHeard]

We're using all dead axles so It's far easier to mount it on the gearbox output shaft. There is a either a 12/28 or 16/28 (depending on how many motors were using in the drive) reduction. The stats above are for the 16/28. Also, the res for above is .33 and .43 inches. [also, the sprocket ratio only effects the resolution]

I think we'll go with 64 counts. That gives us about 1586 ticks per second (per side) and a res of .17 inches. That leaves plenty of interrupts open for possible future addons.

Does that sound good?

[Doug G]

We used the 64 Grayhill encoder back in '06 with the speed of our shooters (~1300 rpm) and they worked pretty well for us. We stayed away from the 128 model, way too much resolution at that speed, expecially for that application where all we needed was velocity, not position.

[emersont49]

I read the encoder_readme.txt and encoder.h files but I didn't find out how to disable unused counters. I tried commenting out the ENABLE_ENCODER_X entries in encoder.h but that didn't work.

Any details on how to disable unused encoder channels?

Thanks again Kevin. I'm really looking forward to using this.

[Tom Bottiglieri]

Originally Posted by AdamHeard

I think we'll go with 64 counts. That gives us about 1586 ticks per second (per side) and a res of .17 inches. That leaves plenty of interrupts open for possible future addons.

Does that sound good?

You could cut the number of interrupts you are handling down by about a factor of 4 or 5 and see absolutely no change in performance. I would bet my shiny new iPhone that no FIRST robot ever has, or ever will, be accurate to 0.17". You may want to shoot for a resolution of .5 or 1 inch. It will drop the the cost of your hardware solution and save your programmers a whole bunch of headache. While the amount of interrupts you are looking at are in the theoretical limits of what the PIC can handle, your program will have to be very robust and optimized to not crash the system.

[Kevin Watson]

Originally Posted by emersont49

I read the encoder_readme.txt and encoder.h files but I didn't find out how to disable unused counters. I tried commenting out the ENABLE_ENCODER_X entries in encoder.h but that didn't work.

Any details on how to disable unused encoder channels?

Thanks again Kevin. I'm really looking forward to using this.

It seems the encoder_readme.txt file directs you to instructions in the encoder.h file that I forgot to include . Until I get around to fixing this, you should be able to disable individual channels by commenting out the associated #define ENABLE_ENCODER_n line in the encoder.h file.

-Kevin