Have you tried setting both setInverted and SetSensorPhase to true? This was the solution for us. It doesn’t make much sense to me since 2 negatives should make a positive, but hey it works for us.
When the wrist is moved manually, the encoder moves negative (from zero at start), when looking at the value on smartdashboard. No combination of setSensorPhase and isinverted seems to make any difference to the values shown on SmartDashboard when the wrist is moved in the “positive” direction.
Are you setting the encoder position anywhere else in the code? I see you set it to 0 when you initialize the subsystem, so if your wrist is somewhere in between its upper and lower limit, its range of motion will be different (e.g. When you initialize it while its at the bottom, its range may be 0-2000, but if its physically somewhere in the middle when you initialize it, its range will be -1000 to +1000)
Also, try lowering your config_kP value to a much smaller value? Like 0.2.
setInverted sets the motor output to the opposite (green vs red on the motor controller and forwards and backwards on the motor). setSensorPhase changes the direction of the sensor increment.
We are not setting the encoder anywhere else. And we tried turning the P down to no avail.
Put this line before you set any of the SRXwrist settings:
SRXwrist.configFactoryDefault()
This will clear all lingering setttings that may be inadvertedly set on the Talon.
Next, try getting rid of the .configPeakOutputForward/Reverse and see if that helps.
Also, have you already tried swapping encoder cables?
1 Like
We have tried switching encoder wires and setting factory default and getting rid of peak output did not seem to change the results
After looking at them the motor and sensor do seem to be in phase.
How are you calling your position functions in code? Are you just calling them once after a button press with nothing else after that?
Secondly, are you sure those positions are correct? If you always start at the same physical position when you redeploy code and then physically move the wrist to where it should be?
Are you actually using a CTRE Mag encoder? Is the LED on it staying green/yellow as your wrist moves? Have you tried swapping it out?
it is called by simply holding down a button, and if we manually move the wrist to 650 it is in the right position. I just replaced the CTRE mag encoder and we still have the same issue.
Do you have your code uploaded to Github so we can see the entire repository?
Sounds like this was mentioned, but here is the relevant section in documentation.
https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html?highlight=setsensorphase#adjust-sensor-phase-using-api
SetInverted cannot be used to correct sensor phase. See link above.
Also don’t just flip the value until the closed-loop behaves. Correct the sensor phase first using open-loop control ( as documented).
Next Steps
After you have open-looped driven your motor and confirmed sensor velocity is positive when Talon is blinking green:
- confirm you have followed
https://phoenix-documentation.readthedocs.io/en/latest/ch14_MCSensor.html?highlight=setsensorphase# - capture a self-test of the Talon (via Tuner) while closed-loop is misbehaving.
- post self-test for review.
- Confirm there are no errors in the DS message log.
1 Like
Is this button called in teleOpPeriodic() with an if() statement or called using the command-based structure. If its the latter, are you doing anything else in your execute()/end() functions?
Have you tried plugging in the encoder into a different Talon and checking if the behavior is the same?
- Talon 13 was not enabled (top of self test). Check the Driver Station - was the robot enabled?
- If the DS was enabled, then check the CAN IDs you specified in source in your Talon constructors.
- Make sure Talon 13 is the correct one - i.e. the one you are troubleshooting
- Be sure to capture a self-test of the Talon (via Tuner) while closed-loop is misbehaving .
I have narrowed the issue down to the fact that the sensor and the motor are not in phase. However changing the setsensorphase to true dosent do anything.
It’s worth mentioning (should have been done before) that this was initialy working and subsequently stopped working. The observation is the encoder started going backwards/out of phase. We have looked at the encoder (and cable), the Talon, and the programming and can’t find a root cause. Any thoughts/ideas on what else might cause the encoder to go out of phase? Would CAN wiring have any affect?
I sent @Galen6790 a PM but didn’t see a response. That almost sounds like sensor wiring, but regardless of the root-cause, it should not take multiple days to get this feature running.
I think something fundamental is being missed in your process.
The next time you are in front of the robot next, contact our support.
http://www.ctr-electronics.com/contacts-us
I was able to solve this issue bu putting the sensorphase command in a periodic loop