Version Controlling Software Dependencies: A Take on Modern Robotics
In robotics, software has always been tricky to maintain and distribute. Historically, the challenge was bundling code so it could run consistently across different developers’ machines, hardware architectures, and sometimes even entirely different platforms. As a result, collaboration and debugging were often more art than science.
In recent years, containerization technologies such as Docker have changed the landscape dramatically. By packaging software and all its dependencies into lightweight, portable units (e.g., in Docker containers), and by “freezing” specific versions of libraries and tools, containerization ensures that applications behave the same wherever they are run and that images can be combined, shared, and executed across different machines. This shift has made distribution far simpler, to the point where entire robotics frameworks can now be delivered as downloadable images, ready to run.
Take the Robot Operating System (ROS) as an example. Gone are the days when installing ROS meant endless updates, mysterious breakages after adding another package, or students in classrooms battling through multipage installation guides. Today, whether you are a student or an industry professional, you can download a pre-built image, spin it up in seconds, and start solving actual robotics problems instead of wrestling with your toolchain.
But this progress hasn’t eliminated every problem. One recurring question is: how much should be bundled into a single image? We can’t include every possible library for every user’s needs. Multiple images and multi-stage builds offer a partial solution, combining different components into a custom image. Yet, dependency conflicts still creep in.
Picture one image relying on version A of a library and another on version B, which breaks compatibility. Merging them becomes a delicate balancing act, and sometimes the result works only because of the order in which the files were copied into the final image. In native installations, such conflicts often trigger early warnings. However, in container images, they can stay hidden until runtime, making them harder to detect and debug. So, are we back to square one? Not exactly, but it’s a reminder that the process requires careful handling.
This becomes even more challenging in modern robotics, where “heavy” machine learning (ML) libraries and GPU acceleration are increasingly essential. These tools bring their own complexities, from hardware compatibility to driver versions, and require careful packaging. Thankfully, GPU vendors like NVIDIA have made great strides in supporting containerized workflows, making it far easier to set up environments for platforms like Isaac Sim compared to just a decade ago (when Docker itself was still the new kid on the block; that is, 2015 for future readers).
At its core, image composition is a version control problem. Each image needs clear versioning and metadata, and there must be a way to orchestrate multi-image dependencies so that conflicts don’t go unnoticed. Unfortunately, in much of the industry, this level of transparency isn’t prioritized, especially in closed-source products that only ship the final, locked-down image. While that ensures stability, it narrows the possibilities for adapting, extending, building on existing work, and ultimately, innovating.
At AICA, we take a different approach and believe in openness and flexibility for the end user. Our framework, although partially closed-source, is designed so that modules can be added or removed easily, with open extension templates for developers to create what we haven’t thought of yet, or to craft something expertly curated to their application. Our latest work continues that vision: providing reusable toolchain libraries for GPU support and ML images. These will be available as parametrizable configurations that allow users to curate exactly what they need, or as pre-configured images ready to pull from our registries, both fully compatible with AICA Studio.
By removing the hassle of dependency hunting and long Dockerfile builds, we aim to let robotics and ML engineers focus on innovation, not installation. Version control will always be a challenge in complex systems, but with the right tools and a collaborative mindset, it doesn’t have to be a bottleneck. And if we can make even a small dent in that problem, we think it’s a step worth taking.
Written by Vaios Papaspyros
Robotics Application Engineer
