For AI agents

This page is for coding agents, assistants and retrieval pipelines that read these docs or write code against RosieOS. Everything here is a summary of other pages. When a detail matters, follow the link and read that page.

Robot data and downloads#

The URDF, MuJoCo model, SRDF, STEP, meshes and robot.json of the Rosie 600, 1000 and 1400 are static files with stable URLs. /agents.md is the step-by-step guide to fetching them, with copy-paste curl, Python and JavaScript and a link to every file. /agents.json is the same list as JSON, and /assets/sim/index.json lists every kit file.

• Plain HTTPS GET or HEAD: no login, no API key, no cookies.
• Any User-Agent works, including the defaults of Python urllib, requests, Node fetch, Go, curl and wget.
• CORS is open (Access-Control-Allow-Origin: *) on the data files, so a web page can load the JSON, URDF, STL and GLB files directly.
• Byte ranges and ETag revalidation work.
• The URDF and MJCF use relative mesh paths, so they load from their URL or from the unzipped kit.

If your environment cannot reach advancedmetalresearch.com, use the mirror on GitHub, advanced-metal-research/rosie-sim-kits. The same files are at https://raw.githubusercontent.com/advanced-metal-research/rosie-sim-kits/main/sim/..., and its sim/index.json lists them with mirror URLs. Failing that, ask your user to download the kit ZIP and attach it. Every file is inside it.

Read the docs as data#

The system in brief#

• One public control API. Every client drives the robot through rt-control. That includes the pendant, offline programming (OLP), the motion servers and your code. It serves HTTP/JSON on the Unix socket /run/rosie-rt-core/control.sock, and optionally over mutual TLS on 127.0.0.1:8443 for remote clients. Behind it, the 1 kHz real-time core owns the EtherCAT drives. See Architecture.
• One controller at a time. acquire returns a fence: a session token and a generation, under an expiring lease. Every later command carries that exact fence. Renew before the lease runs out. A second client gets control_already_owned. See Control authority.
• Three kinds of motion request. Jog (begin_jog, datagrams on jog.sock, end_jog), trajectories (prepare_trajectory, start_trajectory) and programs (prepare_program with a .rdt file, then start_program). The motion paths page says which process owns each path.
• Clients. The Go SDK, the header-only C++ client, TypeScript contracts (types only, no HTTP client) and the rtctl CLI.
• Other services. The OLP server on 127.0.0.1:8794 and the weld planner on port 8796. The planner listens on all interfaces by default. Neither has authentication. Every port and socket is listed in Ports and environment.
• Formats. robot.v4.program.v2 programs, the .weldplan plan request, .rdt dense trajectories, and robot description and configuration files.

Safety rules you must respect#

Read the safety model before you write code that moves hardware. In short:

• There is no software E-stop. RosieOS contains no safety-rated function. The cell's hardware E-stop and safety chain are the only emergency stop. Stop, Halt, lease expiry and the pendant's hold-to-enable trigger are software functions, and they can fail with the software that runs them.
• Only planned weld programs are verified. A weld program is admitted at OLP Load only if the weld planner's collision, limit and tracking certificate passes. Jog, moves and Home are checked against joint limits only, not against collisions.
• Torch outputs are refused everywhere. RosieOS does not switch a welding torch. No seam tracking or sensing is implemented; see Process I/O and sensing.
• Simulation does not qualify hardware.
• Claim only what the safety model allows. It gives the exact sentence you may use about program verification.

Rules of thumb for code#

• The server decodes strictly. Unknown fields, duplicate fields and trailing data are refused.
• Put a request_id on JSON commands so that you can retry them safely, and use a fresh one for every logical attempt. /v1/program uploads have no deduplication: never replay an uncertain upload. See idempotent retries.
• Refusals are HTTP 409 with a reason in error (413 for an oversized body). Match on the leading label. Treat an unknown label, a malformed reply or a transport failure as an unknown outcome. Stop producing motion, send an authenticated stop if you can, and reconcile Status before you acquire again. See Error codes.
• A 200 reply for motion acknowledges admission, not physical completion. Follow events and telemetry to see what happened.
• Keep uint64 values exact. In TypeScript they exceed the safe integer range.

Where to find things#