This is my own 21-bit high-resolution absolute encoder. Over the past few months, I’ve been testing and fixing bugs, and I’m excited to share the progress.
Features
High Resolution: Delivers an impressive 21-bit resolution, providing 2,097,152 counts per revolution. This level of precision ensures accurate angular position measurements.
Additional I/O Support: Equipped with inputs and outputs for integrating features such as limit switches or LIDAR sensors, enabling seamless interaction with broader systems.
Modular System Design: A 2 board architecture allows users to choose configurations that best suit their needs.
Locking Molex SL Connectors: Features locking Molex SL connectors for secure and reliable connections, even in challenging environments.
CAN Interface: Simplifies wiring and allows integration of additional sensors and devices through extra I/O.
Easy Mounting: Compatible with existing encoder mounts, ensuring easy integration into a variety of systems.
The encoder is mounted on a swerve module, shown here with the cover removed.
I’ve been testing this on a robot, and so far, it’s been performing great. It’s fascinating to watch each one change color dynamically with the steering angle.
Another feature I’ve been working on is a mode that lets it act as a non-contact magnetic limit switch. This video captures some of the testing and demonstrates its operation.
Initially, I had planned to release this as a polished product, but there are still some key elements that need further development. Features like additional I/O modules and proper documentation are not fully polished, and I want to ensure it’s fully refined before releasing it.
Because I may use this within my own team, which means I need to either sell it or make it open source to comply with R303 and the rules outlined in Section 8. While I’m not ready to open-source this project just yet, I will make it available upon request for the 2025 season to ensure compliance.
I’ll continue to share updates as I make progress, including build improvements and new features.
Really neat stuff! Higher precision encoders can be used for things like multi turn absolute encoders as well, for arms and elevators. I would be interested in seeing this used for something like an elevator position. You would need some anti backlash mechanism to make sure that it doesn’t lose precision.
You should check the nonlinearity of the signal though. Usually such high precision contactless encoders need to be calibrated to actually get good linearity - otherwise, typical nonlinearity for a magnetic encoder is on the order of +/-0.2deg, if only because the magnet itself is not perfectly crafted.
To use it in the 2025 season, you will need to open source it before kickoff I think, not just make it available up on request.
Non-linearity is certainly a factor to consider. The IC I’m using has a best-case non-linearity of ±0.2 degrees. Taking into account non-ideal magnets and potential misalignment, I estimate the actual non-linearity to fall between 0.3 and 0.4 degrees. To address this, I’m exploring options such as using a larger magnet or positioning the current 1/4" magnets closer to the sensor.
I will probably make a web store soon and become a vendor. If my team ends up using this, I will need to do this anyway since my team requires a formal setup for payments.
You should consider making some sort of calibration algorithm for the encoder if you can. I know the really high precision encoders typically have a means to perform this calibration automatically, but worst case, you can calibrate an assembled shafted unit (with the magnet) against an optical encoder of 22b+ precision. Otherwise, you’re not getting an advantage over a 12-bit encoder.
Spinning a flywheel at constant RPM could also help you calibrate, with enough mass on it to make the speed very consistent.
Thank you for pointing this out. This made me re-read the datasheet and I didn’t realize my IC has auto calibration. With that, it says I should be able to get it to +/- 0.07 degrees.
I’m facepalming right now because RTFM is something that is talked about in my team.
If that isn’t enough I could probably do something where I connect the encoder to my CNC machine and run a calibration program. My CNC has 23 bit encoders on the servo motors.
I could use this USB board that I made and have my encoder talk to my CNC over serial. It might be a little sketchy since the communication between my encoder would look like: X axis motor → Ethernet → LinuxCNC → my python program → USB → STM32 → Encoder IC. I might have to make the motor stop at each point to do calibration since my python program may not be very deterministic.
Those are good ideas. 0.07 degrees takes you into 13-bit range on its own.
A ts5705n250 or other 23 bit encoder can be had from China for pretty cheap ($30 to $80). Optical encoders will have excellent nonlinearity, and you can just check it against a known-good sample like your CNC. Servos with 23-bit encoders are also pretty common in the $200-500 range.
Gearing down a lower precision encoder could also work, as long as your gears are very nice.
Looking through the graphics, I’m interested to know if that board in the background adds locking Molex SL connectors to the Rio or if there’s other functionalities included.
Also curious what testing or other features you had in mind, similar to the magnetic limit switch mode you teased at the end there.
Agree that it would need to be open-sourced or hosted somewhere “generally publicly accessible” prior to kickoff for this to be legal per R303, if you go the non-vendor route.
Not sure this is true. I’ve thought this type of item lately, and a current ‘loophole’/ambiguity seemingly exists.
Here’s a thread that details this:
This thread is what got me thinking about this because the 2025 Rule Updates explicitly name “custom circuit boards” (which I presume this is?) as usable parts from pre-Kickoff. EDIT: you would need to generate new software or open-source it as necessary, however.
Hopefully(?) I’m wrong, so feel free to correct me.
Assuming 2025’s R303 is otherwise similar to 2024’s R303, I would say that the design and source code (including the PCB design files and source code for any firmware running on the PCB) would need to be publicly available prior to Kickoff in order to be legal for a 2025 robot.
ROBOT software and designs created before Kickoff are only permitted if the source files (complete information sufficient to produce the design) are available publicly prior to Kickoff.
It will depend on the exact wording of 2025’s R302 and R303. It’s one thing for R302 to say that a custom circuit board can be re-used. To me, that doesn’t mean “ignore all other rules; custom circuit boards are always OK”, but rather “for the purposes of R302, custom circuit boards can be reused, provided they are not in violation of other rules.”
As an example, they would not be able to use liquid mercury or a laser other than class 1 (R203), they must be within the FRAME PERIMETER in the STARTING CONFIGURATION (R102), etc. I would think that a custom PCB which is legal by R302 still needing to comply with R303 would be no different than needing to comply with R102 or R203.
