Build, flash, update
Forge, Anvil, Channels. One signed version for the whole robot.
DeviceNexus Physical AI Platform
From bare board to managed fleet.
Your hundredth robot should be as reproducible as your first. One signed version for NVIDIA Jetson and Raspberry Pi robots and the ESP32 and STM32 controllers behind them: flashed offline from a tablet, updated over the air, repaired in the field.
Focus on the robot, not the plumbing.
Under every fleet sit five systems nobody planned to build: images, flashing, updates, remote support and board replacement. The people who can build them safely are the people you hired to build the robot.
We built that layer once. You keep the robot, the health checks that decide a release, and the signing key.
Run the comparison with your own numbers: the engineer-months on this layer last year, next to our price. See pricing
Build
Forge turns stock JetPack or Yocto into one signed image with two system slots, so a first flash and an update never disagree about what a version is.
Image building with Forge- OSJetPack 7.2, two slots
- firmwareESP32 display 1.4
- containersby digest
- ROS 2navigation bundle
- Pixiperception env
- aptoffline closure
- configfile trees, atomic switch
signed with your KMS key
by cable, at the bench (Anvil)over the air, in the field (agent)
Verified in full before the switch, rolled back together, confirmed per device.
Flash
Start to flash complete, on an SD card, from a tablet in airplane mode.
NVIDIA's flashing tools only run on x86, so the tablet never runs them: one recovery-mode exchange, then the board writes the image itself.
How the flash works, slowest runs includedTablet
0:00StartPlug in, type ERASE
secondsRecovery boot78.4 MiB
streamingFirmware and OSQSPI and both slots
4:16Flash completeSD card, under five minutes
first bootEnrolled, no consoleWi-Fi, token, keys already written
4:42Set upBlank board to set up, one cable
Jetson
The usual way
An x86 PC at the bench, Ubuntu or Windows WSL, running SDK Manager over a USB cable. Roboticists tell us: about 30 minutes, and a chore.
With Anvil
An Android tablet, a Mac or a Linux machine, one cable, no network. Flash complete at 4:16 on an SD card, set up at 4:42, and the board joins its fleet on first boot.
Watch a full flash
One take, from plug-in to set up, with the clock in frame. Nothing sped up and nothing cut, including the slow parts.
Enroll
Wi-Fi, token and keys are written at flash time, so the board joins its fleet on first boot. No console, no post-flash script.
Fleet operationsUpdate
JetPack 6 to JetPack 7 over the air on an Orin Nano developer kit, with the old system kept as the way back.
Your health checks make the commit call; a robot that cannot confirm boot goes back on its own.
How an update travelsSlot AJetPack 6. Booted and confirmed. Kept as the way back.running
Slot BJetPack 7. Written from the objects it lacked, resumable.verified, waiting to boot
VerdictFrom the slot that actually booted, never a version string. Held until acknowledged.health checks
RolloutGroups by rule. A publish preview says how many robots update and why some will not. N at a time on OS updates.3 of 20
Recover
Offline, a crashed application restarts and a reconnected camera re-binds, no download. Connected, DeviceView runbooks and remote support.
Recovery and remote supportDevices61 robots, 1 needs attention, 02:14
Needs attentionrobot-07JetPack 6 to 7, boot confirmation missingslot A kept as the way back, evidence captured 02:14Return to previous system
Updatingrobot-12Writing slot B, 61%resumable, 3 of 20 at a timePreview
Workingrobot-03Camera timeout three times, recovered locally at 01:52rule: repeated camera timeout on this releaseRunbook
Compute board diesA tablet-provisioned spare takes the role.
Disconnected robot, security fixSigned package on the tablet, verified locally.
Camera workload failsDetected on the robot, retries capped, escalated when connected.
Replace
A replacement board takes the robot's role from the tablet; identity, history and the calibration gate stay with the role, not the part. Replace is Flash again, from the same signed version.
Blueprints and replacementThe boards
NVIDIA Jetson is the demonstration platform; the system is built around your hardware. Every board gets the same signed version, the same spare slot and the same way back.
NVIDIA Jetson Orin Nano 8GB developer kit
- Flash from
- Android tablet, Mac, Linux
- OS
- JetPack 6 and 7, NVMe or SD
- Updates
- Signed A/B with rollback
Raspberry Pi 5 and 4
- Flash from
- Card write from a station
- OS
- Debian 13
- Updates
- Signed A/B with rollback
ESP32 family
- Flash from
- The robot's own computer
- OS
- Your firmware with our companion
- Updates
- A/B with automatic rollback
STM32 Nucleo F446RE and G474RE
- Flash from
- The robot's own computer
- OS
- Your firmware with MCUboot
- Updates
- Swap and confirm
Jetson Orin NX, AGX Orin, third-party carriers
Bring yours to the design review and we flash it on camera.
Hardware procurement service
No board chosen yet? Tell us what you are building and how many units. We introduce you to two or three manufacturers that fit, by name, only with your approval. The hardware and its warranty stay between you and the maker. Find a manufacturer
Verified on the robot, down to the controller.
0bytes
Signed updates are table stakes. What is rare is where the check happens: on the robot, before anything is written, and on the ESP32 and STM32 controllers behind it. Five deliberate bad signatures, on hardware: zero bytes written.
- Your signing key stays in your AWS or Google Cloud KMS. Nobody, DeviceNexus included, can install what you did not sign.
- Separate keys for first flash, platform software and your applications.
- The whole stack runs on your servers from one Docker Compose file.
ISO/IEC 27001 certified. SOC 2 Type II examination completed.
The security page, limits includedDeviceNexus holdsTrust rootIn the agent and the controller firmware.
DeviceNexus holdsTenant bundleWhich of your keys the robots accept.
You holdYour keyIn your KMS. We never hold the private half.
The robot checksSigned versionOne changed byte is refused before anything is written.
Remote support
Runbooks offline, remote shell and desktop when connected. On your Jetsons and Raspberry Pis today, as Linux devices.
Android Enterprise EMM
For robots, kiosks and dedicated-device fleets on Android, from the same company. Zero-touch enrollment, a companion app and a custom launcher.
Your robots
The base of a bigger loop.
This page is the base of the Physical AI loop: teach, train, validate, deploy, improve. Build, flash, update, recover and replace are how deploy happens on a real robot, and how the field reports back to the bench.
The Physical AI PlatformFrequently asked questions
Short answers. Anything not here is a question for the design review.
Can I flash an NVIDIA Jetson from an Android tablet?
Yes. Anvil flashes a bare Jetson Orin Nano developer kit from an Android tablet over one USB-C cable, with the tablet in airplane mode. NVIDIA's flashing tools are 32-bit x86 binaries with no ARM build, so the tablet never runs them: one recovery-mode exchange, then the board writes the bulk transfer itself.
On an SD card the flash completes at 4:16, and the board is set up at 4:42. Wi-Fi, the enrollment token and keys are written at flash time, so the board joins its fleet on first boot with no console.
Which boards does DeviceNexus support?
NVIDIA Jetson Orin Nano 8GB developer kit, flashed from an Android tablet or a Mac or Linux station, on JetPack 6.2.2 and 7.2, NVMe and SD. Raspberry Pi 5 and 4 on Debian 13 with two system slots, written to the card from a station. ESP32 controllers through the robot's own computer, with automatic rollback. STM32 Nucleo F446RE and G474RE with MCUboot.
Jetson Orin NX, AGX Orin and third-party carriers: bring yours to the design review and we flash it on camera.
How do over-the-air updates work?
A Channel publishes a signed version to a group of robots. Each robot pulls only the objects it lacks, verifies the signature and every digest, writes the spare system slot, and reboots only when the rollout and the device both allow. Booted is not done: your health checks make the commit call, and a ROS 2 bundle whose heartbeat dies rolls back on its own.
A publish preview says how many robots will update and why some will not, and OS updates go N at a time.
Can it move a robot from JetPack 6 to JetPack 7 over the air?
Yes. One bench run on the Orin Nano developer kit, on NVMe, took JetPack 6 to JetPack 7 over the air with the old system kept as the way back. The same mechanism moved a Raspberry Pi 4 from Debian 13.7 to 13.7.1 and back.
What happens when an update fails?
If boot confirmation never arrives, the robot returns to the previous system, and the failure surfaces at the top of the console as Needs attention with the evidence captured. A result that cannot be proven is recorded as unknown while the robot waits for a person.
Does it work offline?
Flashing works with no network at all. On the robot, a crashed application restarts without a download, and a reconnected camera re-binds the application that uses it. DeviceView runbooks and remote support need a connection.
Can we self-host it?
Yes. The whole stack runs standalone from one Docker Compose definition.
How is the software signed, and who holds the keys?
Versions are signed with Ed25519 over content-addressed objects, so one changed byte is refused before anything is written. Your signing key lives in your AWS or Google Cloud KMS; only the public half is registered. Separate keys sign first flash, platform software and your applications. DeviceNexus holds the trust root compiled into the agent and the controller firmware, and the tenant bundle that says which of your keys the robots accept.
A compromised backend can install only what you signed. It can decline to offer updates, or offer an older version you once signed. DeviceNexus holds ISO/IEC 27001 certification and has completed a SOC 2 Type II examination. Controller authorization is release policy, not secure boot.
What does it cost?
DeviceView, the remote-support layer, is $1.00 per device per month with a free Pilot tier, and it runs on your Jetsons and Raspberry Pis today as Linux devices. Pricing for the build, flash and update layer is on request.
How are DeviceNexus, DeviceView and AndroidNexus related?
They are one company and one stack. DeviceView is the remote-support layer. The Physical AI Platform (Forge, Anvil, Channels) is the build, flash and update layer. AndroidNexus is the Android Enterprise EMM for robots, kiosks and dedicated-device fleets.
Bring your board, your image, and your release process.
A design review, not a demo: which computers, carriers and controllers; what defines healthy; how long without a connection. Bring an Orin NX on your own carrier and we flash it on camera.