Use an AI assistant with terminal and file access to prepare a RobustOS SDK workspace and build a Hello World application. The same steps are included below so you can follow the work, inspect its results, or complete it manually.

Applies to: Application development for RobustOS Devices using the SDK package and build target supplied for the exact device model and variant.

Pilot guide for development testing: The manual build example was tested with SDK 5.0.3 and R1520 / RobustOS 5.6.0. Verify your AI assistant's commands and results for your own environment.

You need basic C and terminal skills. You can complete the build on your computer before connecting a device. To install and check the application, you also need a suitable development device, access to its Web interface, and a package that satisfies its installation requirements.

Give your AI assistant the task

Start with the RobustOS SDK download and supported-model information. Obtain the SDK package and build target confirmed for your exact model and variant. A model appearing in the SDK hub does not establish which archive or target it needs.

Copy the prompt below into an AI assistant that can operate your development computer. Fill in the device, target, archive location and output folder. If you provide the article URL instead of its text, make sure the assistant can read the complete article, including all four example files.

Read this article in full and prepare a RobustOS SDK development workspace
on this computer. Use the four complete Hello World files in the article.

Device model and variant: <EXACT_DEVICE_MODEL_AND_VARIANT>
Confirmed build target: <BUILD_TARGET>
SDK archive path or authorized download URL: <SDK_ARCHIVE_LOCATION>
Host output folder: <HOST_OUTPUT_FOLDER>
Project identifier: <PROJECT_ID>

1. Detect the host OS and CPU, available disk space, Docker client/server,
   container platform and Docker context. Report the intended local or
   explicitly requested remote execution environment. Ask for missing
   essential SDK/target information rather than deriving it from a model name.
2. If a container runtime is missing, use the official installation route
   appropriate to this host. Respect system permissions and organization
   policy. Record any required user authorization or restart and resume
   from that point when it is complete.
3. Obtain the specified archive, compare a supplied publisher checksum,
   and record its SHA256. Load it, inspect the actual image ID, OS, CPU
   architecture and startup command, and establish a suitable execution
   path. Do not claim ARM compatibility just because the image imports.
4. Create or resume a dedicated, labelled container and persistent SDK
   volume. Verify /root/ROS-SDK and select the confirmed target. Reuse only
   matching project resources; preserve existing source changes. Never
   remove unrelated containers, volumes, images or files.
5. Create all four example files exactly, using LF line endings and real
   Makefile tabs. Check scripts for CRLF before building; a CRLF script may build successfully but fail on the device. Run make package/helloworld/install from /root/ROS-SDK.
   Capture the actual exit code and build log. Confirm target C compilation
   and packaging; an old RPK or sample_shell package alone is insufficient.
6. Locate the RPK from this build and export it to my output folder without
   overwriting a different existing file. Record its path, size and SHA256.
7. Save an environment report with host/runtime details, archive and image
   identities, target, resource names, completed stages, log paths and
   resume commands. On failure, record the stage, reason and recovery step.
   Recheck saved state before retrying; do not erase the workspace to retry.

Complete the environment and build work within this request. Report any
required human action precisely. Stop at the exported RPK: device installation,
firmware changes and Developer Mode changes require a separate device task.
Do not report the environment as verified until the C build and export pass.

The result should include the actual build log, exported RPK, image and target identifiers, and commands for reopening the workspace. Docker starting successfully is only an intermediate result.

Prepare the SDK workspace

Understand where each action runs

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.

Gather the required inputs

Before importing the SDK, record:

• Your exact device model and hardware variant.
• The matching SDK archive and its release information, obtained from Robustel or your designated SDK administrator.
• The build target confirmed for that device and SDK release.
• The host operating system and CPU architecture, and the supported Docker/image combination for that host.
• A host directory for exported packages and a project name for the container and volume.

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.

The remaining steps provide the manual path and the command reference for your AI assistant.

Make Docker available

Choose the host path that matches your computer:

• Windows: use PowerShell and a Docker Desktop installation configured to run Linux containers. Follow the official installation requirements for the selected backend, including WSL or virtualization setup where needed.
• macOS: use Terminal and the Docker Desktop distribution for your Intel or Apple Silicon computer. Confirm that the SDK image has a validated execution path on that architecture.
• Linux: use the installation instructions for your distribution and ensure that your account can reach the Docker Engine service.

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.

Import and identify the SDK 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.

Create a persistent SDK workspace

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.

Select the device target and check package building

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 C application in the next chapter checks that your target compiler can build your own source.

Leave and resume the workspace

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 your first application

Know what the example does

The application sends hello world at debug level to the device's system log, then exits successfully. It is a short program, so a later process-status check may report that it is stopped. A new log entry is the expected execution result.

You will create a source file, a source Makefile, an SDK lifecycle script, and a package Makefile. The package Makefile tells the SDK how to build and place files in the device installation package.

Add the example files

Create a local working folder containing examples/helloworld/. All four complete files are provided below, so the AI assistant can create them directly:

helloworld/
├── Makefile
├── src/
│   ├── helloworld.c
│   └── Makefile
└── files/
    └── sdk.sh

Keep the source and scripts as plain text with LF line endings. Preserve the leading tabs in Makefile recipe lines. The package name helloworld contains no hyphen and is shorter than 18 characters, as required by the package naming rules.

Understand the source and build files

Create examples/helloworld/src/helloworld.c on the host with this content. It becomes package/helloworld/src/helloworld.c after copying:

#include <syslog.h>

int main(void)
{
    syslog(LOG_DEBUG, "hello world");
    return 0;
}

The program uses the system syslog() interface. It does not need a persistent loop to demonstrate compilation, packaging, and execution.

Create examples/helloworld/src/Makefile on the host with this content:

helloworld:
	$(CC) helloworld.c -o helloworld

The command line begins with a tab. $(CC) lets the SDK build process select the compiler. Build the package through the SDK root Makefile, so that the target configuration is used.

package/helloworld/files/sdk.sh sets PROG=helloworld and loads /usr/lib/functions on the device. Its handlers support start, stop, restart, status, on_startup, on_reboot, on_link_up, on_link_down, and status_sync. The example starts on startup; a link-up event stops and starts it; link-down and reboot events invoke stop. status_sync returns without adding status data.

Create examples/helloworld/files/sdk.sh with this complete content:

#!/bin/sh

. /usr/lib/functions

RETVAL=0
PROG=helloworld

start()
{
  ${PROG}
  return $?
}

stop()
{
  killproc ${PROG}
  RETVAL=$?
  return $RETVAL
}

restart()
{
  stop
  start
}

status()
{
  pidof -o %PPID ${PROG} >/dev/null 2>&1
  RETVAL=$?
  [ $RETVAL -eq 0 ] && echo ${PROG} is running || echo ${PROG} is stopped
  return $RETVAL
}

status_sync()
{
  return 0
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status
    ;;
  on_startup)
    start
    ;;
  on_link_up)
    stop
    start
    ;;
  on_link_down)
    stop
    ;;
  on_reboot)
    stop
    ;;
  status_sync)
    status_sync
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|status|on_startup|on_link_up|on_link_down|on_reboot|status_sync}"
    exit 2
esac

exit $?

The start handler invokes the program and returns its exit status. Its process-based status handler can report stopped after this one-shot program finishes.

Create examples/helloworld/Makefile on the host with this content:

include $(TOPDIR)/rules.mk

PKG_NAME:=helloworld
PKG_VERSION:=1.0
PKG_DESC:=helloworld example

PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)
PKG_UNPACK:=cp -rf src/* $(PKG_BUILD_DIR)
PKG_BUILD_PARALLEL:=1
PKG_BUILD_DEPENDS:=

include $(INCLUDE_DIR)/package.mk

define Package/Install
	$(INSTALL_DIR) $(1)/usr/bin/
	$(INSTALL_BIN) $(PKG_BUILD_DIR)/helloworld $(1)/usr/bin/
	$(INSTALL_DIR) $(1)/etc/sdk/
	$(INSTALL_BIN) files/sdk.sh $(1)/etc/sdk/$(PKG_NAME)
endef

$(eval $(call BuildPackage))

This places the executable at /usr/bin/helloworld and the lifecycle script at /etc/sdk/helloworld in the package's device filesystem. The source Makefile compiles the program; this package Makefile integrates it with the SDK packaging system.

Copy the files into the SDK

On the host, check that you will not overwrite an existing package:

docker exec -w /root/ROS-SDK "<SDK_CONTAINER>" sh -c "test ! -e package/helloworld"

Exit status zero means that the path is absent. If it exists, inspect it and keep any user changes before continuing. From the local folder containing your examples directory, copy the example on the host:

docker cp "./examples/helloworld" "<SDK_CONTAINER>:/root/ROS-SDK/package/"

Run the command where the Docker CLI is installed; container paths use forward slashes. Open the SDK shell again to inspect the copied files.

Build and export the installation package

Inside the container, from /root/ROS-SDK, run:

make package/helloworld/install

Check the exit status and build output. For the first build, confirm that the target compiler actually compiled helloworld.c and that packaging completed. A package left over from a previous attempt is not evidence that this build succeeded.

Find the resulting file inside the container:

find bin -type f -name '*helloworld*.rpk'

Match the result to the selected target and build output. Record its full container path. Create an output directory on your host using your file manager or terminal, then export the selected file from the host:

docker cp "<SDK_CONTAINER>:<ABSOLUTE_RPK_PATH_IN_CONTAINER>" "<EXISTING_HOST_OUTPUT_DIRECTORY>"

Check that the exported file exists and is non-empty. Calculate its SHA256 using the appropriate host command above and retain it with the build log, SDK image ID, and target. The RPK hash identifies this file; SDK 5.0.3 package timestamps can make rebuild hashes differ. The next steps verify it on a device.

Install and check the application on a development device

Check the device requirements

Confirm that the device model, variant, and firmware are compatible with the SDK target you used. Obtain access to its Web interface and check its application-signing requirements before uploading the package.

SDK 5.0.3 signs RPKs with its development key. An R1520 with RobustOS 5.6.0 accepted the sample without Developer Mode. Signing and installation requirements depend on the target firmware. Follow the dedicated signing and Developer Mode procedure for your device.

Building in the SDK container does not require a root login to the device. A device root shell, if needed for debugging, requires the applicable Robustel authorization and access setup.

Install and check the result

1. Open App Center in the device Web interface.
2. In App Install, use Choose File to select the exported RPK for this device, then select Install.
3. Check the installation result and the Installed Apps list for helloworld. Resolve any reported compatibility or signature error before proceeding.
4. Open System > Debug and look for a new hello world message from this installation or execution attempt. Note the time window so that you do not count a message from an earlier run.

Look for the message text hello world. The log prefix may include syslog:; timestamps and interface appearance depend on the device configuration and firmware.

If the package is installed but there is no new message, first determine whether the application ran and whether debug-level messages are visible. On a development device where you already have authorized shell access, you can explicitly invoke the installed example:

# Device shell
/etc/sdk/helloworld start

Then check for a new message in the Web interface or the device's /var/log/messages log. If the message is still absent, retain the command result, device firmware, target, and log settings for investigation. Do not change the example into a long-running process merely to make the status display say “running.”

Resolve common stopping points

You have completed the first-application path when the target C build succeeds, its RPK is exported, the matching device accepts it, and a new hello world message confirms execution.

Record your trial result

Keep the host OS and CPU, Docker version, SDK archive checksum, image ID, device target, build log, and exported RPK checksum together. Record environment/build success separately from device installation and execution.

If a step fails, note the command, execution location, exit status, and first relevant error. Include any extra instructions you needed from a colleague so that the workflow can be improved. Remove passwords, tokens and device credentials before sharing logs.

Related guidance

• Get started with the RobustOS SDK
• Debug a RobustOS SDK application