---
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. // SPDX-License-Identifier: CC-BY-SA-4.0
title: Robot Computation and Communication
permalink: /modules/1/robot-computer.html
---
Several choices are available for the computation devices processing the data from the sensors and sending commands to the actuators. Laptops can be a first choice for a powerful platform easy to use. In practice, other considerations are important, including **cost**, **power usage**, and **size**. In self-contained robots, roboticists dedicate effort to configure embedded systems or small form factor computers, allowing for lower cost and power usage. Examples include those below. A microcontroller, like an Arduino Uno, can run one program at a time, over and over again, useful a single purpose, e.g., used for controlling motors. Others, like Raspberry Pi 4 and Intel NUC are full computers that can run as normal laptops. The difference is with CPU, memory, and other interfaces. Some of those embedded systems have also GPU capabilities, such as the NVIDIA Jetson Nano.
{% include image-import.html content='
' description="Arduino Uno" %}
{% include image-import.html content='
' description="Raspberry Pi 4" %}
{% include image-import.html content='
' description="NVIDIA Jetson Nano" %}
{% include image-import.html content='
' description='Intel NUC' %}
Typically more than one computational device is present on the robot. In this way, various parts of the robot can be processed in **parallel**. **Differentiation** of work is one reason for multiple computational devices. For example, it is typical to have a micro-controller for the motors, to safely operate the robot in the environment, and another computer for processing sensor data. **Redundancy** can be another reason to have more than one computer. Computational power requirements depend on the sensor data to be processed and the software run on-board. Deep learning techniques require GPU capabilities. Clearly, the more computational power, the more heat and power consumption in the system.
Communication systems might be necessary if there is a requirement that the robot communicates with a human operator for tele-operation or high-level supervision, or other robots. Different strategies are available and are drawn from the way devices are interconnected. The most straightforward way is to **tether** a robot for reliable tele-operation. However, that comes with the challenges of cable management. If the robot is not aware of that, it can easily become tangled, as shown in the example picture below of an underwater robot.
Other solutions involve wireless solutions. A common solution is to use devices based on radio waves. Operating frequencies include 27 MHz or 49 MHz (RC), 900 MHz (radio), 2.4 GHz (IEEE 802.11 -- common band for WiFi and Bluetooth). An example of WiFi interface is on the figure below on the right.).
The choice depends on the amount of data to share and the distance to cover: the lower the frequency, the longer the line-of-sight distance between two communicating devices, but the lower the bandwidth. Some other media have been used. For example, light, e.g., infrared or green light. Acoustic modems are the typical communication for underwater environments.
{% include image-import.html content='
' description='Tether (in yellow) for an underwater robot.' %}
{% include image-import.html content='
' description='2.4 GHz radio communication module.' %}
Now that we have seen all the hardware components of a robot, how do we design a robot? Let's see the main characteristics that need to be considered -- [Robot design]({{ site.baseurl }}{% link _modules/mod-1e-design.md %}).