YAML-driven AutonomyMetricsLogger

[ibrahimhroob]

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update

Description

This feature introduces a dynamic ROS 2 node that logs critical autonomy metrics (e.g., total distance, incidents, speed, and Mean Distance Between Incidents (MDBI)) to a MongoDB database. Unlike hard-coded loggers, this node is entirely driven by a YAML configuration file, allowing for flexible and dynamic subscription to any ROS 2 topic and field without requiring code changes.

Key Features

• Dynamic Subscription: Subscribes to topics and extracts specific fields defined in the YAML file.

• Role-Based Processing: Recognizes special roles (odometry, control_mode, estop) to automatically calculate and manage core metrics like distance, speed, and autonomy time.

• Dynamic Publishing: Can mirror specific message fields to new topics, acting as a lightweight data filter/converter.

• MongoDB Integration: Initializes a session upon startup and continuously updates metrics and logs events (incidents, mode changes, etc.) to a MongoDB collection.

• Robustness: Includes a stop-detection logic to accurately report robot speed as zero when odometry updates cease.

---

⚙️ How to Use and Configure the Logger

The logger is controlled entirely by the config_yaml parameter, which points to the YAML configuration file (e.g., metrics_full.yaml).

1. Launch Arguments

When launching the node, ensure you pass the correct parameters, especially if running in a containerized environment (like Docker):

Parameter	Type	Default	Description
config_yaml	string	''	Required. Full path to the YAML configuration file.
mongodb_host	string	localhost	The hostname/IP of the MongoDB instance (Use host.docker.internal if running Mongo on the Docker host).
mongodb_port	int	27017	The port of the MongoDB instance.
min_distance_threshold	double	0.2	Minimum distance (meters) the robot must travel before updating total distance/speed metrics. Acts as a noise filter.
stop_timeout	double	2.0	Time (seconds) without an odometry update before the logger forces the reported speed to 0.0.

C. Control Mode Example

The control_mode role requires mapping the raw value from the topic message into the logger's required state (Autonomous or Manual).

YAML

  - name: "/gophar/operation_mode"
    type: "std_msgs/msg/String" 
    role: "control_mode"
    mode_field: "data"  # Field inside the message (e.g., String.data)
    mode_mapping:
      "AUTO": "Autonomous"
      "MANUAL": "Manual"
      "1": "Autonomous"
      "0": "Manual"

Related Tickets & Documents

• Related Issue #
• Closes #

QA Instructions, Screenshots, Recordings

Please replace this line with instructions on how to test your changes.

[optional] Are there any post deployment tasks we need to perform?