I have edited 2471’s Hermes module to use the Lamprey Encoder. I’ve also thrown in a few other changes, namely that the top plate is raised 1/8" and the shaft in the azimuth is slightly different. Note that I am not affiliated with 2471 (I’m with 7034) and most of this CAD is ripped off borrowed from them.
Let me know if you have any questions or want pictures of changes.
Hi @ThomasU, I’m not exactly knowledgeable in the area of encoder types or swerve drive modules. What is the benefit of using the Lampry encoder over the integrated encoder in the Neo’s?
If you used the integrated encoder in the NEOs, you wouldn’t be able to account for the backlash between the gears and the pulleys when determining the module rotation.
Using an absolute encoder allows you to directly measure the position of the module, and account for it.
Sorry I’m just a CAD monkey I don’t really know the answers to those questions. I think it has something to do with taking the position at the beginning of the match?
There are several advantages that stem from the fact that the Lamprey is an absolute encoder, whereas the Neo’s encoder is relative. As Lipstick stated, it helps account for backlash.
Beyond that though, one major problem with relative encoders is that they reset to position 0 when they power off. With most use cases, this is fine. Manipulators are typically in a known position when the robot starts anyway, and you don’t care about position so much as rotations in terms of driving. However, with something like swerve, your starting position is crucial and can be anywhere. There are ways to auto-zero on initialization (hall sensors), but that adds an additional level of both cost and complexity. Using an absolute encoder, such as the Lamprey, solves that for you.
Finally, absolute encoders typically have higher resolutions than relative encoders. This would only matter in the most complex of situations, but it’s still worth noting if you ever run into a resolution problem.
Another thing to note, the original design took advantage of a potentiometer that acted as a pseudo-encoder, rather than using exclusively the neo encoder. The only problem with this is that most potentiometers are not capable of continuous rotation, so it would force you to sometimes take the long way to any given module state.
This is not true. We used a magnepot, which is a hall effect encoder that can rotate continuously. The primary advantage of the lamprey that I can see is that it can be mounted around the axis of the module, so you don’t need an encoder gear stage. Saves one printed part and a couple potential failure points.
I’m not sure what the calibration process is like on the lamprey encoders, but it might make bench zeroing the modules easier as well.
(By bench zeroing I mean giving the module a known encoder zero so it can we hot swapped with any other module with out a code deploy)
It also might be worth noting that we only used the magnepot to initialize the modules at the start of the match and ran our control loop off of the NEO encoder.
If we ran this design again, we would also run the mounting bolts up from the bottom into some captive nuts on the frame so that the modules could be swapped with only bottom access.
Interesting, my bad.
Ah, that’s the kicker. I understand that ligo.
