Help with alternate encoders for NEOs

So my team is starting to move away from falcons (as much as i love them) considering their stock availability and how 5 falcons is like 20 NEOs. One problem that I’ve encountered so far on the technical side of using NEOs is that their integrated encoders are just meh.

I’ve heard many good things about the 63R256 shafted encoders are very nice but they are sold out EVERYWHERE oh my days.

So I’m wondering if anyone has any suggestion because right now im considering 3 options: The Rev Through Bore encoder , ctre MAG encoder (dont know how that one gets wired), or some other greyhill encoder at a lower resolution probably since all the 256 ones are out. Any input would be appreciated.

4 Likes

I would highly recommend the REV Through bore encoder- it’s as high resolution as you’d ever need and is very well priced, and dead simple to use- stick it on a hex shaft (or 1/4" round shaft, it comes with adapters). The CTRE mag encoder can also be used as a quadrature encoder, although it will require adapting the wire to match the Spark MAX data port pinout or to be wired to the RoboRIO. It’s also very high resolution and easy to use with many COTs gearboxes.

We’ve used the 63R256 encoders for many years and like them a lot, however they’re harder to integrate into cots mechanisms than the REV throughbore encoder, and their price is hard to justify in comparison. I wouldn’t recommend them to anyone looking to buy encoders for FRC nowadays.

I’ve also found that the NEO integrated encoder is perfectly fine for most things- velocity control on low inertia mechanisms being the glaring exception. While it is low resolution, it’s almost always going to be behind a gear reduction, increasing the resolution of the encoder over the mechanisms travel.

9 Likes

Im relieved the Through bore encoder turned out to be good because it really does look like the simplest to use. When you say the NEO integrated encoder is fine for most things does this include odometry (trajectoryfollowing etc)?

The biggest complaint I’ve seen is with velocity control because of the 100ms delay. But positioning you will get error with the slop in the gears. But nothing major from what I have heard

1 Like

I’m currently working getting odometry and trajectory following working with the NEO integrated encoders. The problems that I’m having are definitely not with the encoders. (This could change as I test further though) I used them during the 2022 season for positional PID control on our drivetrain and it worked great. Very consistent and accurate. REV also provides very good example code for use with the encoders.

Spark Max API information
https://docs.revrobotics.com/sparkmax/software-resources/spark-max-api-information#java-api

C++ docs:
https://codedocs.revrobotics.com/cpp/namespacerev.html

java docs:
https://codedocs.revrobotics.com/java/com/revrobotics/package-summary.html

I’ve found that NEOs are typically fine for drivetrain odemetry because of the gear ratios that you usually run on the drive train. This increases the resolution of the NEO by quite a lot.

3 Likes

This is a solved problem. See this thread but the TL;DR is REV is releasing a firmware fix, and there’s a workaround in the meantime.

This. Our 2022 robot has hex encoders on the drive output precisely because of this concern, but in actual use we did not get better odometry results from these than the built in encoder (with drivetrain gear ratio multiplier). When the encoder wires got damaged (relatively early in the season) we just abandoned using them.

3 Likes

That thread also talks about issues with odometry because of velocity error- this issue will also be fixed this season. All odometry and pose estimator classes now take distance measurements rather than velocity measurement. We’ve found that using position deltas greatly decreases error vs integrating velocity measurements (even in cases where the velocity measurements are not delayed).

6 Likes

Given the fixes coming, and assuming they work, what use cases remain that cannot be addressed by the integrated Neo encoders? And for those, which encoders (e.g. the through bore one) are recommended? Thanks.

Yep, already tested this on the Beta, huge improvement

1 Like

On a slightly unrelated note, is there like a unit conversion sheet for the integrated encoders? Because by default if I do encoder.getPosition() it returns the amount of times the motor has rotated. I’m aware that you can set the position/velocity scale factor of your encoders to change your units but with that being the case what do I set mines to so I can get meters?

It depends on your application – gear/belt ratios, wheel sizes, etc. If a motor rotation were directly coupled to a wheel rotation, you’d multiply the radius of the wheel (in meters) by 2π.

I see, in the case where the motor is behind some sort of gearing would I have to multiply that by the gearing reduction? Like: encoder.setPositionConversionFactor(wheelRadiusMeters * 2 * math.pi * gearingReduction); ?

Yes, that’s the idea. It is also good to tune this by commanding the robot to drive some set distance and then checking to see how far it actually drove. Often, things like wheel diameters and even gear ratios are not exactly what is published.

You will probably need to divide instead of multiply, because the motor is normally going to be geared down – so for one turn of the wheel, the motor makes multiple turns. Put another way, for one full turn of the motor, the wheel will only turn some portion of a whole turn. You can think of the gear ratio as a fraction.

1 Like

Thank you, that makes a lot more sense. I’ll just change the previous equation by dividing the gear ratio instead of multiplying then manually testing it out.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.