Prepare a persistent SDK workspace, identify the imported image and select the build target for your RobustOS Device. Complete a sample package build before moving to your own C application.
Applies to: Application development for RobustOS Devices using the SDK package and build target supplied for the exact device model and variant.
Development testing: This workflow has not yet been validated across host and SDK combinations. Record the actual build and device results for your selected release before adopting it for production development.
Your host is the Windows, macOS, or Linux computer you use for development. Docker runs the SDK container, which holds the SDK and tools that build applications for your selected device. The device runs the application after installation.
Run docker commands on the host. Run SDK make commands inside the container. Run device commands only in a device shell. A binary built for the device is not a host application.
The SDK workspace is /root/ROS-SDK inside the container. A dedicated Docker volume stores that workspace between sessions. Export completed packages to a normal directory on your host so that you can select them in the device Web interface.
Before importing the SDK, record:
Record the SDK archive release separately from the device firmware version. Select the image from the actual archive and its release information.
For example, r3000 and r5010a are build targets used in the R3000 and R5010 examples respectively. Use the target confirmed for your actual SDK release. Do not derive a target by lowercasing a model name.
Follow the steps below to prepare the workspace manually. If you want to delegate the same work to an AI assistant, use the linked AI setup guide at the end.
Choose the host path that matches your computer:
Installation references: Windows, macOS, and Docker Engine on Linux.
On the host, run:
docker version
docker info
docker context show
Both the client and server must respond. Confirm that the selected Docker context points to the intended development environment and that it runs Linux containers. If only the client responds, start or repair the Docker service before continuing. A remote context builds on a different machine; use one only when that is your intended setup.
If the host, Docker server, and SDK image architectures differ, use a validated configuration for that combination. Cross-architecture execution is not established merely by successfully importing an image.
In the commands below, replace every value in angle brackets, including the brackets. Keep quotes around paths. Commands labelled host run in PowerShell or your host terminal; their container paths always use /.
If the SDK distributor supplies a checksum, compare it with the archive before loading it. These are host-specific ways to compute SHA256:
# Windows PowerShell
Get-FileHash -Algorithm SHA256 -LiteralPath 'C:\path\to\sdk-archive.tar'
# macOS
shasum -a 256 "/path/to/sdk-archive.tar"
# Linux
sha256sum "/path/to/sdk-archive.tar"
Stop if the supplied checksum does not match. A locally calculated checksum identifies the file you used; it proves authenticity only when compared with a trusted reference.
On the host, import the archive:
docker load --input "<SDK_ARCHIVE_PATH>"
Record the image reference reported by the command. If the archive contains several images, select the one identified by the release information. For ros-sdk-5.0.3.tar, the archive metadata identifies ros-sdk:5.0.3, platform linux/amd64, and the default command /bin/bash. Inspect your actual image rather than assuming another archive has the same configuration:
docker image inspect "<LOADED_IMAGE_REFERENCE>"
Record its full Id, Os, Architecture, Config.Entrypoint, and Config.Cmd. Use that full image ID as <SDK_IMAGE_ID> below. Confirm the startup configuration against the SDK release instructions; the next example uses the image's default command.
Choose unique names for <SDK_CONTAINER> and <SDK_VOLUME>. Use a separate workspace for each SDK image and build target. Reusing an old volume with a new image can retain the old SDK files.
On the host, check whether those names are already in use:
docker container inspect "<SDK_CONTAINER>"
docker volume inspect "<SDK_VOLUME>"
For new names, “not found” is expected. If a resource exists, resume it only after checking its image, mounts, and project identity. Choose new names when it belongs to another project.
Create the workspace and start the container on the host:
docker volume create --label "robustos.sdk.project=<PROJECT_ID>" "<SDK_VOLUME>"
docker run -dit --name "<SDK_CONTAINER>" --label "robustos.sdk.project=<PROJECT_ID>" --mount "type=volume,src=<SDK_VOLUME>,dst=/root/ROS-SDK" "<SDK_IMAGE_ID>"
docker container inspect "<SDK_CONTAINER>"
Use a project ID consisting of letters, digits, and hyphens. Confirm that the container is running, uses the selected image ID, and mounts the named volume at /root/ROS-SDK. A new empty volume is populated from the image directory by default. If the container immediately exits, inspect its logs and the release's startup instructions; do not repeatedly recreate it with guessed commands.
Open an SDK shell from the host:
docker exec -it -w /root/ROS-SDK "<SDK_CONTAINER>" /bin/sh
Inside the container, check your location and required files:
pwd
ls Makefile rules.mk package
command -v make
You should be in /root/ROS-SDK, with the SDK Makefiles and package directory present. If the directory is empty, check the image and volume selection before creating application files.
Inside the container, from /root/ROS-SDK, select the confirmed target. Replace the placeholder before running:
make "<BUILD_TARGET>"
make package/sample_shell/install
The SDK examples include make r3000 and, in the matching R5010 SDK, make r5010a. Select one target for this workspace.
After the commands complete successfully, find the sample package:
find bin -type f -name '*sample_shell*.rpk'
Use the actual output location. Do not assume that every SDK release uses the same target subdirectory or filename. If several candidates exist, match the package to the selected target and current build output before exporting it.
This check exercises the sample package workflow. The Hello World application guide checks that your target compiler can build your own C source.
Type exit to leave the shell opened by docker exec. To stop the SDK container, run this on the host:
docker stop "<SDK_CONTAINER>"
To resume later, use the same project resources:
docker start "<SDK_CONTAINER>"
docker exec -it -w /root/ROS-SDK "<SDK_CONTAINER>" /bin/sh
Keep the SDK volume while developing; it contains your workspace. Copy important source changes to your normal source repository or backup location as well.
Build the four-file Hello World application. A sample shell package checks packaging; a successful target C build checks the compiler path as well.
To delegate setup and the C build to an AI assistant, use Set up the RobustOS SDK with AI.