Reduct Bridge

ReductBridge bridges live robotics and IIoT data with long-term storage in ReductStore. You can configure the bridge using a simple TOML file to define inputs, pipelines, and remotes. Inputs produce data, pipelines route and modify it, and remotes store it.

Inputs

An input is a data source. It reads data from a system and produces records for the bridge.

Supported input types include:

• HTTP - poll HTTP/HTTPS endpoints on a fixed interval and store response payloads with optional JSON/header label mapping.
• Metrics - collect host CPU, memory, and disk metrics as JSON records.
• MQTT - subscribe to MQTT v3/v5 topics over mqtt:// or mqtts:// and store raw payloads with optional payload/property label mapping.
• Shell - run shell commands on a fixed interval and store output lines as records.
• ROS1 - subscribe to ROS1 topics, store ROS messages, and extract labels from message fields.
• ROS2 - subscribe to ROS2 topics, store serialized CDR payloads, and extract labels from decoded message fields.

Remotes

A remote is a data destination. It receives records from pipelines and writes them to external storage.

Supported remote types include:

• ReductStore - write pipeline records and attachments to ReductStore with configurable batching.

Pipelines

Pipelines connect one or more inputs to one remote.

# Pipeline definition path:
# [pipelines.<pipeline_name>]
[pipelines.telemetry]

# Required: remote name from [[remotes.*]].
remote = "local"

# Required: one or more input names from [inputs.*.*].
inputs = ["ros_local"]

# Optional label rules (default = []):
# 1) Static labels:
#    { static = { source = "robot" }, to = "*" }
#    - adds labels to matching target entries
# 2) Copy labels from one entry to another:
#    { from = "time", labels = ["timestamp"], to = "echo" }
#    - remembers labels seen on matching source entries
#    - applies them to matching target entries
labels = [
  { static = { source = "ros1" }, to = "*" }
]

Supported Formats

ReductBridge supports different payload formats. Support means ReductBridge can parse payloads, extract labels, and, when schema information is available, store that schema in ReductStore.

• JSON: find values by field path (example: examples/mqtt_config.toml).
• HTTP input: poll HTTP/HTTPS endpoints and extract optional header/JSON labels (example: examples/http_config.toml).
• Protobuf: find values by field path (with schema) or by field ID/type (example: examples/mqtt_protobuf_config.toml).
• ROS formats: decode ROS message payloads for labels and store the payloads as records (example: examples/ros_config.toml).

Installation

ReductBridge is published in build types named after Cargo feature bundles: ros1, ros2, and iot. Choose the build type for the input family you need.

Build Types

Published packages and Docker images are split into these build types so each artifact only includes the dependencies needed for its input family.

Note: ROS2 binary and Docker artifacts are published per ROS distribution: ros2-jazzy and ros2-humble. The ROS2 snap is published as reduct-bridge-ros2 and currently uses the Jazzy build.

Input names in configuration use their input table names, for example [inputs.ros.*], [inputs.ros2.*], [inputs.mqtt.*], [inputs.shell.*], and [inputs.metrics.*].

Docker

Docker images are published as reduct/bridge:<tag>, where <tag> combines a release channel or version with the build type. For ROS2 Docker images, use the ROS distribution-specific build type: ros2-jazzy or ros2-humble.

```bash docker pull reduct/bridge:main- # development builds from main docker pull reduct/bridge:latest- # stable builds docker pull reduct/bridge:v- # release builds

File truncated at 100 lines see the full file