SparkFun OTOS returning incorrect distance values despite calibration attempts

Gotcha. In that case, I’m not sure why you’re seeing such high error. It’s possible your specific unit has some manufacturing flaw, but I don’t have any further way to diagnose remotely.

Thanks for the clarification! Numbers are always appreciated.

Ah, good to know! Using a tape measure from the start location is good, just be careful about using too many decimal places, because it implies you have that many significant figures (also see accuracy vs precision, this was drilled into me in school :wink:).

I’ll also caution about using a ruler; if you’re measuring from the teeth of the field tiles, be aware that FTC field tiles are slightly shorter than 24".

The implication in my previous message was that odometry pods can result in lots of decimal places, not that they’re accurate. If you were using odometry pods as your reference for the “actual” robot location, I would have asked that you go back and repeat with a tape measure, because odometry pods are not a ground-truth reference that can be fully trusted.

The accuracy of odometry pods can better or worse than the OTOS, depending on your implementation. If the pods are plugged into the Control Hub and you write your own odometry algorithm, that’s often worse than the OTOS because of higher and variable loop times (the Java garbage collector can create lag spikes that are 10s or 100s of milliseconds).

Not to tout our competitor’s product, but plugging odometry pods into the goBILDA Pinpoint Odometry Computer will be more accurate than the OTOS. It’s similar in function, except dead-wheels are inherently more accurate than optical measurements. So it’s more accurate, but the downsides are that it’s more expensive (as of writing, 2x pods at $75 each + 1x computer for $60 = $210 total, after goBILDA’s FTC discount), takes more space on your robot (2x pods + 1x Pinpoint versus 1x OTOS), and there’s more constraints on how you mount the pods (must be perfectly orthogonal).

If you’re after the most accurate localization, another thing you can do is utilize the AprilTags on the field with a USB camera on your robot. If you need help getting started, take a look at the ConceptAprilTagLocalization sample OpMode. Whenever a tag is visible, it will give the location of your robot on the field, which you can then use to update the OTOS (or Pinpoint) location.

Yet another option is to add touch sensors to the perimeter of your chassis, so when your robot bumps up against a wall or other known structure on the field, you can use that to reset one axis of your odometry implementation.

So, there’s a lot of options, each with their own advantages and disadvantages. Choose whatever makes the most sense for your team!