Magnetic encoders? Anybody else having trouble?

[lucybugg101]

My team has decided to use the new magnetic encoders on this years robot, however, we are having lots of trouble getting them to work. We are unsure if it is due to the position of the magnet over the motor or if it is something else. Is anyone else using these encoders and either are also having difficulties or have figured them out? Thanks

[Al Skierkiewicz]

Lucy,
You need to provide part number so we are sure we are on the same page.

[Jon Stratis]

Are you talking about the magnetic encoders from FIRST Choice?

http://www.andymark.com/FIRST-Choice-p/fc13-062.htm

We got a pair, but haven't tried them out yet.

[Peter Randall]

We too are having difficulty with the AS5145B encoder. So far we can't get them to deliver any quadrature signal. We'll keep you posted if we find out why

[Bryscus]

Originally Posted by Peter Randall

We too are having difficulty with the AS5145B encoder. So far we can't get them to deliver any quadrature signal. We'll keep you posted if we find out why

After looking at the data sheet it looks like these are a replacement for a potentiometer, not an encoder. One device returns absolute position, the other returns relative position.

It looks like there are a few different ways to communicate with this chip. One is a digital method much like a SPI device and the other is like it was a pot (a pwm signal through a filter which just gives an analog DC-like voltage out; not sure if the filter to do this is on the PCB though). I don't see connections for quadrature output.

- Bryce

[Al Skierkiewicz]

One fundamental to keep in mind is these devices are intended to give angular info over a 360 degree rotation. These do not replace rotational encoders they are a "rotational position sensor".

[Nikhil Bajaj]

From what the data sheet says, they are supposed to have incremental outputs as well as absolute position output.

How have you wired it up? And have you picked the magnet size/spacing appropriately? Alignment is very important.

[Azrathud]

Originally Posted by Al Skierkiewicz

One fundamental to keep in mind is these devices are intended to give angular info over a 360 degree rotation. These do not replace rotational encoders they are a "rotational position sensor".

That is simply not true. The this year's magnetic encoder allows for absolute and incremental reading. Reading A/B pinouts on the magnetic encoder allows for one to record the 'ticks' the encoder has read for incremental output.

I don't know how the encoder truly works, but one can, with the WPILIB, read the amount of ticks(in one direction) the encoder has moved since the start of the robot's program. The get() function of the Encoder class will give you the ticks (1024 per full revolution of a shaft). Say you move the shaft 3 revolutions counterclockwise since the start of the encoder class; the get() function would read 3072. Move the shaft 1 revolution clockwise, and the get() function will read 2048.(I don't know which way -- clockwise or counterclockwise, reads 'positive ticks')
The library(or encoder) accounts for ticks read in the opposite direction One can also see what direction the shaft the encoder is reading and weather the encoder is moving or not(which is probably don't at the library level).

[AntiSleep]

We noticed the readout value jumps all over when using the encoders' analog output. This seems to be caused by the slow PWM it uses. Aliasing issues occur when the cRIO samples its analog inputs. I added a simple RC filter and that seems to have sorted it out. I just used a 4.7k in series and a 1uF after that. That seems to have smoothed it out, but as always some tweaking might be necessary depending on your application.

EDIT - For more info, just found the datasheet actually mentions this on page 18...

[sg999]

We're using the magnetic encoders in quadrature mode on our drive train. However, we're mounting them in such a way that they're spinning at the same speed as the CIM motors we're using on the drive train. We've got a lag of about 5 seconds (when reading the values from teleop.vi). Does anyone know how to fix this?

[Ether]

Originally Posted by sg999

We've got a lag of about 5 seconds

How are you measuring this lag?

[sg999]

Originally Posted by Ether

How are you measuring this lag?

I'll hit the joystick to move the drive motor and a stop watch at the same time. Once the value on the front panel of the encoder changes, I hit the stop watch again, to stop it.

Billbo911: We don't have a camera hooked up, and just about all of our code is in periodic tasks. Even when we moved the code to read the encoders to periodic tasks (10 ms delay), we still get the same lag. The potentiometers that we're also reading are updating rapidly. The code to read those were always in the same spot as the code to read the encoders.

[billbo911]

Originally Posted by sg999

We're using the magnetic encoders in quadrature mode on our drive train. However, we're mounting them in such a way that they're spinning at the same speed as the CIM motors we're using on the drive train. We've got a lag of about 5 seconds (when reading the values from teleop.vi). Does anyone know how to fix this?

We have found that moving all but your driving code out of teleop in into periodic tasks seems to improve the lag issue considerably. Additionally, try making sure that your video coming from the camera is running at the minimum required frame rate and resolution with maximum acceptable compression.

[Ether]

Originally Posted by sg999

We're using the magnetic encoders in quadrature mode on our drive train. However, we're mounting them in such a way that they're spinning at the same speed as the CIM motors we're using on the drive train.

Are you decoding at 4X, 2X, or 1X? The FPGA cannot read a 1024 CPR encoder at 4X at full CIM speeds.

[sg999]

Originally Posted by Ether

Are you decoding at 4X, 2X, or 1X? The FPGA cannot read a 1024 CPR encoder at 4X at full CIM speeds.

We tried both 1x and 4x, with no difference in lag.