A robot simulation can work well on a development machine and still be difficult for someone else to use. The right checkout, dependencies, launch sequence, and knowledge of where to find the logs can all become part of the setup.
Recently, I built an AWS-hosted coordination service for remote robot simulation. The goal was straightforward: submit a job, let an available worker execute it, and retrieve the results without manually managing that machine for every run.
That meant working across Python APIs, containers, infrastructure as code, deployment automation, and the simulation runtime. The most useful lessons came from making those pieces behave together.
Separate coordination from execution
I split the system into a lightweight router and simulation workers. The router owns the queue, run records, and operator interface. Workers claim compatible jobs, start the simulator, report progress, and upload recordings and logs to object storage.
A simplified cloud simulation architecture. The cloud coordinates the work; remote machines run the simulator. The robot scene is illustrative, not a model of deployed hardware.
This distinction matters: cloud coordination does not require moving every simulation workload into an AWS instance. It lets the interface stay available while execution happens on machines equipped for the job. Workers initiate their connections to the router, so scheduling a run does not require opening an inbound connection to each worker.
Make the environment reproducible
I used Terraform for the cloud infrastructure, EC2 for the router, ECR for versioned container images, and Systems Manager for remote deployment operations. GitHub Actions handles builds and provides explicit deployment steps.
Packaging the worker as an image was a particularly useful change. A worker machine can pull a built environment instead of needing a source checkout, access to source repositories, and its own build process. Identifying the running image also makes it easier to understand which software produced a result.
The benefit is practical: less setup knowledge lives in someone’s head, and fewer differences between machines need to be investigated before running a test.
Design for the run that goes wrong
Getting a successful run through the system was one milestone. Handling interruptions made it much more useful.
I added worker heartbeats, detection of lost workers, and explicit failure states so a vanished process does not leave a job looking active indefinitely. I also implemented image updates that wait for the current run to finish, check whether the replacement worker comes back, and restore the previous version if it does not. Local end-to-end tests exercised both successful updates and a deliberately broken image, including avoiding repeated retries after a restart.
Another lesson was to test through the real client path. A deployment health check can pass while an actual worker is blocked by an authentication or network-policy difference. Similarly, a mocked registry client can pass tests without exercising how credentials are selected at runtime.
Those failures changed what I considered sufficient verification: the check needs to cover the behavior the worker actually depends on.
What made the work valuable
The result is a workflow for submitting simulation jobs remotely, executing them on available workers, and inspecting their outputs through a common interface. It also gives me a repeatable way to provision and update the software around those runs.
This experience made cloud infrastructure feel directly connected to robotics work. Packaging, deployment, observability, and recovery determine how easily a simulation can become part of a team’s everyday development process.
That is the part I am glad to have built: a path from a working local simulation to something other people can run and inspect without reproducing my entire development environment.