We are using SparkPIDController for an arm that has 180 degrees of motion. We are also using the through bore encoder in absolute mode. We cannot get PID encoder wrapping to wok. It seems to have no effect. We are using the MaxSwerveModule for reference because it uses the same encoder and PID controller.
1 Like
Can you link your code?
As @heightsbytes requested, please link your code so we can see specifically what you’re doing. Otherwise we’re just guessing.
That said, what do you mean by “PID encoder wrapping”? If you only have 180 degrees of motion, you shouldn’t need to wrap, right?
1 Like
Hi - I’m on the same team - here’s a link to a repo with just the java file: GitHub - ksmiller99/PidEncoderWrapping: Pid Encoder Wrapping doesn't seem to do anything
See lines 124 - 126.
1 Like
My question remains. Do you actually need that feature? You have an input range of 180 deg and a feedback sensor range of 360 deg. Can’t you just set the zero offset of the absolute encoder so that the returned position ranges from 0-180 and just go from there? If the mechanism overextends and returns an angle of -1 or 181, it doesn’t actually affect the PID calculation. As I understand it, with wrapping, that -1 would become 179, and the 181 would become 1, which is likely NOT what you want.
So, the issue is that the PID controller doesn’t see -1, it sees +359 and freaks out.
You are making a very good point though: I think it’s time to set that range to (0, 360), instead of (0, 180)… because this is how it’s done in swerve module example code.
Of course we might not want to the arm to move outside (0, 180)… but it’s probably a good idea to make sure that SparkPIDController doesn’t freak out when it sees 358 while it only expected to see between 0 and 180.
We did try to programmatically set the zero offset to 270, and that also had no effect. In fact, that code is still in the linked file, lines 100 - 104. I forgot to remove that before posting the link. It says 30 in the linked file because I was just testing that instruction.
The reason we prefer wrapping is that if the arm is at zero and it is bumped, can show 359 degrees. If it is at 359 degrees and gets a command to go to zero, it tries to “down”, the long way, to zero. Encoder wrapping is supposed to make sure it goes the shortest route.
The commands exist. They are used in the MaxSwerve module for steering. Why don’t they work here? It seems pretty straightforward.
We also tried to programmatically set the zero offset to 270 degrees, but that also had no effect. I feel there is some subtle underlying error or omission.
Fletch - I appreciate your concern, we prefer to use encoder wrapping. we have our reasons that do not need to be discussed here. You can just consider this an academic question and not be concerned with the practicality.
Let’s just focus on the question and not on why there is a question.
Thanks
Resolution (for anyone who has hit same problem and needs a solution ASAP).
This is not elegant, but simple: we just ended up calibrating the zero on the absolute encoder in the spot that will never be physically reachable when we put the bumper on the robot.
So, the arm can only move between angle +5 and angle +140 (degrees). In this range, no wraparound is physically possible and the software does not need to account for it.
If you have a prettier way to do this, please please share here of course
pidController.setPositionPIDWrappingMinInput(0);
pidController.setPositionPIDWrappingMaxInput(180);
Wrapping doesn’t work this way. You’re not setting the max input, so much as telling the PID controller what the max input will be. Instead you should set the max to 360, so that when the value is 359, it knows that it can go up to get back to 0.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.