Let's start with OTOS. It uses an IMU and an optical tracking sensor and claims to be accurate out of the box. This eliminates the need for inPerTick, and it probably makes most sense to have it set to 1. And then the requisite positions and velocities for other steps can be read off the device (probably makes sense to use the onboard IMU and not have to deal with messed up hub orientations). Positions/velocities will be fractional and velocities will not need to be corrected.
And now Pinpoint. It also uses an IMU from the same vendor but a bit different and external dead wheels. The tuning process will be very similar to normal two-wheel odometry. There's a mechanism to set offsets for each wheel and also a yaw scale. The yaw scale in particular can hopefully be used to recover the individual wheel velocities in angular ramp logger without numerical differentiation. Positions should hopefully not be fractional but velocities may be, so it probably makes sense to share the same OTOS code paths.
There's the possibility that teams will want to calibrate these sensors using external encoders since they will have the extra encoder ports. It does seem relatively unlikely though and not worth planning for at this stage.
Two odometry sensors targeting FTC have been released recently: the SparkFun Optical Tracking Odometry Sensor and the goBILDA Pinpoint Odometry Computer. There seems to be enough interest in the FTC community to warrant adding tuning support for these sensors.
Let's start with OTOS. It uses an IMU and an optical tracking sensor and claims to be accurate out of the box. This eliminates the need for
inPerTick, and it probably makes most sense to have it set to 1. And then the requisite positions and velocities for other steps can be read off the device (probably makes sense to use the onboard IMU and not have to deal with messed up hub orientations). Positions/velocities will be fractional and velocities will not need to be corrected.And now Pinpoint. It also uses an IMU from the same vendor but a bit different and external dead wheels. The tuning process will be very similar to normal two-wheel odometry. There's a mechanism to set offsets for each wheel and also a yaw scale. The yaw scale in particular can hopefully be used to recover the individual wheel velocities in angular ramp logger without numerical differentiation. Positions should hopefully not be fractional but velocities may be, so it probably makes sense to share the same OTOS code paths.
There's the possibility that teams will want to calibrate these sensors using external encoders since they will have the extra encoder ports. It does seem relatively unlikely though and not worth planning for at this stage.