[Feature request]: Consider merging `Progress` and `Odometry` into a `RobotStatus` message or adding `std_msgs/Headers` to them

Open
  • Is something wrong?
#65 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 15 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
rust
Domain
robotics

Research direction

This is a message-design discussion, not a code change. Start by reading the existing Progress and Odometry message definitions and how the /odom topic is consumed, then the open thread on the three alternatives. Done means maintainers agree on one approach, such as a unified RobotStatus, header synchronization, or embedded pose, and the design is recorded before any implementation begins.

Written by the indexing model from the issue text.

Description

enhancement
Before proceeding, is there an existing issue or discussion for this?
Description

In our current architecture, robot pose updates are ingested via the /odom topic, while plan execution status is tracked via a dedicated Progress message. In practice, components that consume Progress almost always require a concurrent pose estimate. However, the reverse is not true (pose estimates are needed even when no plan exists).

This coupling creates desynchronization issues across several core subsystems:

  • Visualization & State Desync: Visualizers consume odometry to render robot position and simultaneously update progress, safe zones, and remaining trajectory rollouts. Under network latency or packet loss, out-of-order delivery results in transient rendering artifacts (e.g., rendering a robot outside its SafeZone because odometry reflects an older state than the latest progress update).
  • Plan Server Snapshotting & Replanning: The plan server samples odometry to initialize start states for dynamic replanning while cross-referencing Progress to evaluate execution milestones (e.g., gating docking routines until sufficient path progress has elapsed). While future states could theoretically be projected from plan progress alone to account for solve latency in multi-agent path finding (MAPF), doing so requires complex predictive state modeling and risks diverging from physical reality. (Fast initial planners such as PIBT mitigate solve latency, but the requirement for tightly synchronized progress and physical pose remains).
  • Safe Zone Eviction: Safe zone deallocation/erasure logic relies on the robot's actual estimated pose rather than plan progress alone.

Because these consumers require correlated spatial and execution contexts, treating them as disparate streams introduces unnecessary synchronization overhead. Conversely, standalone odometry remains necessary outside plan execution (e.g., during startup, idling, or manual teleoperation when plan progress is undefined).

Implementation Considerations
  • Message Aggregation vs. Specialization: Merging spatial pose data into the plan progress pipeline solves synchronization for active navigation, but progress fields are meaningless when an agent is idle or unassigned.
  • Generic Status Topic: Rather than overloading Progress, defining a broader status abstraction (e.g., RobotStatus) that encapsulates pose, active execution state, and progress metrics would decouple lifecycle state from path tracking.
  • Bandwidth & Rate Matching: Odometry typically publishes at high frequencies (20–50+ Hz), whereas progress updates may operate at lower frequencies (1–10 Hz). The consolidated message rate should balance state accuracy against bus overhead.
Alternatives

  1. Header Synchronization via message_filters:
    Add a standard std_msgs/Header to Progress carrying timestamps matching the upstream /odom headers, then rely on synchronization constructs (a la message_filters::TimeSynchronizer or ApproximateTimeSynchronizer). While idiomatic in ROS ecosystems, this introduces buffer management complexity, tuning friction around timestamp tolerance windows, and latency penalties when messages arrive out of sync. In addition we would have to rewrite all of this in rust asw AFAIK I dont think rclrs has message filters yet.

  2. Embedding Pose into Progress:
    Directly embed geometry_msgs/PoseStamped within Progress. This provides immediate atomicity for active plans, but leaves edge cases where consumers must handle null or invalid progress states when an agent is idle.

  3. Unified RobotStatus Message:
    Transition to a consolidated RobotStatus message that encapsulates pose, current operational state (idle, navigating, docking, error), and an optional/sub-field for Progress. This cleanly handles both idle states and synchronized tracking during plan execution.

Additional information

If we integrate pose and progress into a unified status pipeline, we should also consider extending the SafeZone definition to reference the specific progress milestone or sequence ID that triggered its allocation/release.

Dominant language
Python
Stars
10
Forks
9
Avg merge
3h 21m
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from open-rmf/next_gen_prototype

All issues in open-rmf/next_gen_prototype

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.