search

CrossTheRoadElec / Phoenix-api

CTRE Phoenix language API (targets FIRST Robotics Competition, Linux, RaspPi, Windows)
Other
39 stars 28 forks source link

Weird behavior with #clearPositionOnLimitR #61

Closed prateekma closed 5 years ago

prateekma commented 5 years ago

Although the clearPositionOnLimitR function works as intended (i.e. clearing the sensor position when the reverse limit switch is triggered), when a mechanism is resting on the reverse limit switch, any MotionMagic setpoint that is sent to the TalonSRX is disregarded and the mechanism does not move. Moving the mechanism just above the limit switch (so that it is no longer triggered) and then sending the MotionMagic setpoint works.

This is inherently a problem when trying to work with an elevator mechanism that is at its zero because motion magic setpoints at this configuration are effectively useless.

ozrien commented 5 years ago

I just tested this, it works as expected. My guess is that your target position is not >0, which is why your mechanism does not move.

  1. confirm clearPosOnR is set (Tuner )
  2. confirm reverse limit switch feature is enabled (Tuner)
  3. MotionMagic elevator into the limit switch. Note the Talon should drive red as this happens (since your closed-loop error should be negative (descending sensor position).
  4. When limit switch is asserted, motor controller will stop.
  5. Confirm motor controller sensor pos is zero (Tuner, selftest)
  6. Talon will blink the limit fault only so long as you are requesting negative motion, i.e. a target position less than zero.
  7. Now motion-magic to a positive number. Because the limit switch is closed, the sensor position will still report zero (for a while), this is okay because the positive closed-loop error will cause elevator to move upwards anyway. This frees the mechanism from the limit switch and now you are motion-magicing again to your top servo point.

Confirm where in this procedure you are seeing something different, or provide an actual procedure we can reproduce. Other teams have this working so I suspect something is being missed in your setup.

Another thought is maybe your Iaccum has wound up, so the closed-loop still wants to drive negative (for a while) while you are requesting a positive target. Use Integral Zone, or zero your kI until you have root-caused what you are seeing. Or use self-test to confirm Iaccum value.

prateekma commented 5 years ago

Huh, that's interesting. I will test this tonight and let you know what our results are. 👍

prateekma commented 5 years ago

We tried all of these steps in order and it worked as intended! We believe it originally had something to do with the limit switches not being enabled correctly.

Thanks for all your help!