Isolate Gazebo from a particular drone instance

[mhl787156]

The purpose of this PR is to isolate the creation of gazebo/ gzweb from any particular drone deployment. This is to allow straightforward deployment of additional drones into the simulation. This was achieved by creating a new dockerfile starling-sim which performs a multi-build based on all of the drone specific Dockerfile builds. It is assumed that the individual drone build processes all build into \ros_ws. starling_sim then copies the \ros_ws from all specified drones.

A general launch file launch.xml is then used to launch Gazebo and the drones depending on args specified to be true. Current args are gazebo, clover2 and iris. These call the drone specific launch files already specified. The current set up is not ideal, having a single vehicle arg would be preferable but ros2 launch bugs are causing issues: https://github.com/ros2/launch/issues/469#issuecomment-785951620

The Dockerfile launches the specified launch file with the environment variable GAZEBO_VEHICLE set to gazebo as default. ros2 run launch launch/launch.xml ${GAZEBO_VEHICLE}:=true (The extra /bin/bash -c is required to resolve the env variable).

[mhl787156]

There are a number of things still to do including:

• Converting existing docker-compose.yaml to use starling-sim
• To test with kubernetes
• To upload starling-sim up to docker hub (once this pr has been merged) But to reduce the size of each PR, going to do this once this has been merged.

[rob-clarke]

One note: the sim-clover2 image already contains all the necessary files for the iris drone, except for the launch file.

[mhl787156]

Yeah I guessed, however felt it was more consistent for future drone additions if I was explicit in the Dockerfile. In the future this docker image could even be autogenerated!

[rob-clarke]

Ideal solution

The ideal solution would be an image that just has Gazebo and gzweb installed. Required model files (including plugins) could then be included by mounting volumes into it which are picked up by the entrypoint (Potentially using /ros.env.d as suggested on the main README). The gzweb entrypoint would in turn pick them up and webify them.

There would then be per-vehicle images built on the SITL images. The drone image would therefore contain the SITL (configured for that vehicle), the required model files, and the call that spawns the matching model in Gazebo. I feel that's neater than our current approach of needing to spawn a SITL and a model separately. As a counterpoint, there may be use cases where a simpler sim is wanted so tying in Gazebo stuff would make the SITL images a bit more unwieldy. There's also the problem of multiple vehicle types needing the same underlying plugins and how Gazebo would deal with that.

The major problem with that approach currently is that the package containing the spawn script depends on the whole of gazebo which does inflate the image slightly. Building plugins also depends on gazebo-dev.

For both Peiman's and my own projects, we've ended up building models from scratch, so getting a workflow for that would be ideal.

This all supposes we are primarily using Gazebo, but AirSim or similar may prove to be a better fit.

This solution

There is the question of which models to include in a common image. For now, the clover model doesn't work (fly) in the sim so I'm not sure there's much value in including it in the image.

If it's a common image I feel it shouldn't spawn any vehicles as part of its default launch file. That can live in separate launch files and be adjusted with the image cmd.

[mhl787156]

The ideal suggestion sounds fantastic, although I'm concerned that it might end up being quite complex to get going, and to cater for the majority of use cases. We need to do some testing to see if you can hot bind/ hot attach volumes containing pre built models which gazebo can access at runtime. I am concerned that what you describe might be a tad challenging from the kubernetes side, may need to create some 'model-server' type pod. For the current image, we should look into removing the build tools once built.

For the current solution, I agree. I would like to include it and somehow make it fly since I have the real thing sat next to me (also issue #21), right now I don't think it's a detriment to the image by including it but we can revisit this in the future if things really don't work.

When creating the launch files I did toy with the idea of having separate for gazebo/vehicles. But as we will be running via Docker CMD, having to provide a custom command to spawn a vehicle in docker run/ docker-compose or kube configs seemed like a bad tradeoff. The other option is to have starling-sim only run gazebo and each drone addition (e.g. starling-sim-iris) run in its own container - which you can essentially do now (if 'drone only' was exposed as an environment var). The current set up I suppose is a middle ground, the default starling-sim only runs gazebo by default, then you can add drones either by specifing an env variable, or by starting one of the drone images yourself. I guess there's a tension between thinking of the system in terms of direct ROS vs thinking in terms of just using containers.

Are you happy with the current set up - To be revisited at a later date? Or do we want to discuss this further first. Right now I essentially want a clear mechanism for spawning multiple drones so we can start implementing and testing our ID system. It seems dangerous to only stick to starling-sim-iris, especially if/when I get into the flight arena!

[mhl787156]

@rob-clarke should we close this PR for now then? I will just use starling-sim-iris for my testing

[rob-clarke]

Yeah I think hold off for now until we get the clover model flying

[mhl787156]

This is now stale so closing PR