We all know this tedious situation: Plenty of mobile robots around us, and we’d just like to use one of them for a specific task, but we don’t know which one we should take, as they’re all regularly busy on their own. Perhaps this is not a likely scenario right now, but it will be in five or six years from now and it will require novel approaches of how we manage their functionality in terms of services they offer. The Cloud Robotics research initiative is thus looking into robotic device management not so much from a hardware perspective but more from an angle of assessing which robotic resources can be used to deploy or run services and value-added applications on single robots, fleets of robots, or hybrid cloud/fleet constellations. With Roboreg, a first tangible robot-specific registry concept has been realised. The tool will be explained in this blog post.
Our vision is that cloud computing concepts, in particular the ones targeting developers such as Platform-as-a-Service (PaaS), will enter into new domains. The term Cloud Robotics is therefore referring to the use of cloud applications and services on top of robots as physical resources with a certain amount of virtualisation as some functions (e.g. aggregating sensor data) can be more easily shared than others (e.g. performing movement into conflicting directions).
We have prototyped Roboreg, a new kind of service registry for robots, to come closer to the vision. For quick prototyping, we heavily used the Salt stack as underlying master-slave transport and command framework. Roboreg hence runs as interactive command-line tool or HTTP service attached to the Salt API which in turn allows access to Salt minions, small run-time agents with one instance per robot. A key feature of Salt is that if remote functions on the agents are called, the appropriate code (as in Python modules) is deployed automatically from the master node so that new value-added robotics applications and services only need to be deployed through Roboreg and the Salt API to the Salt Master. The figure below summarises the setup.
Roboreg’s design foresees intermittent connectivity issues with robots and therefore maintains a strict separation between live mode and disconnected mode. In live mode, the presence of new robots can be discovered (roboreg scan) and their static and dynamic properties can be queried (roboreg prop). In disconnected mode, information about robots can be shown anytime (roboreg show) and sets of robots can be selected based on their characteristics involving functions and properties (roboreg pick). The history of how the fleet of robots changed over time can be audited (roboreg hist). Again in live mode, services of the robots can be invoked (roboreg call) and new applications and services can be deployed (roboreg push).
Through robot function chaining, some of the subcommands can be chained in a single tool invocation, such as: roboreg pick “camera=True” » call test. Future higher-level tools can make use of this feature to orchestrate invocations across a fleet of robots depending on their real-time status.
The software is published as open source software in the Roboreg repository. A screencast is available (and embedded below) to show how to put the software to good use. The next steps include adding robot-specific functionality and services based on ROS as well as running the platform stack on Kubernetes.
Defaulttext aus wp-youtube-lyte.php