So, we are attempting to run a thru bore encoder on our elevator shaft for climbing. My question is the thru bore reports position from 0-1. When the thru bore does 1 full rotation, it wraps back to 0, which would mess up our position control loop. How would I get the output of the position not to rap when the shaft makes 1 complete rotation? And if I can implement this logic, what would happen when I turn the robot off? The thru bore will know its “absolute position,” but it isn’t really the correct position since the amount of “wraps” isn’t taken into account in the .getAbsolutePosition() method.
It seems like you want ‘absolute’ position, but also want the encoder to be able to make multiple rotations. This isn’t possible. You’ll need to use relative mode with the encoder, and provide a seed location using something like a limit switch that is in a known spot.
What we do is every time the robot turns on and enables, we lower the elevator until it contacts a limit switch. This tells the elevator it is at the 0 position, and from there it can use relative mode to make multiple rotations
2 Likes
Sure it is possible, as long as your elevator starts in a known “safe rotation” of the absolute encoder you can just use an accumulator variable which solves the issues every time you roll past zero. You then use the accumulated value for any calculations.
By safe rotation I mean your elevator is within the same rotation of the encoder when it starts. I.e. all the way down. You could add a limit switch, distance sensor , etc. to act as a safety. For example , if your elevator goes through 3 absolute encoder rotations, you just want to ensure that it is always in the most retracted rotation when code starts.
This isn’t running the encoder in relative mode, you are still in absolute. You just have multiple readings of the absolute encoder as the mechanism passes thru its motion. All you are doing is keeping track of those times it is passing thru 0 and making sure the robot mechanism is starting in the right ballpark.
2 Likes
If you are using the REV Through Bore Encoder this is 100% possible. My team is doing it this year with our extension arm and getting very accurate readings. Look at line 35 of this file. I didn’t set this up but I’m pretty sure this is all you need.
I don’t believe this will work, because your absolute position will never be >1 or <0. You need to look at the transition.
For instance, going from >0.9 to <0.1 in one step (should only happen when you roll from 1 to 0, or the reverse, going from <0.1 to >0.9 (you’re decreasing, going from 0 to 1).
That would be my naive way of doing that.
But I’d much rather use the absolute value of the through bore on startup to zero the motor encoder, which counts in the way you want it to.
We don’t have the adapter to plug into the SparkMax — we are running the thru bore off the RIO’s DIO port as of now. So, I don’t think we can call the .getAlternateEncoder() method. Also, when you pass in 8192 counts per revolution, wouldn’t it stall wrap when it reached 1 revolution? If ur at 8191 (shy of 1 rotation) and then rotate it further, wouldn’t it go back to wrap and go to 0?
Are you saying that instead of using the thrubore and doing all this wrapping logic, it would be better to rely on it as a “zeroing” mechanism and run the control loop off the NEO’s internal encoder? So something like
if(thrubore.getAbsolutePosition() <= 0.27){
motor.set(0);
relativeEncoder.reset();
}
where 0.27 is some arbitrary value that the thru bore is at when the climber is zeroed (a little higher, maybe the actual zero position is 0.25, idk and just set some tolerance of 0.02, so it zeros), and the relative encoder is the internal encoder in the NEO.
Instead, would it be better to use some other form of a limit switch? I’m considering using hall effects; one would be placed at the top “limit” as a safety feature and the other at the bottom as a “zero” in the NEO relative encoder. What advantages would combining the thru bore and the limit switch be, and how exactly would you go about implementation in my use case?
Could I avoid needing a thru bore and get away with using top and bottom hall effects and run the position control loop off the internal encoder? It would just reset at 0 when it triggers the bottom one. The top one would just be for safety. This seems more straightforward and would achieve the same as having a thru bore for the absolute position if I just start the arm at 0 when the robot turns on.
Somewhat. But frankly I wouldn’t recommended it.
Since the absolute encoder can rotate more than one rotation for your entire elevator’s travel, you can’t use it to know where you are all the time. You’d be crossing your fingers that the throughbore is on the correct rotation to zero your elevator.
IF you plan on starting your elevator at the same location each time you turn your robot on, you can simply use the motor encoder and zero it when you turn the robot on (assuming you put the elevator in the same location). Without using the throughbore at all. This is the easy, cheap, but somewhat flawed option.
This is a situation where a limit switch is a better bet to zero your motor encoder and use that for positioning. Start the elevator on the limit switch when you turn the robot on, or create a zeroing routine that lowers it to touch the limit switch.
You could use a string potentiometer for this as well, which would give you absolute positioning.
For an elevator, it shouldn’t be too hard to just always start it in a known location (all the way down), and zero it on code startup, then just use your NEO encoder or the through bore in relative mode.
I see. So, I think in my case, I think it would be better to not use thru bores and the limit switches and run the control loop with the NEO’s integrated encoder.
Yes. This may cause a problem if the encoder loses it’s position, so you’d want a routine that rezeroed by slowly moving down until you see something - like no motion for x seconds, then zeroing again. That way if you lose your position in a match you can recover.
How is it possible for the encoder to lose its position during a match exactly? Like if the robot gets hit hard and the encoder sensor cable gets disconnected, then the motor wouldn’t spin in the first place. So then it wouldn’t be possible to run the routine, or am I misunderstanding?
The most common reason is you get a power blink to that motor from loose wiring, or a loose breaker, or just a freak of nature.
It’s a ‘just in case’ situation.
This is using it in alternate mode with more steps. Instead of letting the firmware handling the wrapping / accumulating, now you have to do it
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.