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