For third time in a row we attended ROSCon, this year held in beautiful Vancouver.
Our goals besides seeing the newest trends in the ROS and Robotics universe first hand, and finding some new robotic hardware directly from manufacturers, was to support our partners from Rapyuta Robotics (RR) in presenting and performing a demo of the first preview of their upcoming Cloud Robotics Platform.
In the context of the ECRP Project, we need to orchestrate intercommunicating components and services running on robots and in the cloud. The communication of this components relies on several protocols including L7 as well as L4 protocols such as TCP and UDP.
One of the solutions we are testing as the base technology for the ECRP cloud platform is OpenShift. As a proof of concept, we wanted to test TCP connectivity to components deployed in our OpenShift 1.3 cluster. We chose to run two RabbitMQ instances and make them accessible from the Internet to act as TCP endpoints for incoming robot connections.
The concept of “route” in OpenShift has the purpose to enable connections from outside the cluster to services and containers. Unfortunately, the default router component in OpenShift only supports HTTP/HTTPS traffic, hence cannot natively support our intended use case. However, Openshift routing can be extended with so called “custom routers”.
This blog post will lead you through the process of creating and deploying a custom router supporting TCP traffic and SNI routing in OpenShift.
Two of the most influential robotics events of 2016, ROSCon and IROS, were conveniently co-located in South Korea during the second week of October.
We had previously attended ROSCon 2015 in Hamburg, but it was our first time at the International Conference on Intelligent Robots and Systems (IROS), this year in Daejeon.
Title: ECRP – Enterprise Cloud Robotics Platform
Industry Partner: Rapyuta Robotics
Research Partner: SPLab/ICCLab, ZHAW
Funded By: Commission for Technology and Innovation
The ECRP project combines cutting edge robotics technology from Rapyuta Robotics (RR), an ETH Zurich spinoff, and novel cloud development from the Service Prototyping (SPLab) and InIT Cloud Computing Lab (ICCLab) at ZHAW.
With ICCLab, RR will transform its existing open source robotics platform from a prototype to a full-fledged cloud-native enterprise ecosystem for third-party applications combining physical devices with cloud-hosted functionality.
RR and ZHAW have agreed to release this work as open source software (OSS), under the label Rapyuta Core.
We received our RPLIDAR this morning and, just as kids on Christmas day, we were very eager to play with it right away.
But I’ll hold my horses, as I can hear you ask: “and what exactly is a RPLIDAR?”
A RPLIDAR is a low cost LIDAR sensor (i.e., a light-based radar, a “laser scanner”) from Robo Peak suitable for indoor robotic applications. Basically a cheaper version of that weird rotating thing you see on top of the Google self-driving cars. You can use it for collision avoidance and for the robot to quickly figure out what’s around it.
Carlo Vallati was a visiting researcher during Aug/Sept 2015. (See here for a short note on his experience visiting). In this post he outlines how cloud computing needs to evolve to meet future requirements.
Despite the increasing usage of cloud computing as enabler for a wide number of applications, the next wave of technological evolution – the Internet of Things and Robotics – will require the extension of the classical centralized cloud computing architecture towards a more distributed architecture that includes computing and storage nodes installed close to users and physical systems. Edge computing will also require greater flexibility, necessary to handle the huge increase in the number of devices – a distributed architecture will guarantee scalability – and to deal with privacy concerns that are arising among end users – edge computing will limit exposure of private data. Continue reading