Elevator Encoder Options

[PChild]

Do you all have preferences about how we handle an encoder for elevator position?

The choices as I see them:

• Use only the internal encoder in one of the Krakens

  • Assume that the system is fully down when code starts,
  • Have a current or velocity homing routine that zeros the system at bottom of motion.
  • Use motion profiling on the Krakens.
  • The Krakens are behind a gearing stage or two so this will have some backlash.

• Through bore encoder on the elevator spool shaft

  • Use this on code boot to seed the position of the Kraken internal encoder.
  • Still needs a homing routine
  • Still has backlash

• CANcoder on the elevator spool shaft

  • Still need homing routine
  • Can be used as fused CANcoder to eliminate backlash

• Two CANcoders set up for Chinese Remainder Theorem

  • Backlash should be very low if any
  • No homing routine needed - CRT code should seed position.
  • Can use fused CANcoder with one of the CANcoders for ongoing control of the system.

[PChild]

@jkleiber @aidnem Thoughts? My initial choice would be to do CRT but I just think it's cool.

[jkleiber]

But assuming the encoder is going to make multiple rotations over the range of the elevator's motion, I don't think we would have a valid control target for motion magic (at least in absolute mode)

Maybe it would be possible to control with a relative position, but then we'll need to maintain the offset in code and likely do a bunch of calibration (number of ticks of encoder 1 vs displacement sounds like a bad time)

[PChild]

Yes, we'd have to use the relative position of the encoder but that's the case in all of the options I proposed except for CRT with RIO side control. There's a Feedback.SensorToMechanismRatio config option that we can set on the Kraken that should eliminate calibration.

[aidnem]

I wonder if through combining sensor to mechanism ratio and the rotor to mechanism ratio we could control the motors through multiple rotations of the CANCoder without it losing its position? My initial comment about ruling out embedded motion magic was that we wouldn't be able to control it to an arbitrary position if it thought it could only wrap around once.
I assume this is what you're saying as well @PChild

[PChild]

You can control a mechanism through multiple rotations of a CANcoder. You can access both position which is limited to +/- 16384 rotations, and absolute position which is either [-0.5, 0.5) or [0, 1) rotations depending on your AbsoluteSensorRange.

We would use the absolute position data on the RIO for CRT. Normal elevator control would then use just the position data.

[jkleiber]

Oh yeah so we basically can see the absolute position in CRT but then calculate how many ticks it'll take from the current position to get to the goal (delta_ticks) and then do MM to current_ticks + delta_ticks = goal_ticks

[aidnem]

We don't even need to use the position delta for control. Phoenix 6 lets you set the position of a CANCoder, so after calculating the position using CRT we can just set the positions of the encoders to reflect the actual rotations from zero.
Then, to control to a height we just convert height -> spool rotations -> CANCoder rotations and then tell Phoenix 6 closed loop to control to the goal CANCoder rotations.