Closing the Physical AI Loop: From Simulation to Fleet Deployment on AWS

Physical AI is the branch of AI that operates in the physical world instead of just reasoning about it, and robots are its clearest expression. Most of what makes this hard has nothing to do with any single model. It’s the loop underneath it, the ongoing cycle that keeps models improving as robots rack up real operating hours.

In practice, that loop rarely gets built first. Teams wire simulators to message buses and route telemetry through edge gateways long before anyone trains a model, then bolt on storage as an afterthought. Nearly every new robotics project ends up rebuilding this same pipeline from scratch.

This post walks through a reference architecture for closing that loop on AWS: turning robot operating data into training data, training new models, and redeploying them back to the robot as one continuous cycle. We demonstrated the live data path at the Robotics Summit & Expo (MassRobotics, Boston, May 2026), using a simulated NVIDIA Nova Carter robot. VividCloud, the software engineering firm behind the demo, builds cloud-connected robotics and IoT systems on AWS.

Watch the demo: Demonstrations in Physical AI Architecture

The loop, defined

A useful way to frame Physical AI development is as a single loop with four stops: a robot generates data as it operates, that data lands in durable storage, models train on it, and new models deploy back to the robot, which then generates more data.

Once redeployment is automatic, training, deployment, and testing stop being separate phases. Every operating hour feeds the next model version, and the boundary between collecting data and using it effectively disappears.

The rest of this post follows that loop around, one stop at a time.

From simulation to data lake

Simulation is where the loop starts, and it is why you can build the whole pipeline before hardware arrives. NVIDIA Isaac Sim runs on a GPU-backed Amazon EC2 instance (G5 or G6 family) and produces physics-accurate sensor data. It publishes standard ROS 2 topics: odometry, camera frames, laser scans, and transforms.

AWS IoT Greengrass v2 runs next to the simulator and subscribes to those ROS 2 topics. A Greengrass component serializes each message and publishes it to AWS IoT Core over MQTT. Greengrass is the edge runtime, so the same component definition runs whether the robot is simulated or real.

From IoT Core, an IoT rule fans the data out two ways. One copy streams to a dashboard for real-time monitoring. Another copy flows through Amazon Data Firehose into Amazon S3 as Parquet, cataloged by AWS Glue and queried with Amazon Athena.

Camera frames at 30 frames per second have no business sitting on an MQTT broker, so the architecture splits by data gravity: high-rate imagery goes straight to S3, while MQTT carries the compact telemetry. Each transport handles the job it’s actually suited for.

At the demo, this path sustained roughly 50 messages per second, with telemetry queryable in Athena within about a minute of being generated.

A training-ready data schema

Collecting data is the easy part. Making it something you can actually train on is where most teams fall short.

Each mission we record uses a schema built for vision-language-action training from the outset, capturing a mission identifier, a temporal frame index, the action label, an S3 pointer to the corresponding camera frame, and the natural-language instruction that produced the trajectory. That natural-language field is what ties a plain-English intent to the observation and action that followed it, which is exactly the shape a downstream training job needs. Building that structure at capture time is far cheaper than reconstructing it after the fact.

The result: the data your robot produces today becomes the training set for the model it runs next month.

The training flywheel on SageMaker

Once operating data lands in S3 with a training-ready schema, Amazon SageMaker AI becomes the hub of the loop, and each stop around that ring maps to a managed SageMaker capability. Amazon SageMaker Ground Truth labels and curates the raw trajectories, training jobs distributed across accelerated instances (when the workload calls for it) produce new model versions, and the SageMaker Model Registry versions each artifact so there’s always a record of what shipped.

Nothing reaches a robot without clearing governance first: human-in-the-loop review through Amazon Augmented AI, paired with automated evaluations, gates promotion, and once a model is deployed, Amazon CloudWatch watches for drift and quality regressions that feed the next round of labeling.

Worth flagging plainly: this ring is a reference design, not something we ran live at the booth. It builds on the same S3 data lake we did demonstrate, using managed services instead of custom infrastructure, so it’s realistic to stand up incrementally rather than all at once.

Deploying models with Greengrass

Redeployment is the stop that closes the loop, and it reuses infrastructure you already have: Greengrass isn’t just how robot data reaches the AWS Cloud, it’s also the path new software takes back down to the robot.

Once a model version clears governance in the Model Registry, an AWS Lambda function packages it as a Greengrass component revision, Greengrass pushes that revision over the air to the target robots, and each robot pulls the update and loads the new model.

From there, the robot runs its next missions on the updated model, those missions generate fresh data, and that data flows back through the same ingestion path described above. Edge to cloud and back to edge, the loop closes.

We call this a development loop rather than a training loop for a reason. Training produces a model, deployment ships it, and testing exercises it, and on this architecture, all three happen on every single cycle, on the same pipeline.

What we demonstrated at MassRobotics

At the booth, a simulated Nova Carter drove inspection missions in Isaac Sim while every sensor reading flowed through AWS in real time, and attendees could type plain-English commands and watch the robot respond within a couple of seconds, model inference included.

Amazon Bedrock interpreted those commands: a model reasoned over the mission, called tools to query telemetry and issue navigation goals, and reported back what it observed. That command path ran through a tool gateway, so the model never held cloud credentials directly; instead, tools executed under scoped IAM permissions, and every command stayed attributable and logged.

VividCloud was upfront with visitors about what was live versus what was reference. The data pipeline, the conversational control path, and the queryable data lake were all running in real time. The perception model and the SageMaker training flywheel represent the roadmap the architecture is built to support, not something demonstrated live.

We led with that distinction on purpose. The point of the demo was never a single clever trick. It’s that the same three zones, edge, ingestion, and storage and analytics, recur on every robotics project, and getting them right once means every future robot starts further ahead.

Why it matters

The same three zones, edge, ingestion, and storage and analytics, recur on every robotics project. Getting them right once means every future robot starts further ahead. Standard ROS 2 topics serve as the integration seam, so swapping a simulated robot for a physical one only changes topic names in the Greengrass component config, not the AWS architecture behind it. And least-privilege access is designed in from the start: the analytics role is scoped to a single Athena workgroup and Glue table, and the control path authenticates every command it receives.

Summary

Physical AI improves through a loop, not a single launch: simulation seeds it, a training-ready data lake feeds it, SageMaker trains on it, and Greengrass keeps redeploying the result. If you’re building connected robots, design that loop before you start collecting data. A training-ready schema and a managed edge-to-cloud path are cheap to establish early and expensive to retrofit later.

If you have a project with similar requirements, we’d like to discuss them with you Contact Us.