Gear tooth sensor vs. Optical Encoders

[Avarik]

I was wondering if anyone has tried using the gear tooth sensors from the KOP, and knows how well they work? I've used optical encoders before, and know those work well. So how does the gear tooth sensor compare, in terms of accuracy? If it matters, I'm planning on using one of these two sensors for robot speed and speed our launcher system is spinning.

Also, can the gear tooth sensors sense the direction of the spin, or just velocity?

And...while I'm at it...how does the accelerometer compare to these when trying to see robot velocity?

[Don Reid]

Originally Posted by Avarik

Also, can the gear tooth sensors sense the direction of the spin, or just velocity?

According to the datasheet, this sensor outputs a 45 us pulse for one direction and a 90 us pulse for the other. I think you can detect this difference with the uP.

If you only want to know the speed of rotation though, just the number of pulses in a fixed period of time is enough. A simplified version of the encoder code could count pulses (in an interrupt function) without worrying about the other input.

[BradAMiller]

Originally Posted by Avarik

I was wondering if anyone has tried using the gear tooth sensors from the KOP, and knows how well they work? I've used optical encoders before, and know those work well. So how does the gear tooth sensor compare, in terms of accuracy? If it matters, I'm planning on using one of these two sensors for robot speed and speed our launcher system is spinning.

Also, can the gear tooth sensors sense the direction of the spin, or just velocity?

And...while I'm at it...how does the accelerometer compare to these when trying to see robot velocity?

The gear tooth sensors work, but it very difficult to get the difference between forward and backwards rotation. As was said, the way to tell is the length of the pulse that is returned. The time in/out of an interrupt service routine is pretty long - especially if you have to save the floating point data area and the temp data areas.

I've been very successful using them to detect pulses, but the direction is very unreliable. In EasyC and WPILib they are currently just counting pulses. I hope to have a new version out soon that will count up and down for clockwise/counterclockwise.

Brad

[eugenebrooks]

Originally Posted by Avarik

I was wondering if anyone has tried using the gear tooth sensors from the KOP, and knows how well they work? I've used optical encoders before, and know those work well. So how does the gear tooth sensor compare, in terms of accuracy? If it matters, I'm planning on using one of these two sensors for robot speed and speed our launcher system is spinning.

Also, can the gear tooth sensors sense the direction of the spin, or just velocity?

And...while I'm at it...how does the accelerometer compare to these when trying to see robot velocity?

We used the kit gear tooth sensors last year, mounting them in recommended circuits on PC boards we laid out and etched. We had no problems with them. We never considered picking up the direction signal, but if you want to do this without concern for problems with the interrupt service latency you can build some custom electronics that looks at the pulse width and selects one of two outputs to send the pulse out on, one for forwards and one for backwards. A little electronics work, but do-able.

[Avarik]

Alright, thanks! That was very helpful.

I set these sensors up with interrupts, right? Or is that not possible with the analog inputs..?

And can someone point me to the documentation please?

[Joe Hershberger]

Originally Posted by Avarik

Alright, thanks! That was very helpful.

I set these sensors up with interrupts, right? Or is that not possible with the analog inputs..?

And can someone point me to the documentation please?

The interrupts on the analog inputs only tells you when the analog conversion is complete. That will not help you for measuring the GTS.

You want to use an External Interrupt. Several of the digital lines are wired to external interrupts on the user processor. When you configure these interrupts, you specify which edge you want to be active. If you leave this configuration alone, then you will receive one interrupt for each pulse and you can measure the speed from the GTS with a timer.

If you are interested in measuring the direction as well, you can add an instruction in your Interrupt Service Routine (ISR) to switch the active edge. This way when the signal changes again, you will get another interrupt. In this case, you will get 2 interrupts per pulse from the sensor.

You can use the timer and some integer math to measure the time between the rising and falling edge to allow you to determine the direction of the gear, then you can also measure the time between one rising edge and the next to determine the speed of the gear.

To time the events, you can simply setup a counter to a speed that will not overflow for the measurements you'd like to make, but that also will give you good resolution. Each time you get an interrupt, save the value in the counter. Also, before saving it, subtract the last timer value that was saved from the current timer value. This will give you the change in time. Save that as well. You can then use the numbers elsewhere in your code to compute the speed. If you want to compute direction as well, the you'll need to store two old values.

Best of luck!
-Joe

[Joe Hershberger]

Originally Posted by BradAMiller

The gear tooth sensors work, but it very difficult to get the difference between forward and backwards rotation. As was said, the way to tell is the length of the pulse that is returned. The time in/out of an interrupt service routine is pretty long - especially if you have to save the floating point data area and the temp data areas.

I've been very successful using them to detect pulses, but the direction is very unreliable. In EasyC and WPILib they are currently just counting pulses. I hope to have a new version out soon that will count up and down for clockwise/counterclockwise.

Brad

Brad,

When using interrupts on this microcontroller, remember that it has no floating point support in hardware. It only has 8 bit integer support. The larger the integer you use, the more instructions are required to do anything with it. Floating point is even worse.

In general, when writing an handler, you want to split the work into two pieces.

In the actual Interrupt Service Routine (ISR), you want to do the least work that you can get away with. In this case, simply subtracting from the last stored value and then storing off the timer value for next time. You want to do only what must be done to save the information about what happened.

The other half of the processing is done in a Deferred Procedure Call (DPC). In here, you can do your floating point division to figure out the actual speed. At the end of your ISR, you need to set a bit in memory somewhere that you will check in you code elsewhere... probably in the user_routines_fast() function. If the bit is set there, then you want to call your DPC function to finish the work on the new raw data.

Using this structure, you will avoid saving off the floating point registers when entering your ISR, will have more accurate timing, and far less interrupt time overall. This will make the rest of your processor more responsive and you will be able to handle far more interrupts on the processor without problems.

Good luck!
-Joe

[Joohoo]

Originally Posted by BradAMiller

I've been very successful using them to detect pulses, but the direction is very unreliable. In EasyC and WPILib they are currently just counting pulses. I hope to have a new version out soon that will count up and down for clockwise/counterclockwise.

One way to make this work is to trigger a timer and since one direction sends a 20something microsecond pulse and the other sends about a 83 microsecond pulse have the timer go for 60 microseconds and the check if the pulse is present you can then add or subtract to your count accordingly