Democratizing robot development
For years and years we have been promised that our lives would be much better with the help of robots tending to our wishes. So far the closest we have come is a robot vacuum cleaner and maybe a robot lawn mower.
Why is that?
The primary reason is that the development of robots or robot solutions has required large teams with a lot of investment capital behind them. By nature, hardware projects are longer and slower than software projects. This combined with the fact that some of the jobs that robots could potentially fill are not perfectly understood or defined in robot context decreases the motivation for large investors to invest in the “unknown” space of service robots.
The development of smartphones over the last decade has had the side effect that sensors have matured, minimized and commoditized like never before. Sensors like:
- cameras (both 2d and 3d)
- gyros and accelerometers
On top of this, the king of robots; self-driving cars, have caused previously unattainable sensors like LiDARs to quickly become available as viable choices.
The academic and hobbyist makers in the robotics community have over the past 10 years developed the open-source Robot Operating System (ROS). ROS makes it a lot easier for robot developers to build their visions of physical robots. It allows them to stand on the shoulders of a lot of other great developers to build equally great software to give “life” to their robots. Despite these efforts, it still takes A LOT of knowledge and deep understanding about robots to configure or modify an existing ROS-based robot.
I have spent the most of the current millennium developing hundreds of apps and app-developer SDKs for first feature phones then smartphones. Over that period I have seen how it has become more and more easily available to new app developers to build cool apps for more and more cutting-edge smart devices: phones, tablets, watches, cars & TVs. Why not extend this list with robots?
Some attempts to make easily programmable service robots have been made, like Sanbot and Pepper, but both of these robots move so slowly that they, in practice, are little more than iPad holders that can move their arms or flippers. Besides that, most of these robots try to be more than they really are, with faces, arms and other features that they cannot use for anything really useful anyway.
Both Sanbot and Pepper have made it (theoretically) possible for the millions of creative app developers the world has been enriched with over the last decade to develop apps that run on the chests of robots with access to some of the robotic features of the underlying robot platform. Good.
The Kugle robot base (Polaris' ball bot base) I see as a really interesting opportunity to make a service robot platform where millions of skilled app developers can invent and iterate quickly, and release new versions of their robot based creations maybe weekly.
The app developers can take advantage of the yearly iteration of new and improved tablet hardware and software platforms. That again gives the app developers new opportunities for creativity.
The Kugle robot base will during development iterate as quickly as possible, and when matured and delivered in the market place, a 2020 version of the Kugle base will stay relevant and useful for a longer period of time than a mass market tablet, and allow for a shorter depreciation period.
In the Kugle project I will develop an interface that will allow app developers without specific robot knowledge to develop cool and innovative robot solutions far beyond our own imagination.
I aim to build the foundation for an ecosystem of app developers, relevant training material and tooling so that app developers can easily and quickly develop their visions of robot powered apps even before they gain access to the actual robots.