Documentation Index
Fetch the complete documentation index at: https://mintlify.com/saquer916/odyssey/llms.txt
Use this file to discover all available pages before exploring further.
Localizer is the odometry abstraction interface that decouples Odyssey’s Follower from any specific sensor or algorithm. By depending only on this two-method contract, Odyssey can work with dead-wheel pods, IMU-based odometry, visual odometry, the GoBILDA Pinpoint computer, or any other localization system — as long as it can report a Pose2d. Implement this interface in your TeamCode to integrate a custom odometry solution without modifying any Odyssey-core classes.
Package: org.firstinspires.ftc.teamcode.odyssey.localization
Interface definition
Methods
Returns the current best estimate of the robot’s pose. X and Y are in millimetres; heading is in radians, normalized to (−π, π]. This method should be pure — it must not trigger any hardware reads or state mutations. All sensor polling should happen inside
update().Polls the underlying hardware and integrates new measurements to refresh the internal pose estimate. You must call this method once per OpMode loop iteration before calling
Follower.update(), otherwise Follower will act on a stale pose.Custom implementation
The skeleton below shows how to wrap a pair of dead-wheel encoders. Fill in the odometry integration logic insideupdate():
Follower during OpMode initialisation:
Built-in implementation
Odyssey ships withPinpointLocalizer, which wraps the GoBILDA Pinpoint odometry computer. It lives in TeamCode rather than odyssey-core because it depends on FTC hardware classes, but it serves as a complete, production-ready reference implementation.
Odyssey does not call
update() internally. You are responsible for calling localizer.update() at the top of every OpMode loop iteration before any Follower calls. Forgetting this is a common source of sluggish or incorrect path-following behaviour.