feat(app): add autoware module (ekf_localizer)

[nokosaaan]

Description

I added the ekf_localizer module.
I have ported the Autoware test case to Rust code.
Although there were multiple test cases for ekf_localizer, I believe that porting test_covariance.cpp alone is sufficient for dead reckoning in MRM. If it becomes necessary to add other test cases, I will consider implementing them as well.

Related links

https://github.com/autowarefoundation/autoware_core/tree/main/localization/autoware_ekf_localizer/test

How was this PR tested?

ekf_localizer.txt

Notes for reviewers

[kobayu858]

This PR will be reviewed after #688 is merged.

[kobayu858]

@nokosaaan
The following five items appear to be missing. If this is intentional, please specify so in the comments; if they were simply overlooked, please implement them.

1. measurement_update_pose does not exist.
2. measurement_update_twist has been simplified.
3. vx_obs_var is fixed at 1.0, causing the logic that “does not trust velocity observations at low speeds” to be lost.
4. The delay compensation buffer is not functioning.
5. The initialization (initialize) does not account for TF transformations.
   Is it perhaps assuming that the input ros2bag is already transformed?

Are you implementing only “predictions for a single point in time + simplified velocity observation updates”?

[nokosaaan]

@kobayu858
You're right — without these 5, this isn't a faithful port of upstream ekf_localizer, and I want to implement all 5 rather than leave them as documented gaps: measurement_update_pose, the full measurement_update_twist (message-covariance + Mahalanobis gate), the low-speed vx_obs_var gate, the delay-compensation extended state, and TF-aware initialize().

On whether the current state is intentional: it reflects what was used for our paper's evaluation (dead-reckoning only, imu_raw.csv + velocity_status.csv (from awkernel_script), no pose observation input). I checked whether any of the 5 were a deliberate "minimal MRM set" decision. Answering the two I was most unsure about:

3. vx_obs_var fixed at 1.0 — not intentional, and not dead code.

• The threshold_observable_velocity_mps gate itself (the low-speed on/off switch in upstream's callback_twist_with_covariance) wasn't exercised in our comparison: the param file we used for the reference run sets it to 0.0, matching upstream's own default ("Set 0.0 if you want to ignore"). So I can't claim the gate's absence caused a measurable divergence in that specific comparison — both sides had it off.
• But vx_obs_var = 1.0 itself — the value update_velocity uses unconditionally regardless of that gate — doesn't trace back to anything. It doesn't match the value the rest of our own pipeline actually uses: VehicleVelocityConverter defaults stddev_vx to 0.2, which create_covariance_matrix turns into a variance of 0.04 on the published twist message — not 1.0. So 1.0 looks like an unreviewed placeholder rather than an intentional choice, independent of whether the low-speed gate is on.
• It's also not unreachable: the actual test_autoware DAG wiring calls ekf.update_velocity(vx, wz) on every 50ms tick, fed by vehicle_velocity_converter→ gyro_odometer over the same CSV data (5700 rows, ~25% below 0.05 m/s).

5. initialize() missing TF — looked fine only because the harness, not the code, kept both sides aligned.

• Our own comparison setup aligns the Autoware and Awkernel runs to start from the same initial pose as an input-alignment step, and the DAG's pose_dummy_generator feeds a hardcoded (0,0,0) / identity-quaternion Pose — not anything derived from a real pose source or TF. So the comparison never actually exercised a real map-frame/sensor-mount offset; it isn't a validated decision that TF-handling is safe to omit, just an artifact of how the demo seeds its starting pose.

Given all that, I'll implement all 5 to match upstream, independent of whether today's specific evaluation setup happens to exercise each one.