Rapyuta: The RoboEarth Cloud Engine

Motivation:

Robots begin to move from factories into household environment. However the key bottleneck for household robots is the computing power. This paper introduces an open source PaaS framework, Rapyuta that is designed superficially for robotic applications, which employ the cloud to solve such challenge.

Key points:

·                     One obvious solution to the computing power limit of household robotic is to employ cloud computing. However, existing platform either is not designed for robotic applications (Google App Engine), or does not take full advantage of cloud computing (DAvinCi). Rapyuta solves many reaming challenges of cloud robotics and provides advanced features such as elastic computing and peer collaborating. .

·                     The architecture of the system consists of four components, user that is the interface for users, LoadBalancer which is for allocating containers for each machine, Distributer that distribute the incoming connections for the robots and Network which provides the whole platform.

·                     The Network essentially has two major components, a Master Task Set, which is the main controller task that monitor and maintains command data structure connecting several Endpoints. Endpoints use RPC protocol to communicate with the master task set and provides interface for connections to robots and other external environment. Ends points can as well communicates with each other via Ports.

·                      The communication is divided into two categories, internal communication protocol that handles communications within the system that is down by RPC and UNIX socket, and external communication protocol which is between robot and Rapyuta via JSON messages.

Tradeoffs:

• The EndPoint design is suitable for household users with multiply sets of robots, and is highly scalable.
• The computing environment especially the re_comm_core is visionary.
• The offloading of all computation to the cloud may fail due to network or server failure.
• Despite of the API key for users, there is no more security guarantee for the platform.
• The performance testing only consider the network latency; other crucial factors such as computation latency is not discussed in the paper.

Thoughts:

• In the introduction mention the architecture would enable robots to benefit from the experience of other robots, however detailed implementation is not clarified in the paper.
• The paper specifically mention it uses JSON string to handle big binary messages, however the author does not talk about reason why he chooses JSON over native java serializable.
• Load balancing, and offloading choice are not discussed in the paper. 

Cloud Robotics: Architecture, Challenges and Applications

 

Motivation:

Robotic systems have brought significant social and economic developments to humans over the last few decades. In recent times, networked robotic systems, in which a group of networked robots cooperatively complete tasks have become very important. However, networked robotics faces severe physical constraints, such as storage space and computational efficiency. Cloud robotics can overcome these constraints and come up with more intelligent, efficient, and yet cheaper networks.  

Key points:

• Main constraints in networked robotics are resource constraints, information constraints and communications constraints. Cloud robotics use the idea of networked robotics but with the elastic resources available in a centralized cloud server that would overcome these constraints.

• The cloud robotics solution described in the paper leverages two complementary cloud: M2M (Machine-to-Machine) level or ad hoc cloud, and a M2C (Machine-to-Cloud) level or infrastructure cloud.

• On the M2M level, a team of robots communicate via wireless links to form a virtual ad-hoc cloud computing unit. Computing capability from individual robots can be pooled to form an ad-hoc cloud infrastructure, and robots can communicate with the ad-hoc cloud when they are not near an access point for the central cloud infrastructure.

• Also, in the M2M architecture, there is no central controller to monitor the flow of communication. Further, the network is highly dynamic, as robots may be mobile and may enter and leave a network anytime. In such a highly dynamic mobile robotic system, gossip protocols are used which do not require route discovery and maintenance.

• On the M2C level, the centralized cloud infrastructure offers a pool of shared computation and storage resources that can be allocated based on demand. It allows a group of robots to offload computation-intensive tasks for remote execution.

• The architecture discussed can be implemented via a number of elastic computing models such as the peer-based model in which each robot and VM in the cloud is considered a computing unit; the proxy-based model in which one robotic unit acts as a leader and communicates with a proxy VM in the cloud infrastructure; and the Clone-based model in which each robot corresponds to a system-level clone in the cloud.

Challenges:

• Computation challenges:  Key benefit of this system is the ability to offload intensive tasks for remote computation. Decision to offload a task requires complex strategies. Tradeoff lies in the energy used by the CPU in a robot compared to the energy used to transmit the data to the cloud for remote execution. 

• Communication challenges: As in the computation challenges, the communication time in sending the computation request has to be taken into account when deciding whether to offload a computation for remote execution. The gossip protocol that is used in the M2M level for communication between robots has significantly low overhead but has a high failure rate.

•  Optimization: The task offloading should basically choose between 3 choices: standalone execution by individual robots, execution by a group of robots, or cloud execution. Sometimes, the best solution may be partial execution by each of the 3 strategies. So an optimal execution strategy is required which will consider all such possibilities and choose the strategy with least execution cost.

• Security challenges:  The VM-environment needs to be trustworthy. It is possible for a malicious VM to sabotage tasks without the robots being aware of it. This is even more crucial in military settings. Therefore, the VM’s trustworthiness has to be confirmed, based on factors like trust measurement and reputation-based trustworthiness.

Benefits:

• Ability to offload intensive tasks. Robot battery life is extended, and generally becomes easier to maintain.

• Ability to access vast amount of data.

• Access to shared knowledge and new skills. Robots can communicate with other robots to learn new skills and knowledge from each other.

Thoughts:

• Communication in the ad-hoc cloud infrastructure may be difficult without an established route or leader. Since robots may enter and leave as they wish, it might be a little difficult to provide reliable communication.

• The paper has discussed only the energy consumed as a factor to decide task-offloading. Other parameters could be considered as well.  

• The paper suggests that it is enough for robots to have just basic processing power to enable only real-time actions. But if the robot suddenly loses contact with other robots and/or the central cloud, it might not be able to complete tasks if it is built too simple.

• If a particular task requires heavy usage of on-board sensors on the robots, the cloud infrastructure will not be of much help.  

Cloud-Based Robot Grasping with the Google Object Recognition Engine

Motivation:

Due to constraints on power and cost, robots operating in unstructured environments such as homes or offices have limits on onboard computation and limited data on the objects they encounter. Cloud Robotics proposes a thin-client model where robots are connected to modern cloud-computing infrastructure for access to distributed computing resources and datasets, and the ability to share training and labeling data for robot learning.

Main Points:

l  The system has two phases: offline and online.

l  Offline phase includes training of the object recognition server, the creation of object reference data, and the creation and analysis of the candidate grasp set. For each object, we capture a representative set of digital images from different viewpoints and use these to train the Google Goggles object recognition system. We also pre-compute a set of robust grasp configurations for the PR2 robot and each object using the Columbia University GraspIt! toolkit. We use sampling of spatial perturbations of each object in stable resting configurations to estimate robustness of each grasp to spatial uncertainty.

l  Online phase starts when an object is detected by the robot system which uses an onboard digital camera and 3D scanner to capture a 2D image of the object and a 3D point cloud and sends the 2D image to servers in the cloud and retrieves an object identifier, confidence measure, semantic information about the object including a 3D CAD model and reference point set, or a report that the object is not recognized.

l  If the object is recognized, the robot system locally estimates the position and orientation (pose) of the object using the 3D CAD model, the reference 3D point set, and the measured 3D point cloud. The pose is then used to index the highest probability grasp from the cloud. The robot then transforms the grasp to the local environment and attempts to execute the grasp. Once the grasp is executed, the outcome data: the image, object label, detected point cloud, estimated pose, selected grasp, and success or failure of the grasp is uploaded to the key-value store server for future reference. Failure can occur due to false or incorrect identification, or after an unsuccessful grasp.

Trade-offs:

l  The paper just said that the outcome data is uploaded for future reference. It need more details to show how the data improve the grasp selection.

l  The weight of an item is an important parameter for grasping the item. However, for some reasons, the weight of an item can change obviously even the appearance remains the same. For example, a full bottle of water compares to the bottle without water. Therefore, we cannot hardcode the weight of an item and need some methods to deal with this problem.

l  Different size of a kind of item may have the similar image. So, we need a method to determine the size of an item. For example, we can use the robot’s hand as a reference to obtain the size of an item.

Cloud Robotics: Architecture, Challenges and Applications

MOTIVATION

In this paper, the author introduces an integration framework between robotic technologies and network technologies. The cloud robotics infrastructure consists of Machine to Machine (M2M) and Machine to Cloud (M2C) communication tiers. These networked robots face many physical challenges. The paper describes a method to overcome the challenges using cloud robotic architecture.

KEY POINTS

• The major constraints of the network robot systems are resource constraints, difficulty in updating resource configurations, constraints in storing and sharing of information, communication troubles like requirement of complex computations and large memory.

• These constraints are overcome using with the help of centralized cloud infrastructure with elastic resources.

        ARCHITECTURE

• The architecture comprises of M2M and M2C tiers. On M2M level, robotic groups are formed which communicate using wireless links and form a collaborative unit. This unit is formed to utilize combined computing capabilities and to enable easy sharing/communication of information between robots that helps in collaborative decision making.

• On M2C level, the elastic centralized cloud provides resources for computational offloading. The main advantage is the extensive memory provided by the cloud for unification of information and the library of behavioral skills that guides learning among robots.

• M2M wireless communication network is formed dynamically, in an ad-hoc manner. Gossip algorithm is used for the purpose of message transmission because they do not require route discovery and maintenance.

• Cloud robotics is built on virtual ad-hoc cloud and a centralized cloud. Peer-based, Proxy-based and Clone-based computing models are the three main models created for specific applications. The Clone-based model has maximum robustness and Proxy-based model has maximum interoperability. Network conditions, application requirements and resource availability are the parameters required to choose the required model.

         CHALLENGES AND SOLUTIONS

• Computation challenges mainly focus on the decision to offload and how offloading takes place with efficient use of resources to minimize the robot’s energy consumption. Dynamic Voltage Scaling (DVS) model is considered for standalone execution, and polynomial energy consumption model is considered for cloud execution.

• Delay sensitivity and failure rates are the two main factors of communication challenges. The communication network delay is calculated using the conductance. The authors have shown that worst case delay is O(N log N) for N nodes in a network.

• Optimal execution strategy is aimed to optimize communication and execution costs. It can be a combination of three kinds of execution strategy namely standalone execution (by robot), execution by group of robots, cloud execution.

• Security challenges are overcome by first verifying the VM-environment (Trust Establishment). Then, VM is monitored and trust measurements are reported to a third party. The VMs infrastructure is verified by user with the help of its service provider’s identity(Reputation-based Trust).

ADVANTAGES

• Extension of battery life as computation intensive code are offloaded. As the cloud hardware is independent of robotic network, it can be upgraded separately, thus extending operational life of robotic network.

• As vast amount of data is available in the cloud, the robots can access them. They can also share information and learn new skills from the existing data.

• Robotic navigation, grasping, Simultaneous Localization And Mapping (SLAM) are few of the applications.

COMMENTS

• The integration of network and cloud robotics provides a very positive impact in offloading techniques.

• The use of gossip protocols may not provide reliable communication. Also, the conductance may become low due to high message latency if there is a fault in the network.

• Though security is ensured using trust measurement, if the robot is hacked, all the information can be accessed by anyone.

• Constant internet connection is very much essential for efficient performance.