Creating and restoring backups of settings

The rc_cube offers the possibility to download the current settings as backup or for transferring them to a different rc_visard or rc_cube.

The current settings of the rc_cube can be downloaded on the Web GUI’s System page in the rc_cube Settings section. They can also be downloaded via the rc_cube’s REST-API interface using the GET /system/backup request.

For downloading a backup, the user can choose which settings to include:

  • nodes: the settings of all modules (parameters, preferred orientations and sorting strategies)
  • load_carriers: the configured load carriers
  • regions_of_interest: the configured 2D and 3D regions of interest
  • grippers: the configured grippers (without the CAD elements)

The returned backup should be stored as a .json file.

The templates of the SilhouetteMatch and CADMatch modules are not included in the backup but can be downloaded manually using the REST-API or the Web GUI (see Template API and Template API).

A backup can be restored to the rc_cube on the Web GUI’s System page in the rc_cube Settings section by uploading the backup .json file. In the Web GUI the settings included in the backup are shown and can be chosen for restore. The corresponding REST-API interface call is POST /system/backup.


When restoring load carriers, all existing load carriers on the rc_cube will get lost and will be replaced by the content of the backup. The same applies to restoring grippers and regions of interest.

When restoring a backup, only the settings which are applicable to the rc_cube are restored. Parameters for modules that do not exist on the device or do not have a valid license will be skipped. If a backup can only be restored partially, the user will be notified by warnings.

Updating the firmware

Information about the current firmware image version can be found on the Web GUI’s System ‣ Firmware & License page. It can also be accessed via the rc_cube’s REST-API interface using the GET /system request. Users can use either the Web GUI or the REST-API to update the firmware.


When upgrading from a version prior to 21.07, all of the software modules’ configured parameters will be reset to their defaults after a firmware update. Only when upgrading from version 21.07 or higher, the last saved parameters will be preserved. Please make sure these settings are persisted on the application-side or client PC (e.g., using the REST-API interface) to request all parameters and store them prior to executing the update.

The following settings are excluded from this and will be persisted across a firmware update:

  • the rc_cube’s network configuration including an optional static IP address and the user-specified device name,
  • the latest result of the Hand-eye calibration, i.e., recalibrating the rc_cube w.r.t. a robot is not required, unless camera mounting has changed, and
Step 1: Download the newest firmware version.

Firmware updates will be supplied from of a Mender artifact file identified by its .mender suffix.

If a new firmware update is available for your rc_cube device, the respective file can be downloaded to a local computer from

Step 2: Upload the update file.

To update with the rc_cube’s REST-API, users may refer to the POST /system/update request.

To update the firmware via the Web GUI, locate the System ‣ Firmware & License page and press the “Upload rc_cube Update” button. Select the desired update image file (file extension .mender) from the local file system and open it to start the update.

Depending on the network architecture and configuration, the upload may take several minutes. During the update via the Web GUI, a progress bar indicates the progress of the upload.


Depending on the web browser, the update progress status shown in the progress bar may indicate the completion of the update too early. Please wait until a notification window opens, which indicates the end of the update process. Expect an overall update time of at least five minutes.


Do not close the web browser tab which contains the Web GUI or press the renew button on this tab, because it will abort the update procedure. In that case, repeat the update procedure from the beginning.

Step 3: Reboot the rc_cube.

To apply a firmware update to the rc_cube device, a reboot is required after having uploaded the new image version.


The new image version is uploaded to the inactive partition of the rc_cube. Only after rebooting will the inactive partition be activated, and the active partition will become inactive. If the updated firmware image cannot be loaded, this partition of the rc_cube remains inactive and the previously installed firmware version from the active partition will be used automatically.

As for the REST-API, the reboot can be performed by the PUT /system/reboot request.

After having uploaded the new firmware via the Web GUI, a notification window is opened, which offers to reboot the device immediately or to postpone the reboot. To reboot the rc_cube at a later time, use the Reboot button on the Web GUI’s System page.

Step 4: Confirm the firmware update.

After rebooting the rc_cube, please check the firmware image version number of the currently active image to make sure that the updated image was successfully loaded. You can do so either via the Web GUI’s System ‣ Firmware & License page or via the REST-API’s GET /system/update request.

Please contact Roboception in case the firmware update could not be applied successfully.

Restoring the previous firmware version

After a successful firmware update, the previous firmware image is stored on the inactive partition of the rc_cube and can be restored in case needed. This procedure is called a rollback.


Using the latest firmware as provided by Roboception is strongly recommended. Hence, rollback functionality should only be used in case of serious issues with the updated firmware version.

Rollback functionality is only accessible via the rc_cube’s REST-API interface using the PUT /system/rollback request. It can be issued using any HTTP-compatible client or using a web browser as described in Swagger UI. Like the update process, the rollback requires a subsequent device reboot to activate the restored firmware version.

Rebooting the rc_cube

An rc_cube reboot is necessary after updating the firmware or performing a software rollback. It can be issued either programmatically, via the rc_cube’s REST-API interface using the PUT /system/reboot request, or manually on the Web GUI’s System page.

Updating the software license

Licenses that are purchased from Roboception for enabling additional features can be installed via the Web GUI’s System ‣ Firmware & License page. The rc_cube has to be rebooted to apply the licenses.


If a computer screen as well as mouse and keyboard are connected to the rc_cube, the software license can also be updated directly at the rc_cube using the Web GUI and a separate USB flash drive from which the new license file can be installed.

Downloading log files

During operation, the rc_cube logs important information, warnings, and errors into files. If the rc_cube exhibits unexpected or erroneous behavior, the log files can be used to trace its origin. Log messages can be viewed and filtered using the Web GUI’s System ‣ Logs page. If contacting the support (Contact), the log files are very useful for tracking possible problems. To download them as a .tar.gz file, click on Download all logs on the Web GUI’s System ‣ Logs page.

Aside from the Web GUI, the logs are also accessible via the rc_cube’s REST-API interface using the GET /logs and GET /logs/{log} requests.


If a computer screen as well as mouse and keyboard are connected to the rc_cube, the log files can also be download directly from the rc_cube using the Web GUI and a separate USB flash drive on which the log files can be stored.