Proof of concept for headless SDF exporting

[luca-della-vedova]

New feature implementation

Implemented feature

Add support for SDF exporting as well as a headless export mode for integration with the legacy pipeline.
For more details refer to the tracking issue#210

#212 and #214 have been locally merged to get a fully working branch

Implementation description

The headless part has been pretty hacked together but hopefully it doesn't affect the rest of the codebase too much since it happens in a completely separate executor / execution path.

[mxgrey]

I've finished reviewing the whole PR. I think the vast bulk of it is good to go, but I left some comments about places where we can have more graceful failures (i.e. avoid unwrapping).

I also left some feedback on the new camera poses feature. I think most of my feedback can/should be addressed in a follow up PR so we don't needlessly block this PR for too long, but there are two pieces of feedback that I think are worth addressing before we merge this PR:

1. I think CameraPoses should be renamed to something like UserCameraPoses to clearly distinguish it from the poses of simulated camera devices.
2. I'd rather not automatically change the user's camera pose when switching between levels.

[mxgrey]

It's awesome to see this in action 🤩

This is a huge step forward towards the next generation. Thanks for getting this to work!

[arjo129]

I tried this it works great. For usability I ran into 2 small issues:

1. It'd be great if we informed the user that the export was successful.
2. Generated SDF does require that the right Gazebo environment variables are set. Perhaps we should also export a ros package with a launch file in it? (Since gazebo<=>ros integration is much better, this seems rather sensible)

I probably can open PRs early next week for (2).

[luca-della-vedova]

I tried this it works great. For usability I ran into 2 small issues:

1. It'd be great if we informed the user that the export was successful.
2. Generated SDF does require that the right Gazebo environment variables are set. Perhaps we should also export a ros package with a launch file in it? (Since gazebo<=>ros integration is much better now this seems rather sensible)

I probably can open PRs early next week for (2).

1. There should already be a printout when export is successful / fails, what I wanted to do next is make the app return a non zero exit code when it is run in headless export mode and exporting fails. This will make colcon build fail to build the package and flag to the user what went wrong.
   This is currently blocked on 0.14 being released and a migration to it. Then we will be able to set error codes for AppExit Make AppExit more specific about exit reason. bevyengine/bevy#13022.

2. Agreed, I think there are two fundamentally different ways to do go at this SDF support, both have pros and cons:

• Make the export only save the world file / models, depend on external launch files. This makes it pretty much a rmf_building_map_tools replacement and plugs in the current pipeline without any change. It's the current approach but admittedly it is not able to actually generate a package from scratch and has to be part of either a manual step or a "CMakeLists" approach as we have been doing.
• Make the export generate a whole package, it will make the feature more standalone but then we might have to ask users to commit the whole generated package to version control, and the generated package will still have to be built through colcon build otherwise it won't be launchable.

[mxgrey]

Since this capability is only meant to make the site editor a replacement for the building map tools, I think the current environment variable situation should remain as-is.

If we want to make the simulation pipeline with gazebo easier, that should be its own follow-up discussion.