Unify the odometry API across controllers

[christophfroehlich]

I'm unsure if we should backport #1854. If not, then updating tricycle controller on rolling might not be necessary as per #1695

I agree. If the backporting of #1854 is uncertain, what do you think about this proposal:

if the goal is to unify the Odometry API across controllers, we can open a separate issue just to unify integrate_runge_kutta_2 and integrate_fk into intergate similar to #1854.

Originally posted by @kumar-sanjeeev in #2042

[shlok-mehndiratta]

Hi @christophfroehlich, I've been following the discussion in #2039 regarding the odometry calculation rollout. I would like to support the effort to unify the API across the mobile base controllers.

I noticed that tricycle_controller is still using the older rclcpp::Duration-based update loop and separate integration methods. I’m happy to start by refactoring its Odometry class to match the new standard established in diff_drive_controller (moving to Time, adding safety guards, and unifying the integrators).

Additionally, I see that PR #2083 (Ackermann safety) has run into some merge conflicts and a discussion on the library-side API naming. Since these changes for steering_controllers_library are central to the overall unification, I'm happy to help resolve those conflicts and assist in finalizing that implementation as well if the current effort is stalled.

Let me know if this sounds good, and I'll start with the tricycle controller refactor.

[shlok-mehndiratta]

Hi @christophfroehlich, just following up on this as I’ve been digging deeper into the architecture.

After reviewing the ongoing work in #1695 (Tricycle migrating to the steering library), I realize that rewriting tricycle_controller's standalone odometry class right now would be redundant work that will eventually be discarded.

Instead, I would love to pivot and tackle the root problem here in #2251: creating a unified API based on the diff_drive standard.

Furthermore, seeing recent improvements like #2280 (adding robust open-loop clamp tests to diff_drive), it's clear that manually copying this odometry logic to other controllers means duplicating complex test cases as well.

My proposal to unify this is:

1. Extract the modernized Odometry class, its unified integrate() logic (from Update odometry implementation in diff_drive #1854), and its associated math tests from diff_drive_controller into a shared utility (perhaps inside a shared controller_library or a kinematics common package).

2. Have the controllers (Diff Drive, and eventually the Steering Library) utilize this shared implementation.

3. This inherently resolves the API integration/naming blockers currently stalling fix(ackermann): handle NaN/Inf values in odometry update #2083.

If you agree with this architectural direction, let me know where you'd prefer the shared Odometry classes to live in the workspace, and I can open a Draft PR/RFC to show the proposed API layout.

[Amronos]

@shlok-mehndiratta, you should probably use the integrate() method in omni_wheel_drive_controller, as that also works for holonomic robots, and put the shared odometry functionality into control_toolbox.
Thanks a lot for volunteering to work on this issue!

P.S. These comments should have probably gone into the parent issue, oops.

[shlok-mehndiratta]

@Amronos , good point on control_toolbox and factoring in omni_wheel_drive_controller for the holonomic case. That's a useful expansion of the scope.

@christophfroehlich , before I go further, I want to make sure I understand the intended scope correctly. Which direction fits your roadmap better:

1. Unify method signatures strictly within the existing controllers in this repo.
2. Extract shared odometry logic into control_toolbox as @Amronos suggested, covering holonomic cases from the start.

Happy to wait for your direction before proposing anything concrete.