Docker Compose with Multiple Drones

[mhl787156]

This PR was primarily to provide a method of using docker-compose to fly multiple drones. In implementing this, the following issues and bugs had to be fixed:

• Closes #94 All drones were utilising the same TF namespace making TF based navigation impossible. mavros_setup.sh now changes the contents of a local mavros_config.yaml and passes these to mavros.
• Fixes a bug in which manually providing MAVROS_TGT_SYSTEM causes the FCU_PORT to be set incorrectly to the default of zero. When calculating the port, the INSTANCE is only dervied from an ordinal HOSTNAME. Now if MAVROS_TGT_SYSTEM is set, the INSTANCE is set to MAVROS_TGT_SYSTEM - 1.
• A new docker-compose file is created (based on the kubernetes deployment) which deploys two drone stacks, Gazebo, UI and Allocator.

TODO:

• [x] Fix bug which is causing both drone's mavros instances to die on takeoff (running docker-compose-multiple.yaml

Note: in run_ros1.sh the error stream has been piped into /dev/null. This is to allow debugging without the TF_REPEATED_DATA ignoring data with redundant timestamp warning from cluttering the entire screen. Unsure as to a solution of this, ideally we can filter out these warning messages as they do not appear dangerous. Cannot find a way to remove these messages otherwise, no clue what might be causing these issues...

[mhl787156]

@rob-clarke Any chance you might be able to have a look at this bug? I am absolutely stumped as to what might be happening. Essentially when running multiple mavros instances, when a command is sent, both the ros12 bridges die at the same time. I have a feeling this might be something to do with running multiple ros1/2_bridges at the same time and how its probably not designed for that. Up for any ideas you might have!

1. I run docker-compose -f docker-compose-multiple.yaml up
2. Open up gazebo on 8080 and the UI on 3000/load-trajectories
3. Click confirm and submit trajectories -> Manual allocation -> Give the traj to either drone
4. UI takes you to control panel, Press GO
5. Simple offboard ARMS and puts into OFFBOARD mode, attempts takeoff
6. Both Dynamic Bridges in both mavros instances die at the same time.

[mhl787156]

On further thought, if it is the case of difficulties caused by having two ros bridges running on the same system, I suppose we have the following options:

• Take out the bridge to run centrally. But this breaks the abstract organisation of 'drone'. Also not ideal for running on real-drones.
• Find someway to isolate the bridge to only bridge comms in its namespace
• Get rid of the bridge alltogether and migrate to ROS2 MAVROS

[mhl787156]

Sorry stray thought, I think the TF_REPEATED_DATA may be due to the bridge re-publishing any TFs that come in between ros1 and ros2. If \tf is treated just like any other topic then it will be republished. However since both ros1 and ros2 use the same transform library tf2 there may be a weird cross error where transforms get double published.

Evidence in also the fact that if mavros/local_position/tf/send set to true (i.e. broadcasts its own tf) there are no warning messages coming up.

May need to add some notion of white-listing, may also help with the above error.

[mhl787156]

The bug in which running a trajectory with multiple mavros containers causes both ros1 bridges to die has been fixed. The ROS1 bridge now uses the parameter bridge instead of the dynamic bridge. The parameter bridge requires that a yaml file specify the list of topics and services in which that bridge operates.

The latest commits make the following changes:

• Like the dynamic configuration of mavros_config.yaml based on VEHICLE_NAMESPACE, a new configuration bridge_config.yaml specifies the mavros topics which we should pass through. On runtime, the bridge_config.yaml is rewritten to include the VEHICLE_NAMESPACE in the topic names.
• To allow the successful use of the dockerfile, an edit to the parameter bridge source is required where line 41 has to be moved up (see https://github.com/ros2/ros1_bridge/issues/316). This fix is put into the Dockerfile before building.
• Following the instructions (here https://github.com/ros2/ros1_bridge/pull/330) the yaml file is read in as a parameter file by ROS1 in the launch file.
• The ros_bridge is run with arguments before the remapping. This is because the arguments for namespe remapping (--ros_args -r __ns:=<new ns>) are misinterpreted by the parameter bridge which expects the arguments to be the names of the parameter titles within the config yaml. Therefore we must provide these arguments for the namespace remapping to be successful.
• The \tf is not included in the bridge_config.yaml which has now removed the re-publishing warnings! Therefore stderr is no longer piped into /dev/null in run_ros1.sh

I think that covers the core issues and this PR should be ready to merge

[rob-clarke]

Please add some docs