This book is about the topic of Mobile Cloud Robotics. Cloud Robotics emerged in 2010. This leverages the fusion of multiple technologies, such as the Internet of Things, mobile robotic platforms, Multicore Graphics Processing Units, and the Cloud platform. The Cloud concept involves virtualizing the compute element, as we'll explain in detail later. Mostly, we will focus on mobile robots, as opposed to robotic assembly, and warehousing. At the heart of the problem is a computation-communication-power usage trade-off. We will look at the integration of these topics, with a roadmap and a defined architecture. The Cloud-supplied services augment the more limited computation resources embedded in the mobile robot. It provides services on demand. These services can be related to data storage, downloading code, or computation. This allows a relatively simple and constrained architecture to have vastly greater resources. We will extend this concept. We can build a swarm of robotic platforms, not necessarily homogeneous, that can self-organize into a cluster computer, using, for example, the Open Source Beowulf software from NASA. There is no reason the Cloud server has to be static, it can be a member of the swarm. The swarm members will share an architecture, differing only in their sensor payload (This is one usage model). The Swarm mothership can host the cloud, wherever the swarm happens to be. I use the term "mothership" here to indicate that the robot platforms are deployed from (and possibly retrieved by) the mothership. The mothership is a supernode, as members of the group or swarm are nodes. With the current generation of GPU-based supercomputer architectures, the mothership can certainly be a Cloud host. It shares the problems of power usage, and communication with members of the swarm. Depending on the operational environment, these issues can be addressed. The more real-time operations have to be handled locally, onboard the various members, due to communications delays. Up front, at the architecture level, the load balancing must be considered in a trade-off with communications and power usage. The mobile platform must always be able to meet the goals, even if a bit late. In some real-time scenarios, late means wrong.