Has anyone here used an absolute encoder (such as a CTRE CANCoder) for anything that’s not driving related?
I want to start using absolute encoders for things like arms, elevators, and such. I’d wish some tips and recommendations for any team with experience in these.
Yes. Absolute encoders work great but are only good for use cases where the mechanism stays within a single rotation. We’re a fan of cancoder over the rev through bore. Arms are relatively easy,U just put the encoder on the output shaft and then u don’t need any conversions. We didn’t use an absolute encoder for our elevator last year because the winch rotates past a single rotation. For this we just used the relative encoder in the motor.
This 100%.
Personally our team has used the rev throughbore encoders with no major problems but I have heard a lot of criticism for them.
It is very possible to make an arm function without an absolute encoder too. I believe 1690 did so this past year due to packaging constraints (someone fact check me on that). As long as you can set the internal relative encoder at a consistent position on the arm it should work well.
We used one last year for our elevator. We wanted to be able to always know exactly where the elevator was in its travel, and browning out had the potential to erase the incremental encoder counts in software. So, we designed a 3D printed gearbox linked to the elevator’s drive shaft which was geared down enough to make the entire travel of the elevator make the last stage of the gearbox complete less than one full rotation. We used a REV Through Bore Encoder on the last stage of that gearbox to measure the rotation.
This setup actually proved extremely reliable. We were always able to know exactly where the elevator was in its travel down to about 0.025". Granted, the travel of that elevator was only 19", so I’m not sure how well this would scale with a larger elevator. We’re planning on trying it out with a “big boy” elevator (~80" of travel) to see if it’s still sufficiently accurate. With that amount of travel, I’m mostly worried about the gear backlash that the (likely) many stages of the gearbox will have. If we can maintain a resolution of 0.1", I’d be happy.
Some Pros of this setup:
Some Cons of this setup:
We have used absolute encoders for the past several years on a variety of mechanisms and found them to be very useful. Examples include arm position, turret rotation position, shooter hood position.
Pros:
Cons:
Tip:
For any pivots I 100% recommend cancoder (or the new through bore encoder) + phoenix 6 with fusedcancoder mode (requires phoenix pro). It has backlash compensation and is a dream to work with in my experience.
Potentiometers give you a wide range of absolute rotations. My team has used from 1 to 10-rotation versions. 10-turn example
We do use CANcoder with the through-bore attachment when possible.
We used the rev through-bore encoder for the first time this past off-season on our intake.
We have an over-the-bumper pivot and being able to track the position was incredibly beneficial for us. We were able to up the speed of our intake deploying and, as a result, hit our team’s first four note auto.
Highly recommend, it was super easy to incorporate it on the existing mechanism and wire.
I seem to recall multiturn pots driven by gt2 belts were the bees knees for elevators in 2015. That and string pots ( which are incredibly useful and underrated these days)
since we’re talking about turret position sensing, i’m curious if anyone has explored the issue of backlash in the sensor drive. The armabot mech uses a worm gear, and a multi-turn pot is the same thing, with backlash up to ten degrees, or one degree for a ten-turn pot geared 10:1, and for a long-range turret one degree of backlash just in the sensor seems like a lot?
Completely agreed. Adding absolute encoders to pivots and limit switches to the top and bottom of your elevator helps to keep programmers happy 
This season for example at first we didnt have an absolute encoder on our pivot, and at our first tournament had issues with it destroying the gearbox cause it lost its positional data. we put on a thrugh bore CAN coder and had no more issues.
Also now with the fused CANcoder aspect of phoenix pro, even more useful
If it involves a sensor and backlash you bet your bottom dollar it has been explored.
Turrets, as you mention, are a tougher one because they are
Annoying to get a direct sensor measurement off of if you pass a gampiece through the axis of rotation (probally need a vision system on the turret itself as we don’t have throubores that big and an encoder/pot on top is finicky),
They are often belt driven (generally lower backlash than gears), which makes it cumbersome to measure the turret with a geartrain (juat look at what armabot had to go through…)
Now I am going to take the stance that in the case of turrets (especially ones that can do 360°) it is all a bit of a moot point.
If you are making a long range turret (e.g. 2013) you do not need much angular range and care far more about your angular accuracy/precision and minimizing backlash.
If you are making a short range turret (e.g. 2022, 2024), you care far more about speed and range of motion especially if defense will be a thing (although there were many teams that were highly successful in the 2022/2024 games without a turret at all). Being off by a degree or three shouldn’t be a big deal close up.
Where this may become messy is in games like 2012 and 2020, where there are short and longer range advantages with a clear emphasis on accuracy. However swerve for rough positional alignment and +/- 45° on a turret may be sufficient (1619 in 2020 is the bot that comes to mind in this case).
2012 played out today would be fascinating.
Only disadvantage really is that they only output a 10 bit number for absolute position, which means a resolution of around ~0.36 degrees. For many cases, this is good enough, for some it’s not.
Also you have to remember to buy the correct adapter for the Spark Max, the absolute encoder adapter if you want to use the encoder for its absolute position values.
We have one on our 2024 bot for our shooter pivot angle and another for our intake arm
We’ve used the REV Through-Bore Encoder for our arms the past two years, and while we didn’t really see too many backlash issues on the 2024 arm (likely due to the fact that we learned a lot from the setup in 2023), the 2023 double jointed arm we built experienced this backlash issue quite often especially on the lower joint. We never really explored if the root of the issue came down to the sensor itself, but we did try to address the issue by adding shim stock from McMaster Carr and applied it to the inside faces of the 1/2" Hex Output from REV. This seemed to temporarily solve backlash issues, but did require some upkeep as time went on.
We also ran the encoder setup off axis with herringbone gears inside the tube to try to eliminate some of that concern of backlash, but had various failures (one in particular where we drilled out a rivet and the base fell directly into the gear teeth, destroying the gears).
I think in this setup, we tried to eliminate the backlash all together, but rather it being due to the sensor, our shortfall was likely the mechanical setup.
multi-term potentiometers are, indeed, great things. There are a couple of downsides:
(1) You should try to get high-quality pots; the signals from low-quality pots will be ‘dirtier’ in that the voltage will vary more even when the pot isn’t moving. (You always get a little bit of that).
(2) They’re all mechanical and really aren’t designed for any sort of loading in any direction. So, you’ll have to figure out how to add your own bearings (or whatever) to avoid that.
(3) One downside is pots is that you have to know where your set-points are – if you twist the pot when it’s not connected to the rest of the mechanism, you have to reset all the set-points. If you have a relative encoder, you just put the mechanism into a known state and count the clicks from there.
This is true (at least the part about us… I never used a rev encoder or a cancoder). We usually use absolute encoders on systems like our arm this year, but because of packaging we didn’t have anywhere to put an encoder in a sensible manner. So we used a hall sensor to make sure the arm is closed at the start of the code. Which is actually totally fine because we only use absolute encoders to reset anyways, we always do all the control through the relative encoders in the Falcons.
This is a concern for sure. What I’ve done in the past is try to mechanically align them as well as practical and use a short piece of an appropriate sized hose to make a “universal” sort of coupler.
This can handle minor misalignments in all orientations - axial or radial - and due to the low force needed to turn the potentiometer, it doesn’t add a lot of backlash. In practical terms, backlash has been low enough that we just ignored it.
You need to deal with the packaging though which can be a deal killer at times but if you can get them reasonable well aligned, you can do it with 5mm or less separation which is on the order of whatever sort of coupler you might use is going to impose anyway.
Got the idea from when many years ago we’d use a length of fuel line stuck onto the end of a spark plugs to get them in and out of tight locations (once loosened) by using the hose as a big “universal joint” with a nice smooth bend.
absolute encoders work great for pivots, but a consistent starting mechanical zero point to use the relative encoder off of will also work really well, last year we used both methods on our robot, but I liked the lack of an extra failure point of the zero mechanism. I also have noticed that sometimes CANCoders can boot weirdly and report incorrect values which I have encountered a few times, last year we had to restart robot code after boot before every match to avoid these issues. best thing just in general for a pivot’s accuracy is minimizing backlash though so that should be the priority.
Well guys, I don’t know what to say, I’m really thankful that all of you have shared very helpful information about absolute encoders. We hope in our team this will help us out extremely in implementing these devices for the next competition.
