Open the Update tile on the hub, or Update in the logo menu. The screen has two tabs: Software update updates the software running on the robot and this app itself, and Firmware update updates the boards inside the robot (see Firmware update). The tile opens without a robot connected and is locked while spectating. A dot on the tile means a robot package that Auto update downloaded is waiting to be installed, or a board needs a firmware update.
The top of the panel shows two cards:
Current robot · Motion — Version, Branch, Commit, Build as reported by the robot.Update file — the package you are about to send: Selected file name, its Version, Size, the Target, and the target PC's System — its Ubuntu version and processor, for example u24-x86_64. — means this device has not connected to that robot yet. Older (RBQ-*) means the robot runs older robot software that does not report its System.There are two ways to get a package onto the device.
Online — the list below the cards shows the versions published for this app's release channel (Online update · internet required). Press Check versions (or Refresh) to fetch the list, then Download on the version you want. The download pulls the robot package onto this device, along with the app build on the Linux desktop app. The row then shows the package size, plus Latest and In use badges where they apply. Each robot package is built for one System. The app learns each robot's System every time it connects to that robot, and remembers it for that robot after the app or device restarts. The download is for the robot currently selected on the hub, so you can download on the internet network and switch to the robot network before sending. If this device has never connected to that robot, the app downloads the package for every System, about four times the size, and sends the one that matches the robot. A robot showing Older (RBQ-*) gets the older RBQ-* packages instead. The robot also refuses a version older than the one it is running. Remove deletes a downloaded package. The Release notes under the list cover the selected version, or the version the robot is running when nothing is selected. If a download stops, press Download again — it continues from where it stopped.
From USB or a file — press Load from USB or file. The system file picker opens (a USB OTG drive shows up there like any other storage). On a Steam Deck in Gaming Mode the app opens its own Choose a file window instead, with shortcuts to Home, Download, Music, Documents and Desktop, any inserted SD card or USB drive, and Up to move to the parent folder. Pick the package file. It must be the package for that robot's System, named core-<version>-<system>.rbq. Robots on older robot software that show no System take RBQ-<version>.zip or RBQ-<version>.tar.gz instead. The Update file card fills in with the file's name, version, and size.
Target selects which robot PC receives the package: Motion (the robot IP you are connected to) or Vision. Vision matters only on older robots that have a separate vision PC. If the robot has no vision IP set — the Vision IP field in its profile on the hub, or Vision PC IP (optional) when you add it by address, both developer mode — the app falls back to the default vision address and says so in a note.
Send robot software.Send to the robot? lists the file, size, and target. If the file is a robot package, the dialog warns that the robot will unpack and deploy it as soon as the transfer completes, replacing the running software. The dialog says files with any other name are only stored on the robot, but current robot software refuses them outright with a "Rejected file name" error — send only properly named packages. If the package is for a different System than the robot, or the robot no longer accepts RBQ-* packages, the app does not send it and tells you to download again with the robot connected.Send. The progress bar shows the percentage, and Cancel aborts the transfer. If the connection drops — the network blips, or you leave the app and come back — the card shows Reconnecting and the app sends the rest from where the robot stopped. Once the whole file is on the robot the card shows Installing on robot while the robot unpacks and installs it. Cancel is gone at this stage: the robot finishes the install even if the connection drops, and the app reconnects to read the result. If the install fails, the robot puts the previous version back and the app shows why.✓ Transfer complete and asks Deploy transfer complete — reboot now?. With a Vision target the dialog only says the vision PC cannot be rebooted from the app and closes with Check.Robot software takes effect only after you restart the robot service or reboot the robot PC. For a Motion target the reboot prompt offers Restart robot service and Reboot robot PC, with Later below them. Restart robot service restarts only the robot software and leaves the PC running, which is enough to apply the update; a robot set up without that service shows Restart request failed, and then use Reboot robot PC.
WARNING
Rebooting cuts motor power and the robot will sag to the ground. The robot must be in the sitting state before you reboot — sit it down first and make sure it is resting on the floor, and do not move it during the reboot. If the robot is standing, Restart robot service is refused with Restart request failed, while Reboot robot PC is ignored without an error. The app connection drops while the robot restarts. Reconnect afterwards and check that Current robot shows the new version.
The vision PC cannot be rebooted from the app. If the target was Vision, reboot that PC by hand.
The GUI Version line shows the version of the app you are running, followed by a badge:
NIGHTLY — a nightly build (its list shows Nightly builds · last 10 kept instead of the release list),LOCAL — a local build with no release channel; it does not check for updates.Next to it, Matches robot (with a check mark) or Differs from robot compares the app version with the robot version. Keeping the two the same is the intended pairing.
Once the version list has loaded, an update button appears if a newer app is available:
Update in store — store installs (Google Play / App Store). The store app opens; install from there.<version> Update — APK and desktop installs. The app downloads the build and installs it: Android hands it to the system installer, the Linux desktop app switches to the new build, and the Windows app runs the installer — the app closes right away and reopens on the new version, so any robot connection drops. On Windows the app first asks for confirmation (App update), and refuses with The robot is standing — updating closes the app and drops the connection. Sit the robot down, then try again while a connected robot is standing. Before running the installer it checks the download against the published checksum and stops if they differ. You're on the latest version is shown when nothing newer exists.On the Linux desktop app, Install online registers a build you downloaded but never installed, and Use this build switches to any downloaded build in the list.
Nightly builds only see nightly releases and release builds only see releases — the channel is fixed when the app is built.
Firmware update updates the boards inside the robot (16 leg motors, PDU, IF, SIDE_F, SIDE_H and TOP) to the latest firmware files stored on the robot. It is a different tab from Software update, which replaces the software on the robot PC. The robot reads each board's hw and picks the file for it. If the robot has no firmware file named with its hw for a kind of board, those boards are marked Not managed and skipped.
The 16 leg motors must all run the same firmware, so they are treated as one group. In the counts and lists on this screen the motors are one item (Motors (n)). A motor whose version matches but whose contents differ from the file is written again, and a banner appears at the top when the motors run different firmware. If any motor cannot be updated (for example a downgrade you did not agree to), the robot writes none of the motors and tells you why.
| Row | Effect |
|---|---|
Status | Counts the boards as Updatable, Latest and Needs check. The motor group counts as one. Boards that do not answer are counted as no response, and skipped boards as Not managed. Check versions makes the robot read the version and hw of every board again. It cannot be pressed while the robot is standing or walking. |
Update all | Updates the boards that need it one at a time, in the order PDU → IF → SIDE_F → SIDE_H → TOP → leg motors. It opens a confirmation first. |
WARNING
Update all cuts leg and arm power first, and leg and arm power stay off when it finishes. Start the robot again afterwards. Leg power is turned on only while the leg motors are updated. UPC power goes off briefly while the PDU is updated, and the 12V ports while the TOP board is updated. An update can start only while the robot is sitting or its control is off, and only while it is sitting if the joints are under control. It can also start after an emergency stop as long as leg power is off (a TOP board without an hw record holds the emergency stop).
When Update all cannot be pressed, the reason appears under the row.
The robot is active — sit it down and try again — the robot is standing or walking. It also appears when the joints are under control but the robot is not sitting, such as during auto start.Another device has control — another device holds control of the robot.Some boards need checking — the robot has no file for a board, or does not know the board's hw and so cannot pick a file. The board name and the reason follow. While any such board exists, the whole update does not run.No boards to update — every board is up to date or Not managed.The robot is busy with firmware work — try again when it has finished — the robot is doing other firmware work.The robot software does not support this — run Software update firstA board left in boot does not block the update even if its hw is unknown. The robot sends that board to its app, reads the hw again and then updates it with the matching file. The update is not blocked either when leg power is off and no motor answers. The robot then turns leg power on during the update and checks the motors.
One confirmation dialog lists the boards and everything you agree to. If the legs or the arm are under control, a sentence says power will be cut first, and the button becomes Cut power and update. If a board would go down to an older version than the one it has, that board and both versions are named (the motors in one sentence), and a board that was running firmware for another variant gets a sentence saying it is switched to the matching variant. If the check ran with leg power off, the motors have no verdict and you cannot agree to a motor downgrade. To take the motors down, press Check versions again with leg power on. If the robot's check result changes after the dialog opened, the update is not sent and the dialog asks again with the changes.
While the update runs, the same place shows the steps (48V off, the board names, Legs on, Motor, Legs off). The board being written gets a progress bar, and a resend shows its count, such as Retry 1/3. There is no stop button, and the update keeps running on the robot even if you close the screen. At the end you see Update complete — n boards with a note that power is still off. If it fails, the reason appears and the robot stops with leg power off. When sending to a board fails, the robot tries again up to three more times after the first attempt. If those fail too, it leaves that board in boot and stops. Update again after a moment.
A motor boot replacement started from the research screen also shows here, as Boot replace with the motor name, and its steps read Checking updater, Sending boot, Writing boot and Confirming new boot. Leave power on while it runs.
Motor firmware 261028 or later is not written to a motor whose bootloader is older than BOOT0 261027, or whose bootloader version the robot could not read. That firmware starts the data phase at 3M when its EEPROM is blank, while an older bootloader talks only at 4M, so the next update would lose the board. The update then stops with a reason such as HRP was not updated: its bootloader is too old for this firmware (261028 or later), and the next update would lose the board. Replace the bootloader first on the Research screen (BOOT0 261027 or later), then update again. Replace the bootloader first, then update again.
These banners can appear at the top of the hub and other screens.
Some boards need a firmware update (IF) — a board was left in boot, or a board is on standby because its firmware does not support its hw. Open brings you to this section.Motor firmware is mixed — run a firmware update — the motors differ in firmware version or verdict. Open brings you to this section.Some boards need an hw record — contact an administrator — a board is on standby because no hw is recorded on it. An update does not clear this.A board is on standby because its EEPROM does not respond — contact an administrator — the board cannot read its hw and is on standby. An update does not clear this.The X on the right of a banner closes it. It comes back when a different board is affected or when you reconnect to the robot.
What developer mode adds here is collected on Developer mode.