So our team is using a PID and motion magic and a SRX mag encoder with a resolution of 4096 CPR to control our robot arm which is rotating aroud a metal rod and is not suposed to do a full 360 or else it will crash into the robot . We did some test without the arm and it works pretty well but we have a problem with the trajectory of our arm because you see if you look at it from the left side our arm is supposed to start to the left and rotate clockwise (upward) to the right side but curently it goes counterclockwise(downward) so our arm would just crash into our robot. Would there be any way to make it go upward
Does applying a positive voltage to your motor result in the encoder value increasing? If not I would try inverting your encoder readings
We’re using a nearly identical setup for our arm and it works in the way you’d like yours to
What are you using for your PID controller (WPILib, onboard motor controller, homemade)? The WPILib and SparkMAX PIDs both hace a “continuous” mode, which you do not want enabled for your setup. Check that you don’t have any kind of input wrapping like this enabled.
Where is your zero position defined?
Our position value goes back to zero when we reach 4096 if that’s what you are talking about
Our encoder value return to zero when we reach 4096 (complete circle)so I don’t know if we can go in negative value
If the controller knows this then yes. Basically, you don’t want the controller to think 0 and 4096 are in the same place, because you can’t drive the arm all the way around.
I’m not sure why you are concerned about the jump from 4096 to 0 since your drawing indicates you aren’t going all the way around. You can put the jump in the area that you aren’t going to travel, you can stop using the continuous setup as mentioned above, and you can use the method for phase inverted for the encoder to make the motor travel the opposite direction of the encoder.
1 Like
I think our problem is more in the way the code is made maybe it know that there is a shorter path if it goes downward also because of the way our encoder is instaled on the robot our zero point is about half way between the top of the circle and the A position so maybe our problem is that the code insnt able to go trough the zero point since the initial code is for an elevator they didnt need it to go trough zero
By zero point are you talking about the random orientation of the magnet installation? We’ve not used Magic Motion this way so maybe it has a quirky restriction but other uses allows us to use the method to move the absolute position to where we want it and not be held hostage to where we glued in a magnet.
the zero point is the spot where we switch from 4096 to 0 since our encoder is set to not continuous (so the value dont go up or down endlessly)
Move the zero to downward by adding an offset then wrapping the values into [0,4096], that’ll solve your problem
thanks we solved our problem like i said earlier it was because our code wasnt able to go past zero so we changed the zero position
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.