Initial, internal review of RFC to be submitted to o3de/sig-simulation #1

michalpelka · 2025-03-04T17:26:11Z

No description provided.

Signed-off-by: Michał Pełka <[email protected]>

PawelLiberadzki

Great aggregation of all concepts in this topic. These are my comments to the first part of this RFC. Tomorrow I will add more.

rfcs/RFC Simulation Interfaces.md

jhanca-robotecai

Great work.

What I miss in this RFC is a few more technical details listed in the comments.

rfcs/RFC Simulation Interfaces.md

jhanca-robotecai · 2025-03-05T13:53:03Z

rfcs/RFC Simulation Interfaces.md

+The implementation will be split into three (or more system components):
+- ROS 2 Entities manager \
+ It will be responsible for the lifetime of spawned objects, it will cache initial positions.
+- ROS 2 Named poses manager \
+ It will be responsible for aggregating information in the Named Pose Game Component.
+- ROS 2 Simulator manager \
+ It will be responsible for modifying the global state of the simulation (e.g., pausing, reloading).
+
+We will decouple the implementation of those managers from the ROS 2 service.
+Every manager will need to expose public methods that will be callable both from C++ and ROS 2.
+The purpose of that approach is to enable testability without the need for a ROS domain. 


Should all system components land in the ROS 2 Gem? As a downside of the RFC you mentioned the increase of the ROS 2 codebase. Shouldn't we start thinking about splitting the Gem into smaller pieces?

ROS 2 - gem for the node and base sensor component to inherit from

RobotImporter - gem for importing URDF/SDF and possibly more

ROS 2 Sensors - gem with basic implementation of all sensors
etc.

This implementation might be the first one to think about it as you mention decoupling c++ and ROS 2 service interfaces.

Regarding this topic, we have also considered moving feature implementations (Entity manager, Named pose manager, ...) into separate Gem, and placing their ROS 2 interfaces in ROS 2 Gem. If I remember correctly, this idea was not rejected explicitly, so we may also discuss it here.

Keeping open for discussion. I think it should be a new gem

rfcs/RFC Simulation Interfaces.md

jhanca-robotecai · 2025-03-05T13:56:16Z

rfcs/RFC Simulation Interfaces.md

+- A component called `SimulationInfoComponent` will be created and attached to the root entity. 
+ That component will be used to cache information in `simulationinfo` to be easily accessible in the future.
+- [TagComponent](https://www.docs.o3de.org/docs/user-guide/components/reference/gameplay/tag/) from LmbrCentral gem at root entity will be created (if not present in prefab).
+- TagComponent will be updated with a list of new tags.


I do not fully get what is the source of new tags.

rfcs/RFC Simulation Interfaces.md

Co-authored-by: Paweł Liberadzki <[email protected]> Co-authored-by: Jan Hanca <[email protected]> Signed-off-by: Michał Pełka <[email protected]>

PawelLiberadzki

This is the second part of my remarks, covering rest of this document.

PawelLiberadzki · 2025-03-06T10:28:13Z

rfcs/RFC Simulation Interfaces.md

+The implementation will be split into three (or more system components):
+- ROS 2 Entities manager \
+ It will be responsible for the lifetime of spawned objects, it will cache initial positions.
+- ROS 2 Named poses manager \
+ It will be responsible for aggregating information in the Named Pose Game Component.
+- ROS 2 Simulator manager \
+ It will be responsible for modifying the global state of the simulation (e.g., pausing, reloading).
+
+We will decouple the implementation of those managers from the ROS 2 service.
+Every manager will need to expose public methods that will be callable both from C++ and ROS 2.
+The purpose of that approach is to enable testability without the need for a ROS domain. 


Regarding this topic, we have also considered moving feature implementations (Entity manager, Named pose manager, ...) into separate Gem, and placing their ROS 2 interfaces in ROS 2 Gem. If I remember correctly, this idea was not rejected explicitly, so we may also discuss it here.

rfcs/RFC Simulation Interfaces.md

PawelLiberadzki · 2025-03-06T10:38:32Z

rfcs/RFC Simulation Interfaces.md

+Let us investigate moving a `Simulated PhysX Rigid Body'.
+We cannot simply call :
+```cpp
+ AZ::TransformBus::Event(entityId, &AZ::TransformBus::Events::SetWorldTM, transform);


There is no need to support robots that are incorrectly made

I would follow this idea everywhere in this implementation. We rather have to make some assumptions, or put some requirements on what is supported with this implementation. Fortunately, in most places we do like that.

rfcs/RFC Simulation Interfaces.md

Co-authored-by: Paweł Liberadzki <[email protected]> Signed-off-by: Michał Pełka <[email protected]>

Signed-off-by: Jan Hanca <[email protected]>

Signed-off-by: Jan Hanca <[email protected]> Co-authored-by: Michał Pełka <[email protected]> Co-authored-by: Paweł Liberadzki <[email protected]> Signed-off-by: Jan Hanca <[email protected]>

Signed-off-by: Jan Hanca <[email protected]>

jhanca-robotecai · 2025-03-17T14:36:42Z

Comments that should be addressed - noted in #2

add information about Gems and Gem's names
clarify what is the starting state of the simulation
clean-up the sample c++ code

Signed-off-by: Michał Pełka <[email protected]>

michalpelka · 2025-03-17T15:06:23Z

Closed in favour of o3de#95

michalpelka added 3 commits February 25, 2025 16:25

Intial Commit

2e3930d

Signed-off-by: Michał Pełka <[email protected]>

WIP

2b18eda

Signed-off-by: Michał Pełka <[email protected]>

Initial proposition

cb1eba4

Signed-off-by: Michał Pełka <[email protected]>

michalpelka requested review from jhanca-robotecai and PawelLiberadzki March 4, 2025 17:26

michalpelka changed the title ~~Initial, review of RFC to be submitted to o3de/sig-simulation~~ Initial, internal review of RFC to be submitted to o3de/sig-simulation Mar 4, 2025

AI spell check

0371f98

Signed-off-by: Michał Pełka <[email protected]>

PawelLiberadzki reviewed Mar 5, 2025

View reviewed changes

jhanca-robotecai reviewed Mar 5, 2025

View reviewed changes

Apply suggestions from code review

ab9dfb7

Co-authored-by: Paweł Liberadzki <[email protected]> Co-authored-by: Jan Hanca <[email protected]> Signed-off-by: Michał Pełka <[email protected]>

PawelLiberadzki reviewed Mar 6, 2025

View reviewed changes

Update rfcs/RFC Simulation Interfaces.md

fcb1ee2

Co-authored-by: Paweł Liberadzki <[email protected]> Signed-off-by: Michał Pełka <[email protected]>

jhanca-robotecai mentioned this pull request Mar 10, 2025

Code review of RFC - Simulation Interfaces #2

Merged

jhanca-robotecai and others added 4 commits March 17, 2025 15:33

Code review changes up to GetNamedPoses

9605515

Signed-off-by: Jan Hanca <[email protected]>

Code review changes after GetNamedPoses

735bb3d

Signed-off-by: Jan Hanca <[email protected]>

External code review changes

26d2361

Signed-off-by: Jan Hanca <[email protected]> Co-authored-by: Michał Pełka <[email protected]> Co-authored-by: Paweł Liberadzki <[email protected]> Signed-off-by: Jan Hanca <[email protected]>

Rename RFC file to keep consistent

ea295f1

Signed-off-by: Jan Hanca <[email protected]>

michalpelka added 2 commits March 17, 2025 15:53

move to RFCs dir

b0cebef

Signed-off-by: Michał Pełka <[email protected]>

remove easter egg

b8cb61c

Signed-off-by: Michał Pełka <[email protected]>

michalpelka force-pushed the rb/sim_interfaces branch from 357ff6d to b8cb61c Compare March 17, 2025 14:59

michalpelka mentioned this pull request Mar 17, 2025

RFC : Simulation interfaces o3de/sig-simulation#95

Merged

michalpelka closed this Mar 17, 2025

Initial, internal review of RFC to be submitted to o3de/sig-simulation #1

Initial, internal review of RFC to be submitted to o3de/sig-simulation #1

Uh oh!

Conversation

michalpelka commented Mar 4, 2025

Uh oh!

PawelLiberadzki left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jhanca-robotecai left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jhanca-robotecai Mar 5, 2025

Choose a reason for hiding this comment

Uh oh!

PawelLiberadzki Mar 6, 2025

Choose a reason for hiding this comment

Uh oh!

michalpelka Mar 7, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jhanca-robotecai Mar 5, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

PawelLiberadzki left a comment

Choose a reason for hiding this comment

Uh oh!

PawelLiberadzki Mar 6, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

PawelLiberadzki Mar 6, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jhanca-robotecai commented Mar 17, 2025 • edited by michalpelka Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michalpelka commented Mar 17, 2025

Uh oh!

Uh oh!

jhanca-robotecai commented Mar 17, 2025 •

edited by michalpelka

Loading