First, WPILib pretty much never uses raw units::radian_t values, instead wrapping them in an frc::Rotation2d. When would it be beneficial for us to use this type over units::radian_t? I lean toward using radian_t type for lower level control (motor controllers) and Rotation2d for high level control (drive train). Since adding radian_ts and adding Rotation2ds produce different results, I think this would produce the most intuitive behavior.
Second, we need to make sure the falcons pids will properly handle angle inputs that wrap continuously from -180 to +180 as the swerve modules will need to. Hopefully the talons natively support it (as the spark maxes do), but we can write something on our end to support it if need be.
First, WPILib pretty much never uses raw units::radian_t values, instead wrapping them in an frc::Rotation2d. When would it be beneficial for us to use this type over units::radian_t? I lean toward using radian_t type for lower level control (motor controllers) and Rotation2d for high level control (drive train). Since adding radian_ts and adding Rotation2ds produce different results, I think this would produce the most intuitive behavior.
Second, we need to make sure the falcons pids will properly handle angle inputs that wrap continuously from -180 to +180 as the swerve modules will need to. Hopefully the talons natively support it (as the spark maxes do), but we can write something on our end to support it if need be.