Proposal for simulation interfaces

[adamdbrw]

Following ros-infrastructure/rep#410, this PR contains a first version of simulation interfaces.

[peci1]

As stated in the comments, I think EntityState should not be a part of Entity. Instead, a message EntityWithState could be created to bind the two.

[azeey]

I left a couple comments. Unfortunately, I haven't had much time to review this PR, so there are still parts I haven't reached. I'll be on vacation for a couple weeks, but I'll try to make this a priority when I return.

[adamdbrw]

All comments so far have been addressed, please take another look and approve / suggest changes.

[DLu]

Thank you for putting in this work.

For progress sake, you may want to consider breaking this up into several PRs. If you made one with just the package metadata, then merge that immediately, and then the other bits can go in chunks.

I'd also like to integrate another interface for collisions but that is blocked at the moment.

[adamdbrw]

@DLu thank you for the review, I applied most of your comments and responded to remaining 2 with some argumentation.
I am open to break the PR down if needed, and to include collisions at a later stage (once this one is merged)

[azeey]

Sorry for the long delay in responding. I like the scope of the PR and the direction it's been evolving so far.

I'd like to ask if @omichel would also chime in for the Webots perspective.

[azeey]

I think for ground truth twist, the body twist has to be expressed in the world frame. In the convention mentioned in ros2/common_interfaces#240, we'd have:

body_frame_id = "frame_name_of_entity" 
header.frame_id = "world"
reference_frame_id = "world"

@tfoote can you confirm? When both header.frame_id and reference_frame_id are "world", it looks like a spatial twist, but that's not what we need here. Maybe we need to clarify that the VelocityStamped message always represents body twists, but expressed in the frame specified by reference_frame_id.

[adamdbrw]

@azeey @tfoote once you confirm, I would welcome a suggestion or an extra context to make sure I understand and apply this correctly

[sea-bass]

@DLu asked me to take a look at this due to my work on https://github.com/sea-bass/pyrobosim -- as such, you now have even more feedback in this very ambitious (and unenviable) task of standardizing such a thing.

Hope this is helpful!

[azeey]

Sorry, this field makes more sense as an input for the GetSpawnables service. I'd imagine a simulator can have multiple sources of spawnables:

1. Local disk (other ROS packages, files placed in directories where the simulator expects, etc.)
2. Remote (Files from a remote service, such as Fuel)

Both of these sources may have subcategorizations to limit the number spawnables returned as well the depth of searching required.

We could make the field an array of strings and let the simulator define what the values are, or we can make them enums if there is broad agreement on what the enums should be. I lean toward an array of strings.