So I’ve heard that the brushless Neo motors did really well this year and my team would like to incorporate them into our drive train next year; however, I’ve also heard that the built in encoders for the Neos have poor resolution. If we were to use external encoders what would be the best fit?
The biggest problem with the NEO encoders has nothing to do with the encoders themselves, it is a far more fundamental problem; the measurement is on the wrong side of the backlash.
As for the best encoder for FRC use, hands down the CTRE Mag. With extremely high resolution, native support for the TalonSRX, well documented libraries, absolute and relative encoder modes, loads of mounting documentation and options, and the lack of a mechanical linkage to cause slippage, I see very little reason to use anything else in the current FRC scene.
Please keep in mind… Using a NEO with the Spark MAX means you have to have the NEO encoder plugged into it. So any secondary encoder would need to go elsewhere - the RoboRio DIO port, for example. You can’t just put it into the Spark MAX like you would if you were running a brushed motor with it (or a talon, etc).
I talked to REV at worlds, and they plan on fixing that, so you can use external encoders and a brushless motor.
Just a note from experience, if your machining is a little less then precise, the mag encoders don’t always work perfectly. We’ve had good luck with Grayhills as well as mags.
I agree with @BordomBeThyName. In 2017, we had a failure with CTRE MAG Encoders by the way they where mounted in a Vex 3-CIM ball Shifter. The magnets “slipped” inside the hole and would not read correctly. The only way to fix it was drop the whole transmission. Since, then, we have just stuck with US-Digital encoders on the outside of the transmission. We get the 1000 PPR resolution direct from US-Digital and so far, they have worked well for us.
So slippage is still a possible issue with magnetic encoders? Is there anyway to prevent that?
Usually you should epoxy or otherwise secure the magnets in the hole (we used green loctite as the fit was tight) to prevent slippage. Not sure the nature of Chris’ slippage though.
The Neo Encoders do have poor resolution at only 42 PPR. However, you still have the gearbox reduction before the encoder hits your wheels, or other manipulator. So if you have a 10:1 reduction in your gearbox you will get 420 pulses per revolution of your wheel or other mechanism. In the past we have used a 256 PPR Greyhill Encoder with great success and that has much less resolution.
The problem with that is that measurement is before the backlash. A low-res measurement of a motor before a 3-stage gearbox is a very different thing than a high-res measurement of the actual wheel position.
As a minor correction here, the NEO is actually 42 counts per revolution (i.e. 42 electrical edge transitions that can be counted), where the 63R256 Greyhill you link is 256 pulses per revolution, which is equivalent to 1024 counts per revolution when doing quadrature decoding (i.e. 1024 electrical edge transitions that can be counted).
So for your example, with a 10:1 reduction, you have 420 counts per revolution on the NEO compared to 1024 counts per revolution on the Greyhill.
Unfortunately the terminology used is not the most intuitive across encoders (also not to be confused with the common term CPR or cycles per revolution!)
If you have the time and resources to do so, experiment with the Neo encoders now during the off-season. You may find the resolution and positioning of the encoders may or may not matter for your application. Some tasks require the precision measurement of the final wheel position after as much backlash as possible at a fine resolution. Others may only need a “good enough” reading.
If you’re primarily concerned with velocity rather than specific position, those encoders may be upto the task. If the game challenge is forgiving on final position of your drivetrain, those encoders may be upto the task. If you’re using some sort of vision or distance sensor for final alignment, those encoders may be upto the task. If you’re primarily using your odometry for field positioning on a precise object or using these motors on a manipulator with precise position requirements, these encoders might not be right for the task.
Whether you want to measure on the motor side of the backlash or on the wheel side of the backlash depends on what you are doing with the signal. If you are using it for path following, then the output side is better. If you are using it for closed loop control, the motor side is generally better because the backlash represents deadband in the feedback control that can cause dithering and other non-convergent behaviors.
We used the NEO encoders on our swerve drive motors for our path following calculations this year without much of an issue. But our distance calculation integrate all 4 wheels, so the error will average out quite a bit.
This is our plan. We used NEO’s this year, but also used the CTRE Mag encoders on the gearbox output for our feedback control. Our plan this fall is to run some tests to see how they compare, both to speed control and position control, with an eye towards figuring out which to use next year. Honestly, we didn’t really need the Mag encoders this year, as we didn’t do any autonomous drivetrain coding - the NEO encoders would have been just fine for closed loop control while manually driving the robot. It’ll be interesting to see how much of a difference we see in testing!
pulses cycles per revolution.
1 cycle = rising edge A, rising edge B, falling edge A, falling edge B
Splitting at hairs, but technically pulses are cycles, a pulse consists of a rising edge and a falling edge, no?
Yup! This all helps illustrate that the terminology is not super straight forward (and you’ll find inconsistent terminology in a lot of places).
This image does a good job visualizing for folks that are unsure for quadrature encoders (the hall sensor signal is different).
I think some of the confusion with regards to the NEO is that the built in sensor is 3 digital hall sensors. The waveform looks like this, with 3 sensor wires instead of 2:
With 42 counts per mechanical revolution.
On a quadrature encoder (2 channel), a cycle consists of 4 edges:
rising A, rising B, falling A, falling B
@Will_Toth since you are already in the thread, can you confirm whether or not this is on the road-map, if possible?
Yes this is on our roadmap you can track the progress here. We’ll keep this up to date as we work on it and what the solution will look like.