Tuning support for odometry sensors

[rbrott]

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.

[zachwaffle4]

I've been doing some thinking and I don't really know what else is missing before adding first-class support for OTOS/PinPoint/etc to the quickstart. According to Jay's quickstart, there isn't a lot of extra tuning required (just OTOS scalars&offsets and deadwheel offsets respectively, I believe). I'd be willing to write a PR to add the new Localizer classes for them to the quickstart, but I'm unsure if you'd like to keep the OTOS-specific tuning classes in the main branch or if a separate OTOS branch should be added instead.

Thoughts?

[rbrott]

There are enough small details here that I think it will be better if I make these changes. At this point, I'm not super interested in OTOS support. It doesn't seem as popular as Pinpoint and will involve more work. I'll attempt a simple Pinpoint integration with an eye toward Jay's quickstart, and we can go from there.