| **Layer** | **Technology** |
| Desktop framework | Tauri v2 |
| Frontend | SvelteKit + TypeScript |
| Backend | Rust |
| Build tool | Bun + Vite |
| Video streaming | GStreamer (MJPEG) |
| Rover communication | UDP on port 9000 |
| Serialisation | Protocol Buffers |
| 3D model rendering | (see [Model Viewer](https://bookstack.roboteamtwente.nl/link/149#bkmrk-page-title)) |
MacOS installation steps were not tested, proceed at your own risk!
### Rust Install Rust via rustup — the official Rust toolchain installer. **All platforms:** go to [https://rustup.rs](https://rustup.rs) and follow the instructions, or run: ```bash curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh ``` After installation, restart your terminal and verify: ```bash rustc --version cargo --version ``` ### Bun Bun is the JavaScript runtime and package manager used for the frontend.Using npm or yarn will **not** work with the current setup, there are scripts that specifically call for bun.
**Linux / macOS:** ```bash curl -fsSL https://bun.sh/install | bash ``` **Windows:** download the installer from [https://bun.sh](https://bun.sh) Verify: ```bash bun --version ``` ### Tauri CLI prerequisites Tauri requires some OS-level dependencies in addition to Rust. **Linux (Ubuntu/Debian):** ```bash sudo apt update sudo apt install libwebkit2gtk-4.1-dev libgtk-3-dev \ libayatana-appindicator3-dev librsvg2-dev patchelf ``` **Windows:** install the [Microsoft C++ Build Tools](https://visualstudio.microsoft.com/visual-cpp-build-tools/) and [WebView2](https://developer.microsoft.com/en-us/microsoft-edge/webview2/) (usually already present on Windows 10/11). **macOS:** ```bash xcode-select --install ``` ### GStreamer GStreamer handles video decoding and streaming. Version **1.22.x** is required to match the Rust crate versions (`gstreamer = "0.22"` maps to GStreamer 1.22). **Linux (Ubuntu/Debian):** ```bash sudo apt install \ libgstreamer1.0-dev \ libgstreamer-plugins-base1.0-dev \ libgstreamer-plugins-bad1.0-dev \ gstreamer1.0-plugins-base \ gstreamer1.0-plugins-good \ gstreamer1.0-plugins-bad \ gstreamer1.0-plugins-ugly \ gstreamer1.0-libav \ gstreamer1.0-tools ``` Verify: ```bash gst-launch-1.0 --version ``` **Windows:** 1. Download the **MSVC 64-bit** installer for GStreamer 1.22.x from [https://gstreamer.freedesktop.org/download/](https://gstreamer.freedesktop.org/download/) 2. Download both the **runtime** and **development** installers 3. Install both to the default path: `C:\gstreamer\1.0\msvc_x86_64\` 4. Add the GStreamer bin directory to your system PATH: ``` C:\gstreamer\1.0\msvc_x86_64\bin ``` Verify in a new terminal: ```bash gst-launch-1.0 --version ```The `GST_PLUGIN_PATH` environment variable is set automatically by the app at runtime (in `lib.rs`), so you do not need to set it manually.
**macOS:** ```bash brew install gstreamer gst-plugins-base gst-plugins-good \ gst-plugins-bad gst-plugins-ugly gst-libav ``` --- # Cloning the Repository**Before** cloning the repository, install the following tools on your machine.
The repository contains a Git submodule for the protobuf definitions. You must clone with `--recurse-submodules` or the `src-tauri/proto/` directory will be empty and the build will fail. ```bash git clone --recurse-submodules https://github.com/RoboTeamTwente/erc-software-basestation.git cd erc-software-basestation ``` If you already cloned without the flag, initialise the submodule manually: ```bash git submodule update --init --recursive ``` ### Keeping the submodule up to date When pulling changes that include submodule updates, always run: ```bash git pull git submodule update --recursive ``` If the proto definitions change and your build starts failing with protobuf-related errors, this is almost always the cause. ## Installing Frontend Dependencies ```bash bun install ``` This reads `package.json` and installs all SvelteKit, Threlte, and other frontend dependencies into `node_modules/`. Run this once after cloning and again whenever `package.json` changes. # Common Operations ## Running in Development ```bash bun run tauri dev ``` This command does the following in parallel: - Starts the Vite/SvelteKit dev server on `http://localhost:1420` - Compiles the Rust backend (first run takes several minutes) - Opens the Tauri application window The frontend supports hot module replacement — changes to `.svelte` and `.ts` files appear immediately without restarting. Rust changes require a recompile, which Tauri handles automatically but takes longer.**First build warning:** the initial `cargo build` downloads and compiles all Rust dependencies including GStreamer bindings. This can take 5–15 minutes depending on your machine. Subsequent builds are fast due to incremental compilation.
### Building for ProductionOne of Tauri's dependencies, libc (the C standard library), is forward compatible but not backward compatible
The demo laptop has an old verison of linux so you need to use docker to build the app if you want to use it in it. The first time you build you have to build docker first: ```bash sudo docker build -t tauri-ubuntu2204 . ``` For building the app in linux the subsequent times for the demo laptop use the command: ```bash sudo docker run --rm \ -v $(pwd):/app \ -v tauri-cargo-cache:/root/.cargo/registry \ tauri-ubuntu2204 ```You don't have to docker build every time, just the first time and if you change anything in the dockerfile
## Testing Without Rover Hardware You do not need a physical rover to develop or test the UI. The backend includes a full simulator. #### Video Feeds **Fake camera** `fake_camera_gstreamer/` — a GStreamer-based test source that sends H.264 RTP streams on the expected UDP ports (4500, 4501, 4502). It can be run from by running the following command from `erc-software-basestation/fake_camera_gstreamer/` ```bash cargo run --bin fake_camera_gstreamer ``` **Stream from Webcam** To test the video feed with your webcam open a terminal and use the following command. Linux ```bash gst-launch-1.0 v4l2src ! videoconvert ! x264enc tune=zerolatency bitrate=800 speed-preset=ultrafast ! rtph264pay ! udpsink host=127.0.0.1 port=4500 ``` Windows ```bash gst-launch-1.0 ksvideosrc ! videoconvert ! x264enc tune=zerolatency bitrate=800 speed-preset=ultrafast ! rtph264pay ! udpsink host=127.0.0.1 port=4500 ``` #### Dummy data streams (rover telemetry) Once the app is running, go to `/settings` and use the simulator controls: - **Start dummy general stream** — starts the full multi-stream simulator sending fake IMU, GPS, arm, drive, and sensor data to the app over UDP. Use this to test all telemetry UI at once. - **Start dummy IMU stream** — starts an IMU-only stream with no jitter or packet loss. Use this for isolated IMU component testing. - **Stop dummy general/IMU stream** — stops whichever simulator is running. The simulator runs inside the Rust backend so it works regardless of whether a rover is connected. ## Connecting to the Rover**TODO**
The base station listens for incoming UDP packets on the address set on lib.rs, must set static address in laptop settings # Common Issues **Build fails with "No valid proto files found under components/"** The proto submodule is not initialised. Run `git submodule update --init --recursive`. **GStreamer errors at startup on Linux** Verify the plugin path exists: `/usr/lib/x86_64-linux-gnu/gstreamer-1.0`. If your system uses a different architecture or distro the path in `lib.rs` may need updating. **GStreamer errors at startup on Windows** Verify GStreamer is installed to exactly `C:\gstreamer\1.0\msvc_x86_64\` and that the `bin` directory is in your PATH. **Video feeds show "SIGNAL LOST"** No camera is sending data on the expected UDP ports. Start `fake_camera_gstreamer` or connect the rover to get video. **White/blank window on launch** The SvelteKit dev server may not have started yet. Wait a few seconds and the window should load. If it persists, check the terminal for Vite errors. **Model shows "Failed to load 3D model"** In development, models are loaded from `src-tauri/models/`. Verify that `chibiRover.glb` (or your model file) exists there. In production builds, run `debug_resource_dir` from the Settings page to check where Tauri is looking. **"\[Error\] Unhandled Promise Rejection: ReferenceError: Cannot access uninitialized variable."** Seems like a circular import error, check the name of the files, some require odd names such as `detected_objects.svelte.ts`. If you remove the .svelte it will error out oddly. # Backend — Application Entry Point & Build System Location: src-tauri/src/ and src/ # main.rs — Binary Entry Point The binary entry point is intentionally minimal. It simply calls `base_station_lib::run()`, which lives in `lib.rs`. The only thing of note is the `windows_subsystem = "windows"` attribute on the first line — this suppresses the extra console window that would otherwise appear when launching the app on Windows in release builds. Do not remove it. # lib.rs — Application Bootstrap `lib.rs` is where the entire Tauri application is configured and started. It does the following in order: ### Managed state registration Three pieces of state are registered with Tauri's state manager so they can be injected into any command via `State<'_>`: - `RoverState` — the three rover mode booleans (`drive_manual_mode`, `arm_manual_mode`, `pickup_mode`), all wrapped in `Mutex` so they are safe to read and write from async commands - `DummyStreamHandle` — holds an optional cancellation flag for the dummy simulator - `RoverAddress` — holds the port the Rover is sending to`RoverState` is subject to change, because the rover might become able to drive and move the arm at the same time
### Plugin registration Three official Tauri plugins are loaded:| **Plugin** | **Purpose** |
|---|---|
| `tauri-plugin-fs` | File system access from the frontend |
| `tauri-plugin-opener` | Open files/URLs in the OS default application |
| `tauri-plugin-dialog` | Native file picker and dialog boxes |
AI will often try to get you to add them to `tauri.conf.json` but that is, as far as I have encountered if, incorrect
### Command registration All Tauri commands are registered here via `tauri::generate_handler!`. This is the complete list of commands callable from the frontend via `invoke()`. If you add a new command in any `commands/` file, it must also be added here or it will not be accessible from the frontend. ### Setup (startup sequence) The `.setup()` closure runs once at launch, before any window is shown. It performs these steps in order: **a) GStreamer plugin path** Sets the `GST_PLUGIN_PATH` environment variable so GStreamer can find its plugins on Windows. It will look for them at `C:\gstreamer\1.0\msvc_x86_64\bin`. On Linux it can find the plugins automatically. **b) Storage directory creation** Calls `ensure_storage_dirs_internal()` to create the `tasks/`, `images/`, and `maps/` subdirectories under the app data directory if they don't already exist. **c) Cache clearing** Calls `clear_cache_on_startup()` to wipe any stale cached files from the previous session. **d) GStreamer streaming server** Spawns an async task that runs `commands::gstreamer::stream()` for the lifetime of the app. This starts the three GStreamer pipelines and their corresponding MJPEG HTTP servers. **e) UDP service** Creates `UdpService` (binding `0.0.0.0:9000`) synchronously using `block_on`. The socket is extracted before the service is moved into Tauri's state manager, so it can be passed to the listener independently. **f) UDP listener** Spawns an async task running `network::listener::run_listener()` with the shared socket. This is the loop that receives, decodes, and forwards all incoming rover packets to the frontend. **g) Controller listener** Calls `commands::controller::start_controller_listener()`, which spawns an OS thread to poll for gamepad events. # proto.rs — Protobuf Module This file simply includes the generated Rust code for the `packets` protobuf module: rust ```rust pub mod packets { include!(concat!(env!("OUT_DIR"), "/packets.rs")); } ``` The actual `.proto` source files live in `src-tauri/proto/`. They are compiled at build time by `build.rs` into `packets.rs` in the Cargo `OUT_DIR`. Importing `crate::proto::packets::*` in any Rust file gives access to all the generated message structs. # build.rs — Protobuf Compilation The build script runs before the Rust compiler and is responsible for compiling all `.proto` files into Rust code. It does this in several steps: **1. Collect proto files** Recursively scans the `src-tauri/proto/` directory for `.proto` files. Only files that are inside a `components/` subdirectory are included — this is a deliberate filter to exclude top-level or organisational proto files. **2. Patch proto files** Each `.proto` file is copied to inside `src-tauri/generated_proto` and patched to inject `package packets;` after the line `syntax = "proto3"`;. This ensures all generated types end up in a single `packets` Rust module, regardless of how the source `.proto` files are organised. The patching is idempotent — it won't inject the package line twice if it is already present.This means that the basestation **protobufers are** slightly **different** from the ones embeded and jonny boi (the jestson) uses. Keep this in mind for debugging
**3. Compile** - Using **prost** for backend. The patched files are compiled for backend (stored in `src-tauri/target/debug/build/base_station-0f99f7e026ffb091/out/packets.rs`) using `prost_build`. A type attribute is applied globally: ```rust config.type_attribute(".", "#[derive(serde::Serialize)]"); ``` - Using the plugin **protoc-gen-ts** for frontend. The patched files are compiled for frontend (stored in `src/lib/proto`) This means every generated message struct and enum automatically derives `serde::Serialize`, so they can be passed directly as Tauri event payloads without any manual wrapper types. **4. protoc** The `protoc` compiler binary is sourced from `protoc-bin-vendored`, so no system installation of `protoc` is required.If you add new `.proto` files, place them inside a `components/` subdirectory under `src-tauri/proto/` and they will be picked up automatically on the next build.
If you add new protobufers you must explicitly commit and push them into the github submodule, they will **NOT** sync automatically when you sync the repo.
# tauri.conf.json — Application & Security Configuration ### Window The app opens a single window titled `base_station` at 800×600. `devtools` is enabled, meaning the browser DevTools can be opened in development builds. ### Content Security Policy The CSP is configured to be strict by default while allowing the specific localhost ports needed for video:| Directive | What it allows |
|---|---|
| `default-src` | Only the app itself and Tauri's custom protocol |
| `script-src` | Self + inline scripts (required by SvelteKit) |
| `img-src` | App assets + the three MJPEG stream ports (5000, 5001, 5002) |
| `media-src` | The three MJPEG stream ports |
| `connect-src` | All localhost ports (for dev server, WebSockets) + `api.ipify.org` |
**For future developers:** Security gives a lot of problems (and they vary between devices and platforms), if something isn't loading always check if it is because of permissions. Thus far setting security to unrestricted does not fix those issues.
### Bundled resources The `models/*` glob in `bundle.resources` ensures all 3D model files in `src-tauri/models/` are included in the packaged application. This is what `load_model.rs` reads from in release builds. # Cargo.toml — Key Dependencies| **Crate** | **Purpose** |
|---|---|
| `tauri` | Desktop app framework, with `protocol-asset` and `devtools` features |
| `tokio` (full) | Async runtime for all network and I/O tasks |
| `prost` | Protobuf encode/decode |
| `gstreamer` / `gstreamer-app` | Video pipeline |
| `warp` | MJPEG HTTP server |
| `gilrs` | Gamepad/controller input |
| `reqwest` (blocking) | HTTP client used to capture video snapshots |
| `serde` / ` serde_json` | Serialisation for Tauri events and commands |
| `anyhow` | Ergonomic error handling across async code |
| `dirs` | Cross-platform system directory paths (cache dir) |
| `chrono` | Date/time (available for timestamps) |
| `bytes` | Zero-copy byte buffer for GStreamer frame sharing |
| `once_cell` | Handling threads of dummy data |
| `rand` | For generating random numbers (for dummy data) |
| `socket2` | For creating a socket with custom options |
| `tobj` | For handling maps with .obj format |
| `las` | For handling maps with .las format |
| `nalgebra` | For handling the computing the height map |
The state described here MIGHT be subject to change
Manages the three global boolean flags that track the rover's current operating mode. The state is held in a `RoverState` struct registered as Tauri managed state (initialised in `lib.rs`), so it persists for the lifetime of the application. ### State fields| **State** | **Default** | **Description** |
| `drive_manual_mode` | `true` | Whether the rover driving is in manual control |
| `arm_manual_mode` | `true` | Whether the arm is in manual control |
| `pickup_mode` | `false` | Whether the rover is in driving or pickup mode |
| **Directory** | **Purpose** |
| `tasks/` | Saved task plan files |
| `images/` | Snapshots captured from video feeds |
| `maps/` | Imported map files |
| **UDP input port** | **HTTP output port** | **Camera** |
| 4500 | 5000 | Depth / front camera |
| 4501 | 5001 | Secondary camera |
| 4502 | 5002 | Arm camera |
**For development without rover hardware**, run the `fake_camera_gstreamer`. For instructions see [Common Operations](https://bookstack.roboteamtwente.nl/link/159#bkmrk-video-feeds).
# network.rs — UDP & Dummy SimulatorThis file is work in progress
Exposes commands related to the UDP connection and the development simulator. ### Commands **`send_ping_cmd(packet_type)`** Intended to send a ping packet to the rover over UDP. Currently logs to console — full implementation pending. **`start_dummy_streams()`** Starts the full multi-stream simulator. Sends fake protobuf packets to `127.0.0.1:9000` mimicking live rover data. Useful for UI development without hardware. Simulator config: - Jitter: 30ms - Simulated packet loss: 2% **`start_detection_sim()` Starts a single stream for the detection object stream dummy data. **`stop_dummy_streams()`** Signals the running simulator to stop by setting a shared cancellation flag. The `DummyStreamHandle` struct (managed Tauri state) holds the cancellation handle so any command can stop the simulator. # controller.rs — Gamepad Input Runs a background listener for gamepad input using the `gilrs` library, translating button and axis events into UDP packets sent to the rover. All dispatching is gated on the current mode (drive vs. pickup) and whether the relevant manual mode is active. ### Modes The controller operates in one of two top-level modes, toggled with the **Start** button:| Mode | Active when | Controls |
|---|---|---|
| Drive | `pickup_mode = false` | Left stick (forward/turn), triggers (brake) |
| Pickup | `pickup_mode = true` | Both sticks (X/Y/rotate/flick), D-pad (Z), triggers (gripper) |
| Button | Drive mode | Pickup mode |
|---|---|---|
| Start | Toggle pickup mode | Toggle pickup mode |
| Select | Toggle `drive_manual_mode` | Toggle `arm_manual_mode` |
| Left trigger (LB) | Toggle latching brake | Ramp gripper speed → close (−1.0) |
| Right trigger (RB) | — | Ramp gripper speed → open (+1.0) |
| Left trigger 2 (LT) | Toggle latching brake | — |
| Right trigger 2 (RT) | Momentary brake (hold) | — |
| D-pad up | — | Ramp Z → up (+1.0) |
| D-pad down | — | Ramp Z → down (−1.0) |
| Axis | Drive mode | Pickup mode |
|---|---|---|
| Left stick Y | Forward / backward | Flick |
| Left stick X | Turn | Rotate |
| Right stick X | — | End effector X (left/right) |
| Right stick Y | — | End effector Y (forward/backward) |
| Packet | When |
|---|---|
| `BasestationManualDrive` | Drive mode, on axis change or heartbeat |
| `BasestationManualBrake` | Drive mode, on brake toggle/press/release or heartbeat; also sent continuously (engaged) during pickup heartbeat |
| `BasestationManualArmMovement` | Pickup mode, on any arm state change or heartbeat |
| Constant | Value | Purpose |
|---|---|---|
| `AXIS_CHANGE_THRESHOLD` | `0.05` | Deadzone boundary and minimum delta before a packet is sent |
| `HEARTBEAT_INTERVAL` | `2 s` | How often state is re-sent without an input event |
| `RAMP_DURATION_SECS` | `1.0 s` | Time for a ramped axis to travel from `0.0` to `±1.0` |
| `RAMP_TICK_MS` | `16 ms` | Ramp thread tick interval (~60 Hz) |
| `MOMENTARY_BRAKE_DURATION` | `500 ms` | Defined but unused — auto-release was commented out |
**Note for future developers:** Clearing the cache on startup is necessary, without doing so the video feed and other assets will not load in some devices.
# load_model.rs — 3D Model Loading Handles loading of 3D model files bundled with the application. **`load_model(path) → Vec**Note for future developers:** Webview technically do this automatically from the frontend but it errors out so the custom function is necessary.
# rover_commands.rs — Rover Science CommandsThis file is work in progress
These commands are called by the frontend to request measurements or send data to the rover. All four are currently partially stubbed — they simulate a 1-second rover response delay and return dummy values, but the actual UDP dispatch logic is ready to be wired in. **`request_coordinates() → (i16, i16)`** Requests the rover's current GPS coordinates. Returns a `(latitude, longitude)` tuple. **`request_weight() → i16`** Requests the weight of a collected rock sample from the rover's load cell. Returns a weight value in grams. **`request_measurement(camera1, x1, y1, camera2, x2, y2) → i16`** Requests a stereo distance measurement. The frontend passes two pixel coordinates (one per camera) and the rover computes the real-world distance to that point. Returns the distance in a unit TBD. **`send_pixel(camera, x, y)`** Sends a single pixel coordinate from the frontend to the rover (e.g. operator clicking on an object in the video feed). Used to direct the rover's attention or arm toward a specific point in the image. # map_commands.rs and map_processor.rs — 3D Map Rendering & Coordinate Transforms **`map_processor.rs` + `map_commands.rs` — 3D Map Rendering & Coordinate Transforms** Converts 3D map files into top-down orthographic PNG images coloured by height (Z), and exposes coordinate transforms so the frontend can convert pixel clicks back to real-world metres. The pipeline runs on a blocking thread to avoid stalling the async runtime. ### Supported formats| Extension | Library | Notes |
|---|---|---|
| `.obj` | `tobj` | OBJ Y-up convention remapped: world X = OBJ X, world Y = OBJ Z, height = OBJ Y |
| `.las` | `las` | X/Y/Z read directly from point records |
| `.laz` | `las` | Same as LAS (compressed) |
| Field | Type | Description |
|---|---|---|
| `img_width` | `u32` | PNG width in pixels (post-rotation) |
| `img_height` | `u32` | PNG height in pixels (post-rotation) |
| `world_x_min` | `f64` | Real-world X at the left edge (currently always `0.0` ) |
| `world_y_min` | `f64` | Real-world Y at the bottom edge (currently always `0.0` ) |
| `metres_per_pixel` | `f64` | Scale factor for pixel→world conversion |
| `format` | `String` | Source format detected ( `"obj"` , `"las"` , `"laz"` ) |
| `rotated` | `bool` | `true` if the image was rotated 90° to landscape |
| Normalised Z | Colour |
|---|---|
| 0.0 | Deep blue |
| 0.25 | Cyan |
| 0.5 | Green |
| 0.75 | Yellow |
| 1.0 | Red |
| Condition | Error returned |
|---|---|
| Unsupported file extension | `"Unsupported format: .{ext}"` |
| File parsed but empty | `"File parsed but contained no points."` |
| All points collinear in X or Y | `"All points are collinear — cannot build a 2D map."` |
| Source file missing at invoke time | `"File not found: {path}"` |
| PNG write failure | `"Failed to save PNG: {e}"` |
Graph subject to change as communication gets finalized
[](https://bookstack.roboteamtwente.nl/uploads/images/gallery/2026-04/scaled-1680-/basestationcoms.png) # service.rs — UDP Socket `UdpService` is a thin wrapper that binds a UDP socket and holds it in an `Arc`socket2` allows to customize the socket, otherwise the buffer size will be set by the system and be too small
# listener.rs — Incoming Packet Handler `run_listener()` is the main receive loop. It runs for the lifetime of the app as a spawned async task. On every received UDP datagram it: 1. Decodes the raw bytes as a `PbEnvelope` using prost 2. Extracts the inner payload variant 3. Checks a per-payload **throttle** — events are forwarded to the frontend at most once every **100ms** per payload type, regardless of how fast the rover sends 4. Emits a Tauri event to the frontend with the decoded message as the payload ### Throttling Each payload type has its own independent `Throttle` instance. This prevents high-frequency streams (e.g. IMU at 50Hz) from flooding the frontend with more updates than it can usefully render. ### Tauri events emitted These are the event names the frontend can listen to with `listen()`:**Note for future developers:** If you add new protobufers you must add them here or you want be able to listen to them
# sender.rs — Outgoing Packet SenderThis file is work in progress
`send_envelope()` is the single outgoing send function. It takes a `PbEnvelope`, encodes it to bytes using prost, and sends it to the target address over UDP. A `hex_dump()` helper (currently commented out) can be re-enabled to log outgoing packet bytes for debugging. Usage pattern in any command: ```rust sender::send_envelope(&socket, "192.168.1.x:9000", envelope).await?; ``` # dummy.rs — Development Simulator The simulator generates realistic fake rover data so the UI can be developed and tested without physical hardware. It is started via the `start_dummy_streams` or `start_detection_sim` commands from `network.rs` and stopped with `stop_dummy_streams`. ### Stream table Each stream has an independent send interval and a generator function that produces time-varying data:| **Stream** | **Interval** | **Notes** |
|---|---|---|
| IMU | 20ms (50Hz) | Sinusoidal accelerometer, gyro, magnetometer |
| GPS | 200ms | Slow position drift around a fixed coordinate (52.2297°N, 6.8978°E) |
| pH | 500ms | pH value oscillating around 7.0 |
| Arm control signals | 50ms | Simulated joint control inputs |
| Arm diagnostics | 500ms | 6 motors with dummy RPM/voltage |
| Arm feedback | 100ms | Occasionally simulates an obstruction error |
| Arm positions | 50ms | All joint angles oscillating |
| Arm target | 200ms | Target XYZ + jaw state |
| Arm obstructions | 300ms | |
| Drive diagnostics | 500ms | 6 drive + 4 steering motors |
| Drive motor | 50ms | Distance to go, turning radius |
| Drive progress | 100ms | Countdown from 10m |
| Sensor board diagnostics | 500ms | Composite board health snapshot |
| Detected objects | 50ms | Generates up to 12 bounding boxes for objects |