What Robotics Can Learn from SaaS
The Rise of Software
The past decade we have seen nothing short of a revolution in software. As Marc Andreesen once said, “Software is truly eating the world”. It’s become a natural part of every single industry and company. Software is unique in its properties in that it requires no initial materials to get started (well maybe outside of a computer). Its value creation is limited to the skill of the programmer and the creator.
The Barrier to Entry has Been Lowered…Almost Everywhere
With this barrier to entry lowered, we’ve seen more and more software engineers and computer scientists build out amazing frameworks and systems that makes it ever the more easier to create software. I mean just look at the number of web frameworks that are out there for JavaScript. I myself have utilized three: Angular, Vue.js, and React, along with the various flavors of React including Next.js. All of these frameworks and systems have led to the proliferation of faster websites, optimized builds, and a more beautiful and user-friendly ecosystem across software applications.
We see a similar wave of “lowering the entry” with AI, TensorFlow took the first stab at it along with Keras (shoutout Francois Chollet on an amazing library) along with PyTorch that created an extremely pythonic and intuitive way to program AI. And now you’re even seeing repositories like HuggingFace that are plug and play. Spacy and NLTK with NLP models, and many many more.
But what about robotics? What about the software ecosystem around robotics? For most people, the major move forward has been the Robot Operating System (ROS). It’s enabled more people to utilize other people’s code by creating drivers and systems that have already been prebuilt. But we’re still not seeing the crazy adoption and the ease of use that we’re seeing with building a website or building a complex AI algorithm. Why is that? Yes, I agree that the robotics space is harder (control algorithms, navigation systems, there’s a lot to unpack). But I believe that there’s a lot that the robotic ecosystem can learn from the decade of proliferation that the general software world has had, of which I believe the robotics world really lacks.
For Starters…Write Better Documentation
Documentation, as we’re seeing more and more, makes or breaks an open source ecosystem. Without proper documentation of how specific systems work, how to install it, and how to run the application, developers are left to their own devices of tinkering and figuring things out. In fact, that’s exactly what we’re seeing. Roboticists are constantly in the mindset of “I just want this thing to work” instead of thinking “how can I build something amazing on top?”. Even with the ROS ecosystem, we’re seeing difficulties of integrating multiple ROS 2 packages together due to dependency mismatches, a variety of sudo commands, documentation searching on this site, on that site.
For example, let’s take ORBSLAM2 as a key example. When attempting to build ORBSLAM2 with a ROS2 wrapper, I ran into a slew of issues that ultimately led me to documentation that was not even in my native language (something related to Pangolin display issues). With these small minute issues that so heavily depend on the system that you’re running, it’s extremely frustrating to have to say “it works on my computer but not yours”. But that’s exactly the case for robotics. Without the consistency in knowing that a software will work on your computer and no documentation to show how to install it on your computer, you’re really left to your own devices — spending days debugging.
With this in mind, I implore new developers of open source and systems to spend time writing really good documentation. Write strong documentation on how to install your packages on a variety of different system types. Discuss the value add that your code brings. Talk about common gotchas and mistakes people face during set up. Provide proper examples of how to use your code for specific items and actions. This documentation will go a long way for getting new developers into the ecosystem and existing developers building out even cooler systems.
How to get started with Documentation
There are many ways that you can get started with writing documentation. For starters, ensure that installation steps are provided on your README.md. Installation should tell the user what versions of ROS 2 you support, what versions you have tested on, and common issues that have arisen from the issues. In addition, you should provide key examples on how to use your package and code including links to examples, or visualizations of the result. A YouTube video can help a lot here as well.
If you have an even bigger package, utilizing a documentation system such as GitBook, Docusaurus, or even GitHub Wiki can go loads far as users can walk through understanding how things work at their own pace. Nav2 and MoveIt do a decent job here, but we would like to see this for the larger research ecosystem.
Docker Needs to Become Mainstream
ROS2 has done an amazing job for creating a messaging system on top of DDS. But because it has to support multiple different languages and systems, it has relied on its own build system via colcon that has led to many frustrations. Though there is no easy mitigation for this, the best way is to start adopting Docker as the de facto way of sharing code.
Though not everything can be Dockerized, the code that can run as standalone ROS topics should be Dockerized. This includes things such as ORBSLAM2, a wrapper for Resnet50, etc. Whether it’s simply providing a base image that has all the dependencies installed or a docker image that users can pull from docker hub and get immediately running. This will save roboticists loads of time when it comes to debugging and integrating a whole system.
Docker has inherent advantages as it removes issues of “it doesn’t work on my computer” by virtualizing any hardware configuration (of course you have to support these configurations), and with modern CI/CD, it’s easier than ever to build and automate this entire process for the users of your package. The faster it is to get set up with your system, the more people will use the hard work that you have created.
How to get started with Docker
Docker relies simply on a predefined Dockerfile . ROS2 has provided a great set of base images that you can use to create the additional installation steps that the user would have to go through with your package. We’ve also provided a wide variety of docker images including GPU-accelerated base images for AI inference that are built on top of the existing ROS base images, so feel free to take a look at our Docker hub to get started.
You can also take a look at this article that goes through how to set up CI/CD with Google Cloud Build and common gotchas when it comes to setting up Docker with ROS.
Finally, here’s a great article on how we set this all up with the YOLOv5 algorithm (creating a ROS2 wrapper and even publishing it to Docker hub as a container anyone can pull and immediately use).
Build Production-Ready Pipelines
Finally, it’s super important that roboticists and developers start thinking about how to make their code production ready. Only with the larger adoption of corporations utilizing open source will we see the proliferation of a larger open source community. At this current stage, the majority of enterprise customers and businesses still rely heavily on internal code with only a select few packages such as MoveIt and Nav2 being utilized heavily. The wider rest of open source are left to their own devices. Why is that the case? Because we need to see stronger production ready systems. Developers need to be taught on how to build proper CI/CD, and testing into their systems and code. More work needs to be done when it comes to building a robust testing framework, simulations, and deployment of the code.
We need to take ideas such as feature flagging, A/B testing, and bring them to our production-ready fleets. We need to think about items such as cybersecurity from day one, monitoring, telemetry, and analytics.
Only when we integrate the entire ecosystem into one will we see a wider adoption. This is also a call on corporations and enterprise to fully support this open source, third-party driven effort that robotics startups and companies are attempting to start. The new wave of Robot Dev Tools are coming to help empower the next generation of roboticists, but we need your support.
By building production-ready code and a production-focused code (with the thought that maybe our code could one day run on thousands of robots), we want to pay close attention to all the things that we mentioned above (docker containers, better documentation, etc.)
Conclusion — Don’t Just Get Things to Work, Go the Extra Mile
Overall, the robotics space is an exciting one and only recently are we beginning to see the true Industrial 4.0 slowly come to life. With the introduction of AMRs, large language models, vision algorithms for grasping, and more amazing research being built, it’s an amazing time to be alive. Yet the news that we hear and the systems that we see out in the wild are still few and far between. Only a select few have all the resources to build at light speed, while many others are still struggling to just get systems to work. I believe that if we integrate and aggregate all of the systems and tools out there, provide better documentation, and ready-made docker containers, we can achieve our dream and vision of an Industrial 4.0 much much faster.
