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.

[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 https://github.com/bevyengine/bevy/pull/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.