Integrations and Collaboration Are the Catalysts of Today’s Robotics Revolution
It may seem like a long time ago, but during the early stages of the Robotic Operating System (ROS) buzz, many companies were hesitant to adopt it into their development.
Generic protocols, software packages, and visualization tools were something that each company would have developed internally, again and again. This created a years-long process where developers would have to reverse engineer technologies, or simply reinvent them— even if they already existed within competitor products.
Before the early days of what we now know as the automation revolution, Linux was considered good for the academy and hackers. Even Windows was competing to get a foot into the robotic market with Windows Robotic Studio.
Back then, making a driver work often meant compiling your own Linux Kernel, reading through some obscure forums by the light of a candle, or as my lab professor would say “Here be dragons.” Developers back then shared a common living nightmare, where by the time real image data began streaming through C++ code, high powered graphic display drivers stopped working due to incompatible dependencies and Ubuntu would crash on boot.
Top AI ML News: Why Intent Plus Sentiment Powered Contextual Targeting Is Winning the…
By now, more than a decade has passed and automation is the name of the game for developers who want to reach market needs at lightning speeds with greater reliability. ROS has come into the picture, allowing data visualization, simultaneous location and mapping (SLAM) algorithms, and navigating robots, something that anyone with some free time and a step-by-step tutorial can develop, test, and customize. Robotic Sensor / Platform vendors themselves are now singing ROS’ praises and releasing Git repositories with ready-made ROS nodes— the ones that they themselves used to test and develop the hardware.
A shift in robotics revolution with new-age software development
This gives the impression that the basic growing pains of robotic software development are now long gone. Today, with off-the-shelf components and software component libraries, building your own robot has never been easier. All this is before we even talk about simulation tools and the cloud.
Yet, for some reason, most of the robots created today are still closed boxes. They are not ROS-based, there’s no cloud-connectivity for OTA updates, and the OS cannot be updated. iRobot, for example, discussed their intention in 2019 to move away from a proprietary operating system to a ROS based one and is currently using ROS only for testing through their CREATE 3 platform. This is just one example. If you take a look at the robots around you, most of the issues they face will never be solvable and their behavior will not change greatly. Today’s ROS-based robots will be replaced by a whole new OS with a full-blown new ROS release in a new robot, marking most of the robots around us today obsolete.
Remember when this was common for phones? Before iOS, Android, or any other 3rd generation technology?
Breaking the cycle in Robotics revolution
Something to consider is that robotics developers and enthusiasts are a critical bunch. They analyze, review, and criticize openly when companies use closed software platforms or release robots with already outdated technology.
Perhaps this is due to long development processes, where cloud-connectivity, FOTA, and other modern features were not around when they set out to build something new. Whole setups are hard to break down and reassemble. Program flows are not transferable.
As early as 2012, companies were developing and releasing some basic behavior tree decision-making code to ROS. It took until ROS2 to see a behavior engine first used as a ROS standard component. This hits especially hard for developers who have tried to reconfigure move-base between robots, set up TF’s, and reconfigure thresholds for negative and positive obstacles when the sensor type or position changed. Imagine Updating its simulative model or Making sure its dependencies are met between the various ROS versions provided by the vendor.
This industry-wide pain has brought robotics engineers together to begin understanding common development hurdles and compiling low-code or no-code software packets that allow companies to get a head-start on their development. Relying on various operating systems and development tools, robotics startups are finding themselves on the same footing with the big industry players, allowing them to rapidly build their robotics foundation and focus on their proprietary technology. These software components can be organized, connected, and reassembled by code, console interface, or from the web using GUI, making anyone (even without ROS specific know-how) able to understand and see the various building blocks that compose the robot execution. The goal of deconstructing the mission to containerized blocks is also to untie the problematic coupling of OS and ROS versions by providing isolation and enabling using various ROS distributions on the same robot, including ROS1 and ROS2 components together.
AI ML News: Ant Group Makes Trusted AI Solutions More Accessible to Support Industrial Collaboration in Digital Economy
Components can now be easily replaced making testing of alternative algorithms easier and robot access can be shared between operators and developers to allow remote access to the robot at any time. This does not require installing anything on the robot itself as all the installations are being managed by an agent running as a service on the robot. Multiple users can see live data or access the robot configuration and change it.
If we want to make the robotics world a better place for generations to come, while also reaping the benefits of streamlined processes, it is vital that we look to the past on what robotics development was. Similar to the software development and SaaS worlds, collaboration in the robotics space is poised to usher in a new era of brilliant technology and previously unimaginable possibilities.
Comments are closed.