Currently there exist two ways of adding vehicles and worlds to simulations
Modify the base docker images to include the worlds or vehicles, and rebuild all of the containers in the correct order (e.g. make iris)
Utilise the /ros.env.d paradigm to mount in new models and worlds, and have the setup.bash add these to the gazebo container paths.
The latter method works great in Docker-Compose as it all happens a runtime
The downside comes if you wish to 'package up' your environment into a Dockerfile, as this ends up forming a tree of container dependencies. E.g. right now if I wanted to run a custom model inside the BRLFlgihtArena, we have the following container tree:
With the first 3 in the ProjectStarling Repo, the next in BRLFightArena repo and the last in my own projects repo. If I then wish to change the world or something else, I am then stuck with dealing with this chain. Also if something changes in the ProjectStarling Repo, there exists this long chain of contianers which also need to be rebuilt!
I think we need some more compositional and structured way of providing this functionality. My suggestion is a base-simulator-template repo, along with repo stubs which represent individual models or worlds.
The template repo has two folders of 'models' and 'worlds' in which the internal Dockerfile and docker-compose will mount (into ros.env.d), and source from. This way every users simulator can be built upon the same base, and we have a level of reuseability.
Perhaps the choice could be asked for a PX4 or Ardupilot or None simulation, in which either starling-sim-base-core, starling-sim-base-px4 or starling-sim-base-ardupilot is used as the parent Dockerfile.
Currently there exist two ways of adding vehicles and worlds to simulations
/ros.env.dparadigm to mount in new models and worlds, and have the setup.bash add these to the gazebo container paths.The latter method works great in Docker-Compose as it all happens a runtime
The downside comes if you wish to 'package up' your environment into a Dockerfile, as this ends up forming a tree of container dependencies. E.g. right now if I wanted to run a custom model inside the BRLFlgihtArena, we have the following container tree:
starling-sim-base-core <-> starling-sim-base-px4 <-> starling-sim-iris <-> starling-sim-iris-px4-flightarena <-> starling-sim-iris-px4-flightarena-with-my-new-model
With the first 3 in the ProjectStarling Repo, the next in BRLFightArena repo and the last in my own projects repo. If I then wish to change the world or something else, I am then stuck with dealing with this chain. Also if something changes in the ProjectStarling Repo, there exists this long chain of contianers which also need to be rebuilt!
I think we need some more compositional and structured way of providing this functionality. My suggestion is a base-simulator-template repo, along with repo stubs which represent individual models or worlds.
The template repo has two folders of 'models' and 'worlds' in which the internal Dockerfile and docker-compose will mount (into ros.env.d), and source from. This way every users simulator can be built upon the same base, and we have a level of reuseability.
Perhaps the choice could be asked for a PX4 or Ardupilot or None simulation, in which either starling-sim-base-core, starling-sim-base-px4 or starling-sim-base-ardupilot is used as the parent Dockerfile.
@rob-clarke thoughts?