Embodied installation
NeuraFrame Embodied runs in two places: the training server, where your heavy model teaches it in simulation, and the robot itself. You install the software on both. The model stays on the server; the only thing that travels to the robot is the learned memory.
Yes, Embodied runs in both places
The same NeuraFrame Embodied runs on the training server and on the robot, and that is deliberate. Because it is the same engine and the same memory format on both, the memory you build in simulation drops straight onto the robot with no translation. What changes between the two is the job it does and what runs next to it.
| Where | Its job | What runs next to it | Hardware |
|---|---|---|---|
| Training server | Learn. It acts in simulation, escalates when unsure, and your teacher corrects it until its memory fills. | The simulator and your heavy teaching model or policy | Usually an x86_64 server, where compute is cheap; any 64-bit Linux works |
| Robot | Run. It acts from the learned memory in milliseconds and escalates anything new. | Your sensors and actuators. No model on board. | Any 64-bit Linux controller: ARM64 (Jetson Orin or other ARM64 boards) or x86_64 |
The clearest way to hold it: there are three separate parts, and only one of them travels.
| Part | Where it lives | Does it travel to the robot? |
|---|---|---|
| The NeuraFrame Embodied software | Installed on both machines, from the build for each one's processor | No. You install it fresh on the robot; it is not copied from the server. |
| The teaching model | The server only | No. The model never goes on the robot. |
| The learned memory (the memory pack) | Built on the server, used on the robot | Yes. This one file is the only thing you carry over. |
So the robot gets its own fresh install of NeuraFrame Embodied, and then just the memory pack. The software is installed on each machine separately; the model stays behind; only the memory travels.
What you need
| Item | Requirement |
|---|---|
| Platform | Any 64-bit Linux, ARM64 or x86_64, on either machine |
| Python | 3.8 or newer |
| Your stack | Perception (vision, sensors) and control (motors, planner, base policy) stay yours; Embodied sits around them |
Install on each machine
Both machines run NeuraFrame Embodied. You download the build that matches each machine's processor, not its role: either build can be the robot or the training host, and anything on 64-bit Linux is supported. It is the same product and the same version on both, not a cut-down edition for the robot.
| Build | Download | Runs on |
|---|---|---|
| ARM64 | neuraframe-embodied-jetson-0.1.0.tar.gz | Any ARM64 Linux: Jetson Orin, other ARM64 robot controllers and boards, ARM64 servers |
| x86_64 | neuraframe-embodied-server-0.1.0.tar.gz | Any x86_64 Linux: industrial PCs, workstations, servers |
The ARM64 file is labeled jetson for historical reasons; it runs on any ARM64 Linux, not only Jetson. So a Jetson Orin robot uses the ARM64 build, an x86 industrial-PC robot uses the x86_64 build, and your training server uses whichever matches it. The robot build is light not because it is a smaller product, but because the model never ships to the robot: only the engine and the learned memory run there. A lower-spec robot needs no special package from us, just the build for its processor. Get the two you need from the download page and run the installer as root on each.
# on the robot; ARM64 shown, use the x86_64 build on an x86 robot tar -xzf neuraframe-embodied-jetson-0.1.0.tar.gz cd neuraframe-embodied-* sudo bash install.sh neuraframe status # confirm the runtime and license state
The package installs the compiled engine, the Embodied experience layer, the neuraframe command, and the fleet client so a device can later join an Embodied Fleet. It contains no model. Embodied is its own product line with its own version (0.1.0), released separately from Studio.
Put the robot into service
Bringing a robot online is three steps, in order. The memory pack is the last of them: it has nowhere to load until Embodied is installed and licensed on the machine.
- Install the build for the robot's processor (ARM64 or x86_64), as above.
- License the device: start a trial or activate, so it runs from memory instead of staying in pass-through. See Licensing & trial.
- Import the memory pack you exported from simulation, then set the deployment mode.
# on the training host, after simulation MemoryPack.export(store_dir, "walker.nfmem") # copy walker.nfmem to the robot; with Embodied installed and licensed, then MemoryPack.import_("walker.nfmem", store_dir) # the robot boots warm
Importing onto a machine that does not have Embodied installed does nothing, and importing onto an unlicensed device leaves it in pass-through, so it holds the memory but escalates instead of acting until you license it. How to raise the agent, set the deployment mode, and define the safety rules is on Operating & modes.
Try the bundled example
The example tells the whole story in one run, with no model or robot required: it trains in simulation, ships the memory to a file, boots a fresh agent warm, teaches a new situation, and shows the safety law holding.
python3 examples/embodied_example.py
Updating a device
To move a robot or sim host to a newer Embodied build, install the new package over the current one, the same way you installed it. The device keeps its license and, more importantly, its learned memory: the store lives outside the program files and is schema-versioned, so a newer engine opens the existing memory and migrates it in place. The machine stays warm across the upgrade and does not re-learn. Only a purge removes that memory.
tar -xzf neuraframe-embodied-*.tar.gz cd neuraframe-embodied-* sudo bash install.sh neuraframe status