Use this guide to identify the inputs for a RobustOS application before you build it. You will distinguish the development computer, SDK workspace and device, then choose the parts of the SDK that your application needs.

Applies to: C, C++ and Linux shell application development for RobustOS Devices with a matching SDK release and confirmed build target. Device capabilities and firmware compatibility depend on the exact model and hardware variant.

Start with a specific device and SDK release

An application is built for a device target. A product family name alone does not identify its CPU architecture, toolchain or compatible firmware.

Record these inputs for your project:

Input	What to record
Device	Exact model and hardware variant, plus the firmware used for testing
SDK	Archive name and checksum, release information, image identity and confirmed build target
Development environment	Host OS and CPU, container runtime and the environment where compilation runs
Application	Package name, source revision and required services or physical interfaces

Obtain the SDK and target mapping from your SDK distributor or the RobustOS SDK entry page. Check that the supplied release covers your device before starting the build. A device listed on the entry page does not by itself identify the correct archive or target.

For example, the SDK examples use r3000 for R3000 and r5010a for R5010. These are explicit target names; they are not a rule for converting other model names into targets.

Keep the SDK package version, device firmware version, application version and documentation revision separate. Matching numbers are not evidence of compatibility.

Distinguish the three execution environments

Environment	Work performed there
Development host	Edit source, operate Docker, retain source control and collect exported installation packages
SDK container	Select the target, compile with its toolchain and package the application
RobustOS Device	Install the package, run the application and inspect its interaction with device services and hardware

The setup guide uses /root/ROS-SDK as the SDK workspace inside the container. A path beginning with /root/ROS-SDK/package/ is therefore a build path. Paths such as /usr/bin/helloworld and /etc/sdk/helloworld describe the installed files on the device.

Use the SDK target compiler for the device build. A successful desktop build can help you test portable logic, but it does not check the device ABI, libraries, paths, privileges or hardware.

Understand the software layers

Your application uses the SDK libraries and application framework to interact with RobustOS services. The Linux kernel provides the underlying operating-system and driver layer.

The diagram is a conceptual view. It does not promise that every component or interface is available on every device.

Layer	What it means for your application
Applications	Your packaged program and the device's existing services run here
Application framework	Configuration, device status, messages, logs and events connect applications to RobustOS services
Libraries	The target's C library and SDK libraries provide callable interfaces
Linux kernel	Device drivers and operating-system facilities provide access to supported hardware

The C library is glibc. Use the version and headers supplied with your target SDK; do not replace them with desktop system headers or assume a fixed library version across releases.

Choose your editor for its ability to preserve plain text, LF line endings and Makefile tabs. The editor does not determine the target toolchain. C++ applications also need the matching C++ runtime; see Build and package RobustOS SDK applications.

Read the component examples

The Applications layer includes examples such as init, Link Management, Modem Service, clish, Web-Server, dnsmasq, GPS and OpenVPN. sample_modbus and sample_uci are sample components. The arrow illustrates the relationship between Link Management and Modem Service.

The Application Framework names the Unified Configuration Interface, Router Environment Variable, Router Message, Log Manager and Event Manager. The Library layer includes examples such as glibc, libxml2, libevent, librouter, openssl and libmodbus. The Linux Kernel layer includes the file system and drivers for modem, Wi-Fi, RS232/RS485 and flash.

These names explain the diagram. Check the supplied target SDK and device before selecting a component or library for an application.

Choose the interface for your task

Task	Start here
Build and install a small application	Environment preparation and first application
Let an AI prepare the development workspace	AI setup runbook
Expose settings or current status in the Web interface	Configuration, status and Web pages
Read or change configured values	UCI configuration API
Publish or query runtime status	USI status API
Write logs, access environment values, exchange IPC messages or subscribe to events	System, messaging and event APIs
Use a serial port, digital/analog I/O, BLE or notification services	Hardware and system services
Add build dependencies or customize package creation	Build and package applications
Supervise a long-running application process	Manage services with agd
Accept a file through an application page	Web file upload
Investigate an application failure	Debug an SDK application
Prepare an application package for deployment	Sign and deploy SDK packages

UCI is the configuration interface: it describes settings that users or applications change. USI is the status interface: it exposes the state reported by the device or an application. A status value does not become a configuration setting merely because both interfaces use dotted tags.

Use device paths only after checking the exact hardware variant. The presence of a path in a sample is not a specification for electrical wiring, serial settings or analog scaling.

Establish resource and dependency limits

Review hardware platforms and SDK resources for model-by-model CPU, device capacity and application-resource profiles, with a method for shortlisting hardware for your workload.

Before adding a library or background service, obtain the flash and RAM budget for your device and firmware. Account for the application, its runtime libraries, uploaded files and its peak memory use. Check the actual device during testing; nominal device capacity and space available for an SDK application are different quantities.

Select dependencies from the supplied SDK package tree. Confirm their target architecture and installed paths. A library listed in historical release material is not proof that it is installed on your test device.

Keep your project source outside the container as well as in its working volume. Record the SDK image and target beside each exported package so another developer can reproduce the build.

Check that you are ready to proceed

You are ready for environment preparation when you can identify the exact SDK archive and target, the intended build environment, the device used for testing and the services your application requires. If the target or firmware mapping is missing, obtain that mapping before choosing commands from an example for a different device.

At the end of the first-application guide, you should have a package from a successful target C build and a fresh device log showing execution. The other SDK guides extend that known starting point.