Magnetic encoders? Anybody else having trouble?
 

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 :)

Re: Magnetic encoders? Anybody else having trouble?
 

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

Re: Magnetic encoders? Anybody else having trouble?
 

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.

Re: Magnetic encoders? Anybody else having trouble?
 

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

Re: Magnetic encoders? Anybody else having trouble?
 

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

Re: Magnetic encoders? Anybody else having trouble?
 

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".

Re: Magnetic encoders? Anybody else having trouble?
 

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.

I do not see that in the data sheet. Can you provide a page number where you see that? Thanks.

- Bryce

Re: Magnetic encoders? Anybody else having trouble?
 

Here is the Austria Microsystems link to the data sheet.

http://www.ams.com/eng/content/downl...6/533867/34237

For the AS5145B, on page 29 it says that the default firmware has the incremental mode set up for use.

Re: Magnetic encoders? Anybody else having trouble?
 

https://wpilib.screenstepslive.com/s...control-system

Well here's WPI's instructions on how to AS5145B Magnetic Encoder with the FRC Control System. Not sure how much it'll help, but just my 2 cents

Re: Magnetic encoders? Anybody else having trouble?
 

Ok. Well that's just a little weird. Who names their pins Test* and then uses them in normal operation? Bizarre.

So it looks like sg999 has it right. Take a look at the WPI instructions. The only gotcha is that the CSn pin needs to be pulled low to use this feature. Then it works just like a standard encoder.

On a side note, it looks like this chip can take rotational speeds up to about 15,000 RPM. It looks like to go this fast would require putting the chip in high speed mode, but it really is unclear.

Good find!

- Bryce

Re: Magnetic encoders? Anybody else having trouble?
 

Just make sure you're not asking any one DIO channel to count faster than 38,000 pulses per second.

Re: Magnetic encoders? Anybody else having trouble?
 

How are you mounting these encoders? We just got ours today, only to realize they don't fit on the encoder shaft of the mini tough boxes we were planning to use.

Also, has anyone figured out if putting the encoder too close to the motor will actually cause interference, as our backup plan for mounting these encoders also involves putting the encoder almost touching the motor.

EDIT: No, putting the encoders right next to the motor doesn't cause (noticable) interference, we tested them today.

Re: Magnetic encoders? Anybody else having trouble?
 

I'm a bit confused. In table 4, it says the max input frequency for the magnet is 153 rpm @4096 positions/rev. In table 7 it says that you can go up to 9766 rpm@ 64 samples/rev. Then in 9.6.3 it says it can go up to 30,000 rpm and refers to table 7. Maybe by going lower than 64 samples/rev?

In any case, I can't find where to change the samples/rev. Any ideas?

Re: Magnetic encoders? Anybody else having trouble?
 

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).

Re: Magnetic encoders? Anybody else having trouble?
 

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...

I believe it defaults to 4096 bit but can be changed through the digital interface.

We have tried this encoder on a shooter wheel and it can swamp the cRio pretty quickly. IMHO this encoder would probably best shine in a lower speed continuously rotating system or as a positional sensor.

- Bryce

Re: Magnetic encoders? Anybody else having trouble?
 

The datasheet is a bit unclear to me. Can pins 3 & 4 be configured to output a square wave quadrature signal or can they not?

Has anyone successfully done this with this sensor?


I'm guessing your comment above is based on not using the A & B quadrature output?

The datasheet is unclear regarding the max rpm the sensor electronics can support in incremental quadrature mode and still produce a usable output.

Sorry to be unclear in my last post. Yes, we were using the magnetic sensor in encoder mode. Were did seem to be getting good feedback. I didn't scope it, but we were getting count rates that seemed consistent and direction was also detectable.

All this was possible only at slow speed though. We could hit the Nyquist frequency for the cRIO input at very low speeds - maybe 15% or less of a CIM motor output, I can't remember the exact figure. At around this speed the encoder rate sign would change. We also would get very quantized numbers for speed (e.g., always something like dancing between 20142.464 and 21439.264 that were repeated exactly).

Just a thought, is it possible that having 4096 bit resolution that could correspond to 4096 ticks on an optical encoder and that the transitions actually happen 4x that speed? That would make matters even worse for sure.

So we gave up pretty quickly using the magnetic sensor and went to US Digitals instead. In hind sight I probably should have just rotated the shooter wheel one revolution and checked how many clicks it produced...

Re: Magnetic encoders? Anybody else having trouble?
 

Pretty sure it's 1024 cpr equivalent. 4096 transitions per rev.

Re: Magnetic encoders? Anybody else having trouble?
 

quote from screenstepslive:

Re: Magnetic encoders? Anybody else having trouble?
 

I'm guessing you were using the Encoder class and instantiating 4X decoding?

That's your problem. That's overkill for a shooter wheel speed sensor.

If instead you connected only one channel of the sensor, and made a Counter object that counts only the rising edge of that channel (with no direction control), the FPGA is capable of keeping up with 1024 rising edges per rev at well over 5,000 RPM (perhaps as high as 8,000 RPM).

Please note though: for high-CPR counters at high RPM, if you use the getPeriod() method, you must set FPGA samples much higher than the default 1. For your app, I'd use 127 (the maximum), which is about 1/8 of a revolution. Setting the size of the FPGA sample buffer is easy in LabVIEW. In C++ or Java, it requires a small edit to the WPILib code.

Or, at those high speeds with a high CPR (like 1024), you could get the counts (instead of the period), and divide by elapsed time. To get good results with this method, you need a good value of elapsed time. In C++ you can use the PPCtimer (low overhead and microsecond resolution). In LabVIEW you can use a Timed Structure and just divide by the period.

Re: Magnetic encoders? Anybody else having trouble?
 

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?

Re: Magnetic encoders? Anybody else having trouble?
 

How are you measuring this lag?

Re: Magnetic encoders? Anybody else having trouble?
 

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.

Re: Magnetic encoders? Anybody else having trouble?
 

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.

Re: Magnetic encoders? Anybody else having trouble?
 

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

Re: Magnetic encoders? Anybody else having trouble?
 

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

I'm aware of the 1X / 4X setting and we tried both. At full speed our wheel spins at around 6000RPMs. We were using 1X almost exclusively.

As for changing to a counter class, that might work much better.

What are the changes between 1X and 4X under the hood between the cRIO and FPGA?

- Bryce