add a github workflow to build the container and push it to our registry

[marc-hanheide]

A GitHub workflow should be added that automatically builds the container image and pushes it to our registry. The documentation and docker-compose.yaml should then be updated to use the released image. The docker compose file should also be updated to take information from a .env file and this should be documented to ease use without having to check out the entire source base. The aim is that people just download the docker-compose.yaml file and then can ran it with a local .env file that docker compose uses.

[cooperj]

Hi both,

There's a slight problem with the way it works. In the new Docker container, it doesn't open correctly or is missing crucial steps for it to work.

The rosbags provided from @rajithadesilva yesterday didn't work as expected; I don't think they have an image topic inside of them to calibrate from. They're captured from a dogtooth robot.

---

Copilot and I have been working through getting it working but we've hit a limit on what can be delivered. It does mention that it works with the Kitti dataset out of the box; so I've added a function to download and test this and will keep you updated how far I get, but it does not work as smoothly as I expected.

I think this needs re-evaluation on where it stands for our use case.

The first issue I see is that we are running both ros1 and ros2, with the bridge in between the two; are we better off asking Copilot to have a go at rewriting this to purely ROS2. While we are there take it as an opportunity to clean up the code and simplify it down.

I'd also like it to have the ability to probe the ROS topics (etc) and look for the appropriate topics to have it configure itself; for example looking at the data type to infer the type of data that is coming in. Perhaps tie this together with some user interface to exclude 'irrelevant' topics once detected.

The other question is an implementation detail, but how do we want this to be deployed? Theoretically, Is this something that would only need be run; once-ever, once-per-day, or continually during operation?

I think that raises the important question regarding how much effort is put into this single component, if it is going to be less often there is less benefit from making it more resilient.

@marc-hanheide, let me know how you would like to proceed with this.