A place to show off your knowledge of encoders

[jwakeman]

Lots of questions regarding encoders and how to interface them with WPILib but I'll try not to dump too many questions in here all at once. There are 4 types of encoders I have seen. I will name each encoder and give either what I think I understand and/or my questions for that sensor. Feel free to answer piecemeal, just quote the question your answering.

1. US Digital E4P

This one looks like it is only for use with the Andy Mark gear box. I've decided to forget about this one since I'm not using that gearbox in this application. Good?

2. Gear tooth sensor

This is the one that is pictured in the "C/C++ Programming Guide" for WPILib. This sensor only uses one digital input. I should use it with the GearTooth class. I can call the Get() and GetPeriod() methods from the Counter class it inherits from to get the count and rate respectively. I'm not sure if I can sense direction or not with this one. I was under the impression you need an A and B channel to sense direction. I see one comment in GearTooth.h that says "but in future versions we might implement the necessary timing in the FPGA to sense direction." But then I see a function named EnableDirectionSensing(). I'm leaning toward the comment being stale. If so then I should be able to call GetDirection() from the Counter class as well. Should this sensor only be used with gears that are in the FRC KOP due to the spacing/shape/number of teeth? Or will it generally work with any gear with ferrous teeth?

3. Magnetic rotary encoder

Does the WPILib support this one yet? In the "2011 FRC Sensor Manual" it says this sensor can be used in applications that typically used quadrature encoders. However the different interfaces it lists don't seem to match up with the Encoder class in WPILib. It talks about a serial interface which is staring to look like it would involve using the I2C class. It looks like this mode would take up 4 digital I/O slots on a digital module. I'm not sure what the address refers to in DigitalModule::GetI2C(UINT32 address). I see the device takes a 5-bit READ Angle command that would return 16-bits. How would this line up with the methods in the I2C class? Is the 5-bit command the registerAddress in I2C::Read(UINT8 registerAddress, UINT8 count, UINT8 *buffer)?

4. Linear Encoder with magnet strip

This one has the familiar A and B channel and seems like it would match up nicely with the encoder class. Is that magnet strip intended to only be laid out flat? Or can I wrap it around a shaft or sprocket that I am trying to measure the pulses on?

Thanks!

[jhersh]

Originally Posted by jwakeman

1. US Digital E4P

This one looks like it is only for use with the Andy Mark gear box. I've decided to forget about this one since I'm not using that gearbox in this application. Good?

Fair enough. The AndyMark gearboxes are surely easy to use with them. Certainly not the only place they could be used, but other places you would have to fashion the correct sized shaft and mounting holes to use it.

Originally Posted by jwakeman

2. Gear tooth sensor

This is the one that is pictured in the "C/C++ Programming Guide" for WPILib. This sensor only uses one digital input. I should use it with the GearTooth class. I can call the Get() and GetPeriod() methods from the Counter class it inherits from to get the count and rate respectively. I'm not sure if I can sense direction or not with this one. I was under the impression you need an A and B channel to sense direction. I see one comment in GearTooth.h that says "but in future versions we might implement the necessary timing in the FPGA to sense direction." But then I see a function named EnableDirectionSensing(). I'm leaning toward the comment being stale. If so then I should be able to call GetDirection() from the Counter class as well. Should this sensor only be used with gears that are in the FRC KOP due to the spacing/shape/number of teeth? Or will it generally work with any gear with ferrous teeth?

You can't sense direction with most gear tooth sensors, but there are a few that can. I believe the geartooth sensor class doesn't support that, but the FPGA and the Counter classes support it. You just need to use the kPulseLength mode. Generally works with any gear that fits the specs of which ever geartooth sensor you choose.

Originally Posted by jwakeman

3. Magnetic rotary encoder

Does the WPILib support this one yet? In the "2011 FRC Sensor Manual" it says this sensor can be used in applications that typically used quadrature encoders. However the different interfaces it lists don't seem to match up with the Encoder class in WPILib. It talks about a serial interface which is staring to look like it would involve using the I2C class. It looks like this mode would take up 4 digital I/O slots on a digital module. I'm not sure what the address refers to in DigitalModule::GetI2C(UINT32 address). I see the device takes a 5-bit READ Angle command that would return 16-bits. How would this line up with the methods in the I2C class? Is the 5-bit command the registerAddress in I2C::Read(UINT8 registerAddress, UINT8 count, UINT8 *buffer)?

It supports in several ways. The serial interface would work with SPI, not I2C. There is also a duty cycle output that you can read with the Counter class. There is also a filtered output of the duty cycle that can be read via the analog input (this is the configuration that has pins wired by default). The last method (I know... there are a ton) is the sin cos test mode. I personally think this is the best way to interface it. You need to do a bit of soldering to enable that mode, but you would then wire the sin and cos signals to the analog input. Those then are configured with 2 analog triggers. and the outputs of those are hooked up to a quadrature decoder. Awesome!

Originally Posted by jwakeman

4. Linear Encoder with magnet strip

This one has the familiar A and B channel and seems like it would match up nicely with the encoder class. Is that magnet strip intended to only be laid out flat? Or can I wrap it around a shaft or sprocket that I am trying to measure the pulses on?

Yes... the A and B hook up the same way as a typical encoder. You can use the index to figure out if the magnet is in range too.

You could wrap the strip around a shaft, but if you want it to turn 360 degrees, the interface would be shaky. You can get circular strip as well (or so the data sheet claims).

-Joe

[jwakeman]

Well I was just amount to post a reply to my own thread lamenting the fact that I hadn't received any replies yet..but you beat me to the punch Joe!

I believe the geartooth sensor class doesn't support that, but the FPGA and the Counter classes support it. You just need to use the kPulseLength mode.

I do see that the GearTooth class is calling Counter::SetPulseLengthMode()

void GearTooth::EnableDirectionSensing(bool directionSensitive)
{
	if (directionSensitive)
	{
		SetPulseLengthMode(kGearToothThreshold);
	}
}

where kGearToothThreshold is defined as 55e-6. So its looking like this class IS setup for direction.

The serial interface would work with SPI, not I2C.

This I figured out on my own today and I just finished up the first draft of a class for implementing the SPI interface with the sensor. I uploaded the project to our repository (http://code.google.com/p/first-team63/source/browse/#svn%2Ftrunk%2FDevelopment%2FApps%2FcRIO%2FAS5030_ SPI). I can also attach the code here as a zip if anyone requests. Joe, I would appreciate your comments on this code if you have a moment to look over it. I used the sample code in one of the specs as a reference. One thing I wasn't sure about was a function they were using called DIO_HIGH_IMP() that they didn't show the definition of. This function was to change the mode of the DIO pin to input mode. I just kinda left this out of my code and i am hoping that is ok because we are using the DIO pin as output only in the 4 line configuration.

The last method (I know... there are a ton) is the sin cos test mode. I personally think this is the best way to interface it. You need to do a bit of soldering to enable that mode, but you would then wire the sin and cos signals to the analog input. Those then are configured with 2 analog triggers. and the outputs of those are hooked up to a quadrature decoder. Awesome!

I think I will see how my SPI interface treats me before I dive into this one! I am gathering though that the AnalogTrigger and AnalogTriggerOutput class would somehow be used to create a simulated DigitalInput to pass to the Encoder class? This one looks tough...

[jhersh]

Originally Posted by jwakeman

This I figured out on my own today and I just finished up the first draft of a class for implementing the SPI interface with the sensor. I uploaded the project to our repository (http://code.google.com/p/first-team63/source/browse/#svn%2Ftrunk%2FDevelopment%2FApps%2FcRIO%2FAS5030_ SPI). I can also attach the code here as a zip if anyone requests. Joe, I would appreciate your comments on this code if you have a moment to look over it. I used the sample code in one of the specs as a reference. One thing I wasn't sure about was a function they were using called DIO_HIGH_IMP() that they didn't show the definition of. This function was to change the mode of the DIO pin to input mode. I just kinda left this out of my code and i am hoping that is ok because we are using the DIO pin as output only in the 4 line configuration.

Looks like you are bit-banging the SPI interface. There is an SPI engine built in to the FPGA that will do this stuff for you and will be much faster. The functions to access it are in the ChipObject dir in the WPILib source. This is a pretty difficult interface to use, though... it's just the register interface. Thanks to the contributions of Peter Johnson from team 294, the next WPILib for C++ update will include an SPI class that is easier to use. You may want to consider holding out for that.

Originally Posted by jwakeman

I think I will see how my SPI interface treats me before I dive into this one! I am gathering though that the AnalogTrigger and AnalogTriggerOutput class would somehow be used to create a simulated DigitalInput to pass to the Encoder class? This one looks tough...

Fair enough. The AnalogTrigger will give you AnalogTriggerOutput objects which if you look at their header file, inherit from DigitalSource. The Encoders take DigitalSource type objects as parameters for the A and B channels.

-Joe