I want to open up a discussion on the matter of simulations for OpenRMF as we transit into the next iteration or generation of middleware.
Background
The current OpenRMF relies heavily on Gazebo for its simulations. While convenient, Gazebo runs very heavily on physics, which might not be fully utilized.
The default robotic fleets work on a very simple point-to-point style of navigation, while doors and lifts have a simple lift controller to serve as a proxy to test and showcase the features of OpenRMF.
Transition to Next Generation
As we go forward to the next iteration, we can actually look at what we can and want to do with OpenRMF simulations.
With the site editor progressing steadily, we have two possible paths that we can take in terms of simulations.
The first is to have simulations embedded into the site editor, making the site editor a powerful application that comprises all the elements of OpenRMF, from map definition to the OpenRMF’s core and simulations.
The second is to have a separate pipeline that allows users to run simulations.
There are some merits to either solution, but we can start laying down some common groundwork while discussing to see which option is better.
A Bevy library that contains common infrastructure elements like doors and lifts
This can be helpful when designing a simulation for OpenRMF where doors and lifts integrations are one of the focus.
A robot fleet simulator on Bevy
Potentially a Bevy library that allows users to add robots with a simulated navigation stack that moves around Bevy-defined entities.
Workcell integration
Potentially a Bevy package that allows users to add workcells with basic motion planning capabilities
The focus should be on creating visual representations of the workcells while allowing interaction with OpenRMF. We should utilize existing crates to perform robot control, like motion planning and joint control.
PS: I will try to update the main thread periodically as the discussion grows, so please do point out any misinformation or confusion in the main thread.
I think its great to have point-to-point simulation in bevy (aka Event driven simulation). We can definitely handle lifts and doors without the full physics from gazebo. However, there is still some value in providing SDF worlds that get exported to gazebo. For instance, if an end user wants to do E2E testing with FreeFleet, it makes sense to build on gazebo’s existing infrastructure (we don’t have an example for this, but it’d definitely be nice to have). Similarly if I want to integrate a non-rmf based system with rmf, (for instance some new type of sensor like a Lidar system for detecting obstructions) gazebo still has more sensor models for us to use.
Workcell integration
Motion planning is a huge can of worms. While we can use prerecorded paths in bevy (perhaps building on k and open-rr’s work), I can imagine that this will be a non-trivial amount of work. We really should build on other peoples work for this rather than re-inventing the wheel.
I think its great to have point-to-point simulation in bevy (aka Event driven simulation). We can definitely handle lifts and doors without the full physics from gazebo. However, there is still some value in providing SDF worlds that get exported to gazebo. For instance, if an end user wants to do E2E testing with FreeFleet, it makes sense to build on gazebo’s existing infrastructure (we don’t have an example for this, but it’d definitely be nice to have). Similarly if I want to integrate a non-rmf based system with rmf, (for instance some new type of sensor like a Lidar system for detecting obstructions) gazebo still has more sensor models for us to use
Maybe we can explore to see if we can have the best of both worlds (event-based using Bevy and physics-based with Gazebo).
Hopefully, the design of the next OpenRMF can be configurable to adapt to either simulator.
For the event-based, in theory, it should be as straightforward as adding the simulator plugin into the Bevy application.
For Gazebo, we can opt for ROS or Zenoh to get and pull information from Gazebo.
Motion planning is a huge can of worms. While we can use prerecorded paths in bevy (perhaps building on k and open-rr’s work), I can imagine that this will be a non-trivial amount of work. We really should build on other peoples work for this rather than re-inventing the wheel.
Yes, I agree with not re-inventing the wheel. The focus of the event-based simulation should be purely the interaction between the simulator and OpenRMF, while providing visual representation of the states of the arm.
As a user rather than a core developer, I don’t have insight into the detailed roadmap for next‑generation Gazebo. I’m curious whether it will add stronger native support for event‑driven / discrete‑event simulation, or potentially incorporate Bevy‑style event handling logic. If so, that could let Open‑RMF depend more directly on Gazebo without a separate simulation pipeline. Would anyone from the Gazebo team share their thoughts on this?
From the Gazebo roadmap, I see you’re leading the low-fidelity / faster-than-realtime work (kinematics in Dart & Bullet, kinematics mode w/o SDF changes).
Any thoughts or plans in next-gen Gazebo for stronger native support of event-driven / discrete-event simulation, or something Bevy-like for event handling?
That could help Open-RMF lean more directly on Gazebo without a fully separate pipeline.
From the Gazebo roadmap, I see you’re leading the low-fidelity / faster-than-realtime work (kinematics in Dart & Bullet, kinematics mode w/o SDF changes).
Something called the “Trivial Physics Engine” (TPE) has existed in Gazebo for many years now, motivated in part by the Open-RMF project which wanted much-faster-than-real-time simulation. The Open-RMF project experimented with it for a while but the increase in real time factor wasn’t as significant as we expected (something like 5x-10x when we were hoping for 100x-1000x) and didn’t seem to improve how well the simulation scales to more robots. It also took significant work to maintain because it needs custom plugins for things like moving the robots up and down elevators, and those elevator plugins need to interact nicely with the other plugins that control the robot motions.
That could help Open-RMF lean more directly on Gazebo without a fully separate pipeline.
A big part of the motivation for event-driven simulation within Bevy is to use it directly in the Open-RMF Site Editor. The process of taking an edited facility, generating it into a Gazebo world, and launching that simulation is somewhat cumbersome to do for every small change that a user might make. We’d rather be able to provide a minimalist discrete event-driven simulation directly inside the site editor that can be run without any exporting or external pipeline.
We’d continue to support the existing SDF world export and Gazebo simulation pipeline, because that would serve a different use-case: Providing a full physics simulation of the operation. This would likely become the final step in simulated validation of a deployment instead of being something that’s done incrementally in a rapid development loop.
Gazebo is already looking at Bevy for physics-based rendering, so if the Gazebo team considers using Bevy for a discrete-event simulation alternative to gz-physics then of course the Open-RMF team will be eager to share whatever we develop towards that end.