AWS Robotics Blog

How to connect your robots to the AWS Cloud and drive data-driven innovation

When you think of robots, do you only think about hardware? Or do you think of delivering robotics solutions that can increasingly reach new levels of autonomy and optimize sophisticated processes? There’s more to robotics technology that meets the eye – physical devices are dependent on systems that train them and provide intelligence. Today, these machines can deliver automation that goes beyond what rigid programming models could enable, often learning from their own experiences and making dynamic decisions informed by data they gather from the environment in which they operate. At the end of the day, robots are as good as their ability to collect, store, and process data.

Robot data drives innovation. It helps improve both robotic devices and operational software. Without data, you can’t build fleet monitoring dashboards to troubleshoot issues, train repeatable machine learning (ML) models, or run simulations that allow for more cost-effective testing and validation of new features. Your data strategy will dictate whether you are able to build mature solutions from day one, innovate on behalf of your customers, and achieve operational excellence.

In this blog post, we will share what we’ve learned from working with hundreds of robot builders to help them establish a solid foundation for robot connectivity and drive data-driven optimization and innovation – even when robots operate in remote, rugged locations where connectivity may be disrupted, intermittent, or even unavailable. You’ll also learn how to connect your ROS2 robots to the cloud using AWS IoT Core, as well as the opportunities for new use cases, and applications for your data once your robots are connected to AWS.

Why cloud-to-edge connectivity matters for robotics

Deploying robots in production is complex and involves building robust intelligence such as navigation, behavior, and artificial intelligence (AI) and ML. Many use cases require exchanges and collaboration with other robots, Internet-of-Things (IoT) devices, humans, and a variety of systems. For example, a material movement use case in a factory may involve a fleet of industrial robots that must work in harmony with a work management system and multiple Programmable Logic Controllers (PLCs) to ensure that the inventory is moving from source to destination smoothly, with appropriate throughput.

The Internet of Robotic Things (IoT) and Industrial IoT (IIoT) have rapidly evolved to take advantage of data collected through intelligent sensors and actuators, robots, and other “autonomous things” operating in consumer, business, and industrial environments. The Internet of Robotic Things (IoRT) combines autonomous robotic systems with IoT/IIoT connectivity, edge/cloud computing, AI/ML, and more to fast-track the development of mature solutions using that data.

AWS believes that the data generated by robots is the key to improving the reliability and capabilities of robotic systems. Robot connectivity is the foundation that allows you to be able to gather this data, process it to provide tangible improvement to the functionality of the robot, and improve visibility into performance and operations. We also acknowledge that not every use case and environment in which your robots operate is conducive to continuous, high-bandwidth connectivity with the cloud. Our suite of services across the AWS IoT and Hybrid Cloud with AWS portfolio is designed to enable our customers to build this foundation for any connectivity scenario in the real world – from cloud-connected to fully disconnected robots, and every scenario in between.

Let’s now look at how you can easily and securely connect your ROS2 robots with AWS IoT Core and begin collecting telemetry data that you can use to improve your robotic applications.

How to connect your ROS2 robots to AWS and start capturing telemetry data

In this section, you will learn how to send telemetry from a ROS2-based robot to AWS IoT Core over MQTT. This code was tested on an Ubuntu 22.04 system on ROS2 Humble. You need to setup certificates on your device to connect to AWS IoT Core, which is setup via AWS Command Line Interface (AWS CLI) with appropriate privileges and assumes you have AWS Console access.

Install AWS CLI using the following commands:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" 
unzip awscliv2.zip 
sudo ./aws/install

Set up appropriate credentials to run AWS CLI commands. This blog assumes you are an admin user and recommend to limit permissions only required AWS IoT services commands. To learn more about methods to set up credentials and permissions, please see configuring AWS CLI and AWS Identity and Access Management.

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_DEFAULT_REGION=us-west-2

Install AWS IoT device SDK Python by running the following command:

python3 -m pip install awsiotsdk

Next, clone the following repository:

cd ~
git clone https://github.com/aws-samples/aws-iot-robot-connectivity-samples-ros2.git

Build the code with the following commands:

cd ~/aws-iot-robot-connectivity-samples-ros2/workspace
colcon build
source ~/aws-iot-robot-connectivity-samples-ros2/workspace/install/setup.bash

Your ROS2 code is built! However, before you run the code, you will need to setup certificates to communicate with AWS IoT Core. The certificates are used for Authentication and Authorization of the AWS IoT thing associated with your robot and provide encryption in transit for the data sent and received.

Each robot must have a credential to interact with AWS IoT. All traffic to and from AWS IoT is sent securely over Transport Layer Security (TLS). AWS cloud security mechanisms protect data as it moves between AWS IoT and other AWS services.

AWS IoT

You are responsible for managing device credentials X.509 certificates, as well as managing policies and permissions in AWS IoT. X.509 certificates provide AWS IoT with the ability to authenticate client and device connections. Client certificates must be registered with AWS IoT before a client can communicate with AWS IoT. X.509 certificates authenticate client and device connections to AWS IoT. X.509 certificates provide several benefits over other identification and authentication mechanisms. X.509 certificates enable asymmetric keys to be used with devices. For example, you could burn private keys into secure storage on a device so that sensitive cryptographic material never leaves the device. X.509 certificates provide stronger client authentication over other schemes, such as username and password or bearer tokens, because the private key never leaves the device.

In production at scale, AWS IoT Device Defender tools can be used to audit and get alerts for the security posture of IoT resources and add mitigation through build in actions such as updating a device certificate, quarantining a group of devices, or replacing default policies.

You will need to set several environment variables that are required for running the IoT API calls. These are the location of where to download the certs, and example names of what to call your devices.

export CERT_FOLDER_LOCATION=~/aws-iot-robot-connectivity-samples-ros2/iot_certs_and_config/
export THING_NAME=my_ros2_robot_thing
export IOT_CONFIG_TEMPLATE=~/aws-iot-robot-connectivity-samples-ros2/templates/iot_config_template.json
export IOT_POLICY_TEMPLATE=~/aws-iot-robot-connectivity-samples-ros2/templates/iot_policy_template.json
export IOT_POLICY_NAME=ros2_robot_iot_policy

The above command will download certificates in the $CERT_FOLDER_LOCATION on your robot.

Next, download a root certificate to connect our AWS IoT thing to AWS IoT Core, and and attach the certs created to the thing. AWS IoT provides client certificates that are signed by the Amazon Root certificate authority (CA). The root cert is used to verify the authenticity of the certificates created.

ROOT_CERT_FILE=$CERT_FOLDER_LOCATION"rootCA".crt
curl https://www.amazontrust.com/repository/AmazonRootCA1.pem > $ROOT_CERT_FILE
export CERT_ID=${CERT_ARN#*cert/}
aws iot attach-thing-principal --principal $CERT_ARN --thing-name $THING_NAME

You now have authentication to connect to AWS IoT Core but need a policy to define permissions and boundaries for your AWS IoT thing. A sample policy is provided in the repository purely for testing purposes, and you should modify it to suit your needs.

Create a copy of the iot_config_template.json file provided with the endpoint and certificate locations for your robot.

export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
export ENDPOINT_ADDRESS=$(aws iot describe-endpoint --endpoint-type iot:Data-ATS --query endpointAddress  --output text)

export PORT=8883
export IOT_CONFIG_FILE=~/aws-iot-robot-connectivity-samples-ros2/iot_certs_and_config/iot_config.json
cat $IOT_CONFIG_TEMPLATE >> $IOT_CONFIG_FILE
export PRIV_KEY_LOCATION=$CERT_FOLDER_LOCATION$THING_NAME.private.key
export CERT_FILE=$CERT_FOLDER_LOCATION$THING_NAME.cert.pem
sed -i -e "s/ENDPOINT/$ENDPOINT_ADDRESS/g" $IOT_CONFIG_FILE
sed -i -e "s/ROOTCA/$(echo $ROOT_CERT_FILE | sed 's_/_\\/_g')/g" $IOT_CONFIG_FILE
sed -i -e "s/PRIVATEKEY/$(echo $PRIV_KEY_LOCATION | sed 's_/_\\/_g')/g" $IOT_CONFIG_FILE
sed -i -e "s/CERTPATH/$(echo $CERT_FILE | sed 's_/_\\/_g')/g" $IOT_CONFIG_FILE
sed -i -e "s/CLIENT/$THING_NAME/g" $IOT_CONFIG_FILE
sed -i -e "s/PORT/$PORT/g" $IOT_CONFIG_FILE
cat $IOT_CONFIG_FILE

Next we create a policy file from a template file provided. This policy defines the permissions boundary for our AWS IoT Thing. Notice that this template only allows subscription and reception to ros2_mock_telemetry_topic. Modify the policy per your needs as you expand your use cases.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iot:Publish",
        "iot:Receive",
        "iot:RetainPublish"
      ],
      "Resource": [
        "arn:aws:iot:us-west-2:ACCOUNT_ID:topic/ros2_mock_telemetry_topic"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iot:Subscribe"
      ],
      "Resource": [
        "arn:aws:iot:us-west-2:ACCOUNT_ID:topicfilter/ros2_mock_telemetry_topic"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iot:Connect"
      ],
      "Resource": [
        "arn:aws:iot:us-west-2:ACCOUNT_ID:client/CLIENT"
      ]
    }
  ]
}

Create a policy from the template with the appropriate information using the following commands:

export IOT_POLICY_FILE=~/aws-iot-robot-connectivity-samples-ros2/iot_certs_and_config/iot_policy.json
cat $IOT_POLICY_TEMPLATE >> $IOT_POLICY_FILE
sed -i -e "s/ACCOUNT_ID/$ACCOUNT_ID/g" $IOT_POLICY_FILE
sed -i -e "s/CLIENT/$THING_NAME/g" $IOT_POLICY_FILE
cat $IOT_POLICY_FILE
aws iot create-policy --policy-name $IOT_POLICY_NAME --policy-document file://$IOT_POLICY_FILE
aws iot attach-policy --policy-name $IOT_POLICY_NAME --target $CERT_ARN

You should see a response like the following:

AWS IoT Policy
You have completed all the setup needed to send data to AWS IoT Core! You may now remove the AWS CLI specific credentials from the robot since you now have the IoT Certificates setup for the robot to communicate with AWS IoT Core.

Launch the rosnode with the following command:

source ~/aws-iot-robot-connectivity-samples-ros2/workspace/install/setup.bash
ros2 run telemetry_mqtt mock_telemetry_pub

This ROS2 node publishes mock telemetry data on topic mock_telemetry and can be verified by the following command, in a new terminal.

source ~/aws-iot-robot-connectivity-samples-ros2/workspace/install/setup.bash
ros2 topic echo mock_telemetry

Next run the node, that subscribes to the mock telemetry data and publishes to AWS IoT over MQTT topic ros2_mock_telemetry_topic.

export IOT_CONFIG_FILE=~/aws-iot-robot-connectivity-samples-ros2/iot_certs_and_config/iot_config.json
source ~/aws-iot-robot-connectivity-samples-ros2/workspace/install/setup.bash
ros2 run telemetry_mqtt mqtt_telemetry_pub --ros-args --param path_for_config:=$IOT_CONFIG_FILE

To view the data being published, login to your AWS console to the MQTT test client page on the browser by searching for IoT Core in the search bar and selecting MQTT test client as shown below.

AWS IoT Core

Connect to the MQTT test client on the console as shown below.

MQTT test client

Subscribe to the topic published by the AWS IoT thing in the client, to see mocked data being published by the ROS2 node.

ROS2 Mock Telemetry Topic

You can now convert any ROS2 topic data and send it over as an MQTT topic over AWS IoT Core, with a thing transformation layer from ROS2 topic to JSON-formatted messages sent over an MQTT topic.

Benefits of Internet-of-Robotics-Things (IoRT) connectivity

The more robotic “IoT things” you connect in collaborative autonomous fleets, the bigger the impact of your connectivity architecture, frameworks, and platforms for streaming, processing, and analyzing data. Connected robots produce big data that you can use to monitor your fleets at scale, manage your robot software remotely, drive continuous improvement, and build increasingly better solutions. Once your data is available on AWS IoT Core, you can leverage this IoRT connectivity to unlock multiple use cases to improve your robotic system.

Device management

AWS IoT device mangement tools can be used to register, organize, monitor, and remotely manage connected devices at scale. You are also able to connect to robots remotely to debug critical issues on robots at remote sites. This is done via Secure Shell Protocol (SSH) protocol to the robot from your browser using the secure tunneling functionality by leveraging the AWS device client functionality.

Operational excellence and continuous improvement

You can gather actionable operational insights by bringing data into AWS Analytics tools. For example, you can pipe data from IoT Core to Amazon Opensearch Service using an IoT Rule. This helps gather metrics and performances indexes from the data gathered by the robot which can be used to make improvement decisions, while providing visibility by viewing the data on a Amazon Managed Grafana dashboard using the Amazon Managed Grafana plugin for Opensearch.

Fleet monitoring and teleoperation

With a combination of AWS IoT services such as MQTT and Device shadow capabilities, and video streaming solutions from Amazon Kinesis Video Streams, you can build secure and scalable command-and-control and teleoperation solutions for your fleet of robots.

Build intelligent robots faster

AWS IoT Greengrass is an open-source IoT edge runtime and cloud service that provides pre-built software modules and AWS IoT integrations to implement and manage the solutions above. Greengrass includes pre-built, ready-to-deploy components to manage device security, credential rotation, remote access over secure shells, ML model deployment and execution, log capture and storage, buffered data streaming, and more. Finally, you can use Greengrass to securely provision, deploy, and manage the software life cycle on fleets of robots, including ROS based robots.

Next steps

With AWS, you get access to a globally scalable set of tools and resources to streamline the development and production of your robots. Get started today by connecting your robots to AWS with this sample application and start capturing telemetry data. While you’re on GitHub, make sure to favorite the repository for upcoming updates!

Sophie Pagalday

Sophie Pagalday

Sophie Pagalday is the Sr. Product Marketing Manager for AWS for Industrial & Manufacturing. She's spent most of her product marketing career in the industrial automation, logistics, and supply chain space, focused on technology ranging from enterprise work management systems to robotics. As an advocate for our customers, Sophie is relentless about learning about the challenges they face and how to best communicate how our services can help them.

Vamshi Konduri

Vamshi Konduri

Vamshi is a Senior Solutions Architect for Robotics at AWS, and helps customers solve challenging problems in robotics with AWS services, software, and by defining solution architectures. He is a Carnegie Mellon alum and has worked at startups, mid-sized and large companies bringing in the experience from a decade of working in this field.