feat(sim): publish structured /rmf_simulation/collision_event JSON on emergency stop

[jayDevCodes]

This small change publishes a structured collision event on when a model triggers an emergency stop.

• Uses existing std_msgs/String (JSON payload) to avoid adding new message types.
• Publishes JSON containing:
  • time, robot_name, other_entity (currently empty), contact_point (zeros)
  • severity (2 = critical for emergency stop)
• Publisher is created in init_ros_node for each model (best-effort).
• No world pause by default; a node parameter pause_on_collision can be declared to request pause (not implemented in this context).
• No new files were added — this is an in-place improvement for programmatic collision detection so test harnesses can detect collisions automatically.

How this helps:

• Test harnesses (e.g., stress_test_rmf_chope) can subscribe to /rmf_simulation/collision_event and fail tests automatically when collisions occur.
• Small, non-invasive change that addresses the need to detect collisions programmatically.

[arjo129]

@jayDevCodes, I think @yenode is already working on this specific issue. I'd rather not have more than one person work on such a small task. Perhaps you can look at rmf demos and @yenode's PR and see if we can automate success criterion for the tests.

[jayDevCodes]

Hi @arjo129,

We reviewed Yenode’s work and the demos. To automate the test pass/fail result, we plan to update the slotcar plugin so it publishes a ROS2 flag when an emergency stop happens (for example: collision_event = true).

In the stress_test, we will add a subscriber that listens to this flag. The test will fail if the flag is triggered or if any robot’s mode becomes WAITING.

This way we can use Gazebo’s built-in collision detection through the slotcar logic and connect it to a topic that can be tested automatically.

We can prepare a draft PR soon. Please let me know if this approach looks good to you.

Thanks!

[arjo129]

This solution feels overcomplicated and is a duplicate of #160

[arjo129]

Why do this? It makes no sense to have a per model publisher it'll just flood DDS discovery and make detecting failures harder.

[jayDevCodes]

The std::lock_guardstd::mutex lk(g_collision_pub_map_mutex); protects access to the global g_collision_pub_map to avoid data races — init_ros_node() may insert the publisher while emergency_stop() (or other threads) read/publish from the map, so we must synchronize those accesses.

[arjo129]

Please don't upload macos metadata.

[jayDevCodes]

Thanks for pointing that out. I’ve removed .DS_Store from the repository and added it to .gitignore so macOS metadata files won’t be committed again.

[arjo129]

Don't remove the newline.

[arjo129]

We can edit the header file.

[arjo129]

We probably should avoid json magic here. Either use nlohman-json or we should just use a custom message.

[jayDevCodes]

agreed.

[arjo129]

@jayDevCodes , please update the PR template honestly as to whether you used GenAI for the PR. The OSRA policy for GenAI requires that you disclose any use of gen AI (we. are not against genAI but you need to be honest). Failure to do so will not bode well for any GSoC applicant.

[jayDevCodes]

@arjo129 I only used an AI assistant to help spot/fix small bugs and tidy up the code for readability. The design and core logic are implemented by me, which is the main part of this work. — happy to revert or adjust any edits you prefer.

[arjo129]

Have you read the policy I linked? Any use of AI must be declared in the PR description and commits. Not declaring it means dishonesty. I will be closing this PR as there is a better solution already.