Autoware Dockerfiles clean up

[sgermanserrano]

New Feature

The current level of duplicity within the Dockerfiles can be removed.

4 cases of usage for the docker images have been identified (without considering cross-compiling):

1. Environment without CUDA support
2. Environment with CUDA support
3. Autoware built without CUDA support
4. Autoware built with CUDA support

The above is translated into 4 Docker images and 3 Dockerfiles:

1. Base image with all non-CUDA related dependencies. (Dockerfile.cpu.kinetic_dependencies)
2. Base image with CUDA related dependencies built from 1. (Dockerfile.cuda.dependencies)
3. Autoware built on top of 1. (Dockerfile.autoware)
4. Autoware built on top of 2. (Dockerfile.autoware)

To keep the current state of build, case 4 can be set to be the default one in the build.sh and run.sh scripts.

The split of Dockerfiles should also help at building Autoware docker images automatically.

[amc-nu]

@servando

I’ve been working exactly in that
Please have a look at:

https://github.com/CPFL/autoware_docker_images

The images are implemented in that order with an extra layer. This allows to run within the allowed time in Travis CI and Docker Hub. Please let me hear your opinions, and feel free to change the repository.

[filiperinaldi]

Hi @amc-nu Me and Servando had a go on this last week during a Hackathon. I pushed what we have done (not complete) so we can compare and join efforts.

• We kept it within the Autoware repo for simplicity
• Nothing is duplicated, generic stuff like installing ROS and creating user are only on the base image
• We can have images using the same docker built on both Arm and x86_64
• Cuda support is orthogonal (and enabled by default). Can be disabled with "--cuda off" for system that do not support it.

[sgermanserrano]

Solved in autowarefoundation/autoware#1946