Help with rev throughbore in absolute

Good evening everyone!

We are in need of some help.

We are attempting to use a throughbore rev encoder in absolute mode for our wrist, the wrist will only ever spin 270 degrees.

We have the encoder wired into the spark using the rev absolute encoder board, and when we are in the rev client we get values ranging from 0-1 as we expect.

Even when we run the encoder in shuffle board we get the values 0-1

The problem comes when we go to write code specifically telling the encoder to go to a set position like .25

No matter what command we use or value we enter the wrist spins endlessly in the same direction. Until we disable the robot!

this is essentially the last ticket item programming wise. We are about to give up and use the built in neo 550 incremental encoder and just home it correctly every-time.

Any help we Will try anything at this point.!!!

Please share your current code, preferably by using a Source Code Management site like GitHub. It is very difficult to help debug and explain errors in code without being able to read it.


Make sure you enable PID wrapping in the SparkMaxPIDController. I would also recommend setting the position/velocity coefficients to 360 or 2pi so it’s more intuitive than 0-1.

Be sure to set the feedback device of your pid controller, and be sure to have a pid tuned for your absolute encoder.

1 Like

we will be back at it this afternoon, I will relay all this to the programming team, and I will also get the GitHub to the code posted assuming we don’t have it fixed by tonight.

1 Like

Make sure to reset the profiled pid if you are using one.

Okay!!! So here is the problem! And Ik there’s a solution for it our fix is temporary, but I’m. It sure what that fix is currently.

Our range on the throughbore is now 0-360 but our “home”position is 0 however this was the problem as it would over shoot 0 and read 360 then return all the way back around and repeat this time and time again,

We discovered this by changing the home to 5 and watched as it stopped at 4.98……

Since we only move the wrist 180 degrees we shifted our home to be 90 so our operating range is now 90-270 avoiding the area of conflict.

What would be the correct way of managing this conflict? Without changing the operating range. And using 0 as a go to position?

Did you do this? Should fix that exact issue.

Yep. This is the way, we had the same issue a week ago and this fixed it. I was a little shocked that it turned out so simple. Hats off to REV there.

OP, here’s our GitHub where we have two motors working off an absolute encoder and a simple P controller using REVs inbuilt stuff. We were having similar issues to you, where the motor just sent it. Our problem ended up being accidentally having the encoder set up wrong (I don’t remember how, but one of the lines was earlier than it should have been). No promises that is your problem, but given the similarity of our problems it’s worth checking.

Check out the arm and wrist subsystems and the commands we use for each, see if there’s any discrepancies. Feel free to DM me with questions or post here. 6574 is competing at a week 1 event right now, no promises on speedy replies.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.