Investigate ROS2 node connection external to Starling

[mhl787156]

Brought up by Arthur, a use case is for MSc students to use this system to fly drones. Many students may not have the technical knowhow with regards to docker/kubernetes and computer related things. Currently all ROS interactions are assumed to be within the kubernetes/docker environment.

To easier facilitate use, it would be preferable if a user running ROS 'bare metal', i.e. not inside a docker container, could also interact with Starling ros nodes running through docker environments.

[rob-clarke]

This Just Works™ for me when:

• Using the k8.mavros.arm64.yaml deployment on the droneconfig branch
• Deploying to a RasPi connected to a PixHawk
• With everything running network host

Admittedly, the local ROS2 stuff was also in a container, but not a Kubernetes managed one as I haven't installed ROS2 on my machine.

The SITL case is likely more complex but for the simple single SITL case under compose it shouldn't be too different.

[mhl787156]

Interesting, I think we need to investigate this a little more. I can foresee the following use cases I suppose:

• [ ] ROS2 bare metal running on the master node also running the kubernetes master.
  • [ ] Only RasPi pods are running (i.e. no local mavros/sitl pods)
  • [ ] Only local mavros/sitl pods
  • [ ] A mixture of RasPi and Mavros/Sitl pods.
• [ ] ROS2 running in a docker container on the master node also running the kubernetes master.
• [ ] ROS2 bare metal running on a different machine which is on the same network as the kubernetes master
• [ ] ROS2 running in a docker container on a different machine which is on the same network as the kubernetes master

[rob-clarke]

Maybe its the process namespace / rmw GUID conflict problem popping up again

[mhl787156]

For reference the Just Works is likely because everything there is running local host on its own network. ROS2 seems to communicate fine between containers (kubernetes or otherwise) on the same subnet.

Core challenge is either across subnets (Referenced by #49 ) or across localhost -> kubernetes for this issue.

I think the only real solution is to use Static DDS servers which sit on multiple networks (and multiple of them) and configure all ROS nodes to point to these servers. This will be baked into all ros images.

[rob-clarke]

My problem with static DDS servers is that is it adds a load of infrastructure that would need to be replicated in the shift to outdoors. It also raises questions about the workflow for someone working purely on their local machine; would they be required to launch DDS servers locally to use the standard images?

Is there actually a problem with just running everything network=localhost? All the dancing with port numbers with PX4 SITL was originally put in there to enable running multiple instances on the same network stack.

[mhl787156]

So referring to my comment here I still need to do some experimentation. Best case scenario, it's one additional pod running on the master and the user doesn't have to do anything except maybe set an environment variable. I'm fairly certain in all cases, users will not need to launch their own servers.

I tried network=localhost for a bit but I couldn't get it to work. Had issues like SITL not connecting to gazebo and services not being very happy haha. I can try again if that would be preferable.

However I think we still need a discovery server gateway between Bare metal ROS and kubernetes/docker ROS.

[mhl787156]

I believe this has been solved by running everything net=host. Any machine on the arena network has access. Similarly with anything running locally.