1. RaaS: Robotics as a Service
A Service Model for Cloud Robotics
Hi, I’m Arjun Singh, from UC Berkeley, and today I’ll be talking about Robotics as a Service, or RaaS, which is a Service Model for Cloud Robotics. This is joint work with Ben Kehoe, Ken Goldberg, and Pieter Abbeel.
Arjun Singh, Ben Kehoe, Ken Goldberg, Pieter Abbeel
University of California, Berkeley

2. Example Use Case Objects coming down conveyer belt
Identify each object, pick it up, and place into correct bin
Low-level control
Object recognition
Grasp planning
Motion planning
To put things in context, I’ll start with an example use case. Imagine we have a robot that needs to identify objects coming down a conveyor belt, pick them up, and place them into the correct bin.
What’s necessary for this task? Well, obviously you’d need to be able to control the robot. You’d need object recognition for identifying objects, grasp planning for figuring out how to pick up each object, and then motion planning to actually pick and place the object.
Drawing: Ketrina Yim

3. How to Solve It with ROS Acquire computing hardware
Install ROS and relevant packages
Execute and maintain software and computing hardware
So how would we solve this today, using ROS?
Well, first, we’d need to get the computing hardware, if the robot didn’t have enough onboard computation.
We’d then install ROS and the relevant packages for object recognition, motion planning, and so on.
Once we’re all set up, we can start executing the task.
However, we would have to continually maintain both the software and hardware.
Drawing: Ketrina Yim

4. Pros and Cons of ROS
Huge positive impact on robotics (especially sharing)
Core great for messaging, low- level control – components that make a robot operating system
Asking it to do too much
All code for everything robotics related
Packages required for barebones ROS installation
Packages required for full ROS installation
What are the pros and cons of using ROS?
First, ROS has had a huge positive impact on accelerating robotics research, especially through code sharing and community building.
The core is great for doing things you would want a robot operating system to do – pass messages, low level control, and so on.
However, I think we’re asking it to do too much, by including all code for everything robotics related as ROS packages

5. Pros and Cons of ROS Intimidating for non-roboticists
Nontrivial to set up secure distributed networking with ROS -- need to understand VPNs, have control over network environment, etc.
Dependencies can turn into a nightmare (especially with multiple ROS versions)
Because of the difficult setup and learning curve, ROS is pretty intimidating for non-roboticists. Computer vision and NLP people, for example, don’t really work with ROS, even though we need their code.
If we want to move computation to the cloud, we need to do so securely. It’s nontrivial to set up a secure network with ROS – you’d need to understand VPNs and have full control over your network environment.
Dependencies can turn into a nightmare, particularly if there are multiple ROS versions involved. If you need a package that’s built for ROS Diamondback, but the rest of your robot works with ROS Groovy, you may be stuck either downgrading or converting the package.

6. Computing Environment has Changed
ROS design started in 2006 – a lot has changed!
Cloud computing: Easy access to vast numbers of machines
Software engineering: Service- oriented architectures and Software as a Service
E.g. Google Docs vs. Microsoft Office
The computing environment has changed significantly since ROS was designed
First, as you all know, cloud computing has enabled easy access to a huge number of machines, for example through Amazon’s EC2 or Google’s Compute Engine. Additionally, software engineering has developed, and service-oriented architectures and Software as a Service have matured. For example, think of Google Docs – it didn’t exist just a few years ago, and now it’s quite widely used.

7. Example Services – Motion Planning
So let’s take a look at some examples of service-oriented systems In the context of robotics.
Each service is specialized to do a single thing – in this case, motion planning.
Here, the input is a start state and a goal state for the robot’s arm, and the output is a trajectory that moves the arm from the start to the goal.

8. Example Services – Object Recognition
Here’s another example.
The robot takes a picture of a scene and sends it off to the object recognition service.
The service detects the objects present and returns a list of detected objects, shown here as an image.

9. Our Idea: Robotics as a Service (RaaS)
Publish algorithms as services
Consume services on your robot
Collaborative data collection
So here’s our idea – we want to enable Robotics as a Service. Algorithm developers can publish serves in the cloud. Algorithm users can discover and use services from the cloud. Lastly, we envision collaborative data collection, in which people and robots could share data for use by others.
You would have algorithm developers publishing algorithms to the cloud. One important detail is that there’s also a meta-service that we’re running in the cloud that provides a directory of services and datasets – this is what services get published to.

10. Related Work Cloud Robotics Open-Source Tools Commercial Products
Rapyuta ( Robotics Platform as a Service Rocon ( Higher-level orchestration Goldberg et al Networked robotics Arumugam et al Cloud computing for robots Ciocarlie et al Big data for robotics Kuffner 2010 Cloud-enabled robots Remy and Blake 2011 Service-oriented robotics Blake et al Service-oriented robotics Waibel et al Shared knowledge
MoveIt! (Sucan and Chitta) Motion planning
GraspIt! (Ciocarlie and Miller) Grasp planning
OpenCV (Bradski) Computer vision
OpenRAVE (Diankov) Motion planning
Ladon ( Web service framework
Commercial Products
Mashape Index of service APIs
PiCloud Move computation into cloud
We’re not the first ones to have this vision. There’s been quite a bit of work done on Cloud Robotics, especially in the past few years. Many projects overlap in their goals significantly, particularly Rapyuta, and some work on service-oriented robotics by Remy and Blake, and by Waibel – I’ve bolded them here.
There are also many open-source tools that share the same spirit, even if they aren’t yet in the cloud. For example, MoveIt focuses on providing a variety of Motion Planning Algorithms. Similarly, GraspIt!, by Matei, for grasp planning.

11. Vision Index of available services and datasets (RaaS)
Provide algorithms as web services
Run anywhere – in the cloud or in your lab
Collaborative data collection
What we have now is extremely early, pre-alpha
It’d be really good to illustrate the overall vision with pictures rather than words; looks like you’d have 4 pictures here:
Someone coding and code shipped off to a cloud
Someone coding and code being used from the cloud the cloud could contain “RaaS”
Show data (paper / disc drives) sent off to the cloud / retrieved from
Show some kind of directory that is connected to the RaaS cloud
Maybe the RaaS cloud could be sitting in the middle of the slide, and then we could see a connection from North West for 1, from North East for 2, …

12. Vision – RaaS Ecosystem
What we have now is extremely early, pre-alpha
It’d be really good to illustrate the overall vision with pictures rather than words; looks like you’d have 4 pictures here:
Someone coding and code shipped off to a cloud
Someone coding and code being used from the cloud the cloud could contain “RaaS”
Show data (paper / disc drives) sent off to the cloud / retrieved from
Show some kind of directory that is connected to the RaaS cloud
Maybe the RaaS cloud could be sitting in the middle of the slide, and then we could see a connection from North West for 1, from North East for 2, …

13. Outline Why services? Why not ROS? Doesn’t ROS do this? RaaS Workflow
What’s limiting about the current way of doing things?
Use cases / pain points
Why not ROS? Doesn’t ROS do this?
RaaS Workflow
And when I say services, I don’t mean the cloud – although you can just imagine that for now, all services run in the cloud, they aren’t interchangeable terms
I’ll go over some different aspects that don’t necessarily seem related, but I’ll explain how a service-oriented model can help make things easier.
On the surface, it may seem like ROS already serves this role, but I’ll talk about some cases in which it’s being asked to do too much.
Lastly, I’ll go over some details of how to use the system, from the vantage point of the different people involved – for algorithm developers, for algorithm consumers, and for data collectors.

14. Why RaaS? Limited Resources Code Sharing Encapsulation Parallelism
Common Interfaces
So why RaaS?
There are several areas in which RaaS can help.

15. Why RaaS?
Limited Resources
Code Sharing
Encapsulation
Parallelism
Common Interfaces
Some robotic platforms have limited onboard computation (e.g. Baxter)
Can’t run sophisticated robotics algorithms
Need offboard computation – use the cloud or buy computers
Services give a straightforward way to move computation to the cloud
First, lets look at the case of limited computational resources.
Many robotic platforms, like Baxter, have limited onboard computation, due to space, power, and cost constraints.
These robots can’t run sophisticated algorithms onboard – you need offboard computation.
Services provide a straightforawrd way to move computation into the cloud.
Photo: David Yellen for IEEE Spectrum

16. Why RaaS?
Limited Resources
Code Sharing
Encapsulation
Parallelism
Common Interfaces
Spend months working on your algorithm, finally finish it, and you want to share it
Need to figure out what all the dependencies are
Need to document how to install everything
Need to document how to use your code
Don’t have time for any of these
Packaged service: only worry about API users interact with
Next, let’s look at sharing code.
So, you’ve spent months working on your method, you finally finish it, and you want to share it. What needs to happen?
You need to figure out what all your dependencies are, you need to document how to install everything, you need to document how to actually use your code, and you don’t have time for any of it
The reason you need to do all of this work is that the end user doesn’t know how to build or use your code– only you do. If you provide your algorithm as a service, the end user doesn’t need to worry about building anything. This saves them time, and it saves you time. All you need to worry about then is the API users will interact with

17. Why RaaS? Robotics requires integrating many different components
Limited Resources
Code Sharing
Encapsulation
Parallelism
Common Interfaces
Robotics requires integrating many different components
Vision, NLP, control, messaging, planning, grasping, etc. – each alone is complex
Huge number of dependencies – something is bound to conflict
Services force encapsulation of components
Use object detection and planning systems without worrying about conflicts
Robotics, perhaps more than any other discipline, requires the integration of many software components. You might need computer vision, natural language processing, planning, grasping, and more, all in one system. Each of these alone is fairly complex and can have many dependencies. When you take all of them together, something is bound to conflict.
Services force encapsulation of components. For example, if an object detection system and a planning system have conflicting dependencies, it can get extremely difficult to get everything running. Encapsulating these systems as services allows easy use of both systems.

18. Why RaaS? Service: natural interface for parallelizing computation
Limited Resources
Code Sharing
Encapsulation
Parallelism
Common Interfaces
Service: natural interface for parallelizing computation
Insulates user from managing parallelism
Automatically run multiple instances of a service on multiple machines
A service is a natural interface for parallelizing computaiton. We can insulate the user from having to manage this parallelism by automatically running multiple instances of a service on multiple machines. If you have more than one image in which you need to detect objects, RaaS can automatically send them to different machines, so that both images are processed in parallel.

19. Why RaaS? Easy benchmarking and comparison
Limited Resources
Code Sharing
Encapsulation
Parallelism
Common Interfaces
Easy benchmarking and comparison
Use common interfaces when defining services
E.g. object recognition systems
Input: Image
Output: List of object identities
Can’t expect researchers to implement interfaces at a library level
Swap out services
RaaS enables you to easily compare competing algorithms. We do so by encouraging the use of common interfaces. For example, for object recognition, the service interface has an Image as input, and a list of object identies as output. If two competing object recognition systems implement this interface, you can swap out one service for another without needing to change any of your code, and then see which works better for your problem.
It’s not feasible to expect researchers to implement common interfaces at a library level – it’s too difficult.

20. Why Services? – Data Abstract data away from the algorithms
Create interfaces for datasets, similar to the interfaces for services themselves
Plug-and-play different datasets
Fork/contribute to datasets

21. RaaS Workflow
Now, I’ll go over the workflow when using RaaS, first from an Algorithm Developer’s point of view, and then from an Algorithm User’s point of view.

22. RaaS Workflow – Algorithm Developers
Remember, the algorithm developers are publishing their services in the cloud – what’s involved?

23. RaaS Workflow – Algorithm Developers
Launch Machine on Amazon EC2
Write your usual code
Wrap with service code
Create Amazon Machine Image (AMI)
Publish your service
Install dependencies + code
Create Amazon Machine Image
First, you just write your usual code. You implement your algorithm. Here, I’ve shown an object detection system – takes in an image, and returns a list of detected objects.
Next, you need to wrap your algorithm with service code. You have to define the interface – inputs and outputs. Again, the input is an image, and we specify its type, and the output is a list of strings, since each object label is a string.
The inputs are provided to the service function automatically, and then you run your code and return your outputs as normal.
The next step is to package up your code by creating a disk image. Concretely, we’ll make a disk image for Amazon’s EC2. If you’re not familiar with EC2, it’s a product by Amazon that lets you rent computers on an hourly basis to run your own software. You can create Amazon Machine Images which let you create an exact replica of an EC2 machine at any time. We’ll need to make one of these.
You first launch a machine on EC2. You then log in, install your service and any dependencies. Then you create an Amazon Machine Image. Amazon will give you an ID for your AMI, which you’ll need for the last step.
Lastly, you publish your service to our directory so that others can find it and use it. You’ll need to include the Amazon Machine Image ID the service wrapper you wrote earlier.

24. RaaS Workflow – Algorithm Developers
Make creating a web service as simple as possible
Ignore HTTP, serialization, encoding, webservers, etc.
Rich set of types available for service methods
Strings, floats, integers, binary blobs, raw files, timestamps, durations, poses, transformations, vectors, matrices, images, point clouds
Create your own
Can serve ROS nodes as web services
For algorithm developers, we’ve tried to make creating a web service as simple as possible – I think this is one of the key things that sets us apart from some other efforts, as ease of use has guided our design at every level.
You can ignore HTTP, serialization, encodings, webservers, etc. All you need is your service definition, and we take care of the rest.
We provide a rich set of types, spanning most things required for robotics. However, you can always create your own.
Lastly, if you already have created a ROS node, you can serve ROS nodes as web services.

25. RaaS Workflow – Algorithm Users
Okay, let’s look at the user’s perspective -- the user chooses services and consumes them with their robot.

26. RaaS Workflow – Algorithm Users
Choose services
Launch machines in the cloud
Connect to machine and use services
Detect objects in images, plan motions, etc.
Service Definition:
Client Code:
First, you choose which services you want from the directory. You’ll need to get the AMI ID, and then launch a machine on EC2 by copying and pasting the AMI ID.
Next, you’ll want to connect to and consume the service. Here’s the service we defined a few minutes ago. Here’s the corresponding client code for using the service. First, you connect to the service, and then you can call the function in the cloud. Now you can detect objects in images, plan motions, and so on.

27. RaaS Workflow – Algorithm Users
Compare different algorithms implementing the same interface by changing a single URL
Again, ignore serialization, encoding/decoding, HTTP, etc. – use like an ordinary function call
Use web-service-based ROS Nodes as if they were local ROS Nodes
Here are some nice features from the user’s perspective. Again, by using common interfaces, the user can compare different algorithms by simply changing a single URL.
And again, the user can ignore many of the details – they don’t need to worry about serialization, encoding, or any of that – they can use the service like an ordinary function call.
Lastly, you can use web-service-based ROS nodes as if they were just local ROS nodes – we’re aiming for seamless interoperability with ROS.

28. How to Solve It with RaaS
No need to worry about computing hardware
Install barebones ROS – (i.e. only messaging, low-level control, etc.)
Use object recognition, motion planning, grasp planning services from RaaS
RaaS complements ROS
Let’s look at our motivating use case again. How does it look with RaaS? First, we don’t need to worry about the computing hardware, as long as we have something that can send network requests. We install barebones ROS for low level controls. From RaaS, we use the object recognition, motion planning, and grasp planning services. If any of them improve, our system automatically improves without us having to maintain anything – bug fixes will happen automatically.
Note that as this example shows, RaaS complements ROS – it does not replace it.
Drawing: Ketrina Yim

29. Collaborative Data Collection – Example
Ten camera rig with controllable turntable
High quality 3d models from about 600 images in 5 minutes of human time
Ship us an object, we upload model to cloud, you can recognize it in images
I also want to give an example of collaborative data collection. My other main project right now is collecting a lot of data for object recognition with this 10 camera rig with a controllable turntable. We’ll be able to get high quality 3d models and about 600 images in about 5 minutes of human time.
With the RaaS infrastructure, this opens up some interesting possibilites. Rather than having everyone build a rig like this to collect data, we can specialize in collecting data. You could ship us an object, we’d build and upload a model, and then you could recognize it without having to touch a single line of code.

30. Roadmap Linux containers rather than Amazon Machine Images
(Almost) Complete (pre-alpha)
Future Work
Linux containers rather than Amazon Machine Images
Can then run services anywhere – in your lab or in the cloud
Infrastructure for other programming languages
Data collection APIs
Service framework implemented for Python
Service directory implemented for EC2
Need to polish up rough edges and automate tedious steps
Finally, I’ll go over the roadmap. We have a significant portion mostly complete, at a pre-alpha stage. We have the service framework we described implemented for Python. We have the service directory implemented for EC2 and Amazon Machine Images. We still need to polish up some rough edges and automate a few tedious steps, though.
For future work, one of the most interesting things is using Linux containers rather than Amazon Machine Images. You’d then be able to run services anywhere – in your lab, or in the cloud, without having to install any of the software for those services. We also plan on building infrastructure for other programming languages. Lastly, we need to work out the Data collection and sharing APIs.
If you’re interested, you should us!
Interested? us!

31. Docker
Upcoming: packaging framework to allow you to run anywhere – on EC2 or on your laptop
Based on Docker (which is based on Linux containers (LXC))
Dockerfile: describe the steps required to build your service’s environment, then run generated image anywhere
Host a repository of contributed images and Dockerfiles