Actions#

Overview#

Actions are the primary way to process, transform, and analyze data in Roboto. An action is a containerized function — packaged as a Docker image — that runs on Roboto’s managed compute infrastructure.

Actions ingest raw log files into Roboto’s data model and post-process that data after ingestion. An action can work with raw files downloaded from a dataset, or read already-ingested topic data as structured records without downloading the original files. Actions can also write results back to a dataset, add tags and metadata, and create events.

Actions range from simple scripts to sophisticated transformations. Roboto ships with a library of ready-to-use actions for common robotics workflows, and you can build and deploy your own.

The Action Hub#

The Action Hub is Roboto’s catalog of actions. It includes ingestion actions for ROS, PX4, Ardupilot, and other supported formats, along with analysis and utility actions.

Your organization’s deployed actions are available from the Actions page in the Roboto web UI.

Action lifecycle#

A typical workflow:

Develop — Write your action code and define its configuration in action.json. roboto actions init scaffolds a new action project.
Test locally — Use roboto actions invoke-local to run your action against real data without deploying.
Deploy — Build and push your Docker image, then register the action with your Roboto organization using roboto actions create or the generated deploy.sh script.
Invoke — Run the action on hosted compute, either manually or automatically via a trigger.
Monitor — Follow live logs and check invocation status as it runs.

See the Process Data with Actions user guide for a step-by-step walkthrough, or Create Your Own Action to build and deploy a custom action. Example actions are also available on GitHub.

Configuring an action#

Each action is defined by an action.json file that specifies its name, description, parameters, compute requirements, and more. See the Action Configuration reference for the complete schema.

Parameters customize an action’s behavior at invocation time without changing its code: for example, a signal threshold, a topic name, or an output format. Parameters can be required or optional and can have default values.

Compute requirements set the CPU, memory, and storage allocated to each invocation. See the Compute page for available options and how usage is measured.

Invocations#

An invocation is a single execution of an action. When an action is invoked, Roboto:

Provisions an isolated container with the requested compute resources.
Downloads input files into the container’s workspace (if requires_downloaded_inputs is enabled).
Runs the action’s entrypoint, passing in dataset context and any parameter values.
Streams container logs in real time.
Uploads any files written to the action’s output directory back to the dataset.
On exit, shuts down the container and records the final status.

Each invocation has a unique identifier prefixed with iv_.

To monitor an invocation:

# Check status
roboto invocations status <invocation_id>

# Stream live logs
roboto invocations logs --tail <invocation_id>

See the roboto invocations CLI for the full list of commands.

Triggers#

A trigger is a rule that automatically invokes an action when a specified condition is met. Triggers are the primary way to build automated data pipelines in Roboto. For example, you can ingest every log file as it is uploaded, or run a diagnostic action whenever a file finishes ingestion.

Trigger types#

Roboto supports two types of triggers:

Event-driven triggers fire in response to activity on your data. The event that prompts Roboto to evaluate a trigger is called its cause. Supported causes are:

File Uploaded — fires when a file is uploaded to a dataset.
File Ingested — fires when a file has been successfully ingested. Use this when your action reads ingested topic data rather than raw files.
Dataset Metadata Updated — fires when a dataset’s metadata, including tag additions or removals, or description change.
File Metadata Updated — fires when a file’s tags or metadata change.

Scheduled triggers fire on a recurring schedule defined by a cron expression, independent of any data activity. Use these for periodic reports, summaries, or other time-based workflows.

For-each mode#

For event-driven triggers, the --for-each option controls the unit of invocation:

dataset_file — the action is invoked once per matching file. Use this when your action processes individual files.
dataset — the action is invoked once per dataset (when any matching file arrives). Use this when your action operates on the dataset as a whole.

Required inputs#

The --required-inputs option specifies one or more glob patterns that files must match for the trigger to evaluate. For example, '**/*.bag' matches any .bag file in any subdirectory. Use '**/*' to match any file at any depth.

Conditions#

A trigger can also specify a condition that must hold before Roboto invokes the action. Roboto evaluates conditions against dataset or file properties. For example, a trigger can fire only when a dataset has a specific tag or a metadata field matches a given value.

For simple cases, use --required-tag or --required-metadata when creating a trigger:

# Only fire when a dataset has the "production" tag
roboto triggers create \
    --name ingest-on-upload \
    --action ros_ingestion \
    --required-inputs '**/*.bag' \
    --for-each dataset_file \
    --required-tag production

For more complex conditions, use --condition-json to pass a full condition expression.

Example: post-ingestion analysis#

A common pattern is to run an analysis action automatically after ingestion completes. Set up an event-driven trigger with the File Ingested cause, and the action can read topic data as a structured dataframe without downloading the raw log file.

Managing triggers#

roboto triggers search
roboto triggers get my-trigger
roboto triggers delete my-trigger

You can also create and manage triggers through the Roboto web UI. See the roboto triggers CLI for the full list of commands.