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.

[zachwaffle4]

that was fast lmao; what changes to tuning are relevant for pinpoint/what about it would need to be added to docs?

[rbrott]

Well it's not quite ready. I released what I have now mostly to make sure the refactor didn't break existing support.

[zachwaffle4]

I was thinking that for both Pinpoint and OTOS we could have a DriveView constructor that, instead of having either leftEncs and rightEncs OR parEncs and perpEncs it just has a single poseFactory: () -> Pose2d that we can use to get information from the Pinpoint/OTOS directly during tuning, although I don't know enough of how the math behind the ramp loggers work to know if that would be enough.

[zachwaffle4]

It then occurred to me that my idea above is unnecessary because I could just add a class that uses the OTOS to pretend to be an encoder; I added that to #13 and then used them in acmerobotics/road-runner-quickstart#478 to allow OTOSLocalizer to be used in the Drive View Factories.

[rbrott]

In my mind, the user wants to tune Pinpoint the same way they would tune two-wheel. Having Pinpoint pretend to be two encoders and an IMU then makes sense. I agree that you want a different API for OTOS, and you will need to tweak the tuning process beyond what's currently implemented.

[zachwaffle4]

When it comes to tuning, I believe that the only extra steps are the scalar/offset tuners that Jay wrote. I think aside from that I'd have to either rethink the entire DriveView system as described above or duplicate some of the tuning opmodes to use an OTOS instead of a DriveView (which I think is a worse idea).

[rbrott]

Everything should be in place for Pinpoint tuning now. I'm sure it's a little broken still but hopefully not grievously so.

[zachwaffle4]

I believe everything is in place for OTOS tuning now also (in #13 here and acmerobotics/road-runner-quickstart#478)!