When To Use Orca, And Why Robotics Is The Sweet Spot

Orca was built for a specific shape of problem - continuous, window-oriented, algorithm-on-algorithm analytics over sensor data. Historically that shape has shown up most clearly in vibration, pressure and temperature analytics. Increasingly - and more interestingly - it is showing up in robotics telemetry, where Orca's design solves a set of problems that the rest of the robotics observability stack only addresses in parts.

This post walks through when to reach for Orca. It covers vibration, pressure and temperature data briefly because those are the well-trodden domains, and then spends the majority of its time on robotics - which is where I see Orca doing the heaviest lifting over the next few years.

Why Orca Exists

Before naming the domains, let's rack off the criteria. Orca earns its place when a workload has all of the following:

• Data that keeps arriving - there is no "end of dataset" to pin a schedule to.
• Analysis that is windowed - bounded regions of interest (an event, a shift, a task, a cycle) rather than one continuous stream-of-consciousness calculation.
• Algorithms that depend on other algorithms - condition indicators feeding deviation detectors feeding remaining useful life models.
• A need to tune availability against accuracy - sometimes wait for the full event, sometimes fire early with partial inputs.
• Multiple owners, multiple languages, or multiple sites that want to ship independently.

If a workload has any one of those, Orca is plausible. If it has three or more, Orca starts to pay for itself quickly. The Orca architecture overview describes the windowing model that makes this work, and the hub and spoke post argues why that topology beats a monolithic pipeline for this class of problem.

Vibration Data

Vibration is a really typical Orca workload, and the first that the toolboxes shipped against. A typical vibration pipeline has a high-rate raw signal (a few kHz to a few tens of kHz), a signal quality gate, a set of derived condition indicators (RMS, kurtosis, crest factor, spectral bin energies, order tracking), a deviation detector watching for distribution shifts, and eventually a remaining useful life projection.

Orca fits this cleanly. Each level of the pipeline is its own algorithm, each runs in its own window, and the dependencies are explicit: signal quality gates the indicators, indicators feed the deviation detector, the detector triggers remaining useful life. When the business wants earlier alerts the window schedule tightens; when it wants a reference calculation for an auditor the same processors run retrospectively over the archive. The analytics code does not change. That flexibility is the reason the toolboxes release can ship the same algorithms into both real-time and batch deployments.

Pressure And Flow Data

Pressure and flow can be treated similarly to vibration data. Use cases cluster around leak detection, compressor health, hydraulic system degradation, pump cavitation. The algorithmic stack looks similar: quality gating, derived indicators (rolling statistics, spectral content in the case of pulsating flow, slope and step features for leaks), deviation detection, and RUL where a failure mode is well-characterised enough to project.

Temperature Data

Temperature is the quiet workhorse of condition monitoring. Sample rates are lower (often sub-Hz), but the analytical patterns are still windowed, still dependent, and still benefit from the same pipeline: quality filtering, derived features (rate of change, time-above-threshold, thermal cycle counting), deviation from a learned baseline, and eventually a degradation model. Temperature on its own is rarely the whole picture (it is usually one input among several) but it is a workload that sits comfortably inside Orca.

The tradeoff story is slightly different here. Temperature analytics rarely needs sub-second latency, so a low-frequency windowing scheme is usually the right call - wait for the event, get the accurate answer, accept the delay. The fact that Orca lets a team express this with one line of window configuration rather than a rewrite is the value add of Orca.

---

The common thread across vibration, pressure and temperature is that they are single-modality problems. The stack is well understood, the algorithms are well known, and Orca's role is to stop teams rebuilding that stack from scratch. Robotics is different.

Robotics

Robotics telemetry has the properties above and then some. It is multi-modal, highly heterogeneous, fleet-scale from day one, and task-structured in a way that maps onto Orca's window model almost exactly. The rest of this post digs into that - what robotics telemetry actually looks like in production, what the current landscape does well, where it stops, and why the hub and spoke topology is the shape this problem wants.

What Robotics Telemetry Actually Looks Like

A modern robot - an industrial arm, a collaborative cobot, an AMR, a surgical manipulator, a humanoid (etc. etc. ...)- emits a catalogue of signals that is wider than most people outside the field appreciate:

• Per-joint servo data: commanded and actual position, velocity, motor current, motor temperature, and on richer platforms estimated or measured torque. Typical rates: 100 Hz to 1 kHz per joint, multiplied by six to twenty-plus joints.
• Inertial data: IMU streams (accelerometer, gyro, magnetometer) at hundreds of Hz to a few kHz.
• Force/torque sensing: at end-effectors or wrists, often at 1 kHz.
• Encoders: motor-side and link-side, often both on platforms with harmonic drives where dual-encoder torque estimation is used.
• Perception: camera frames, depth maps, LiDAR point clouds - much lower rate (10-60 Hz) but vastly higher bytes-per-sample.
• Control and planning signals: coordinate frames, planner outputs, trajectory execution status, lifecycle state.
• Events: task start and end, grasp success, error codes, fault latches, emergency stops.
• Mission context: pallet IDs, SKU, operator, bay, shift.

The cross-modal picture is what makes robotics telemetry its own thing. A single event, say, a screwdriving operation, draws on joint currents (to detect stall), force/torque (to confirm seating), vision (to confirm the screw head), planner state (to know the operation is in the screw phase) and mission context (to know what torque target applies to this SKU). Industry research is clear that modelling this well requires handling the spatiotemporal asynchrony between sensors and the different noise characteristics of each modality

• the raw streams cannot just be concatenated.

And it is not one robot. Production fleets are dozens to thousands of units, often from multiple vendors, often across multiple sites, often with mixed ROS 1, ROS 2 and vendor-proprietary middleware underneath.

What The Current Robotics Telemetry Stack Does Well

The robotics observability landscape in 2026 has matured substantially. Worth naming the pieces that are doing real work:

• MCAP and rosbag - MCAP has become the de facto open standard for multimodal robot logs, replacing the older rosbag formats and shipping by default with ROS 2 and NVIDIA Isaac. It solves the recording and replay problem very well.
• Visualisation and debugging tools - Foxglove has become the reference workstation for replaying MCAP data, scrubbing a timeline, visualising 3D scenes, camera frames, and timeseries panels together. It is excellent for human-in-the-loop debugging, and its recent Series B signals how much appetite there is for the category.
• Fleet-level observability SaaS - Sift pitches unified telemetry, simulation and ops data for robotic systems; RobotOps normalises telemetry across mixed-vendor robots with VDA 5050, ROS and vendor APIs; InOrbit aggregates telemetry across ROS 2, AMRs, manipulator arms and custom platforms with remote operation. Each of these is a serious product.
• Commodity time-series and metrics - Prometheus and Grafana are still the workhorses for anything that fits neatly into a scalar metric, and teams increasingly pair them with OpenTelemetry for tracing.
• Specialised maintenance research - there is a growing body of academic work on detecting faults from motor drive signals, unsupervised fault detection from joint current and anomaly detection in assembly, screwing and manipulation tasks. These are the algorithms that production fleets will be running in three years.

The picture that falls out of this is coherent but partial. The stack is good at recording, visualising and routing. It is weaker at orchestrating analytics over the recorded data, especially when those analytics are layered, windowed and span multiple modalities.

Where Robotics Telemetry Breaks The Common Tools

Four fault lines show up when a team tries to run serious analytics on robotics telemetry with general-purpose infrastructure.

The scalar assumption breaks immediately. Prometheus and most metrics-first observability tools assume a sparse scalar: one reading per (metric, label set) every 15 or 60 seconds. Robot joint current at 1 kHz per joint, twelve joints per arm, fifty arms on a line, is not a sparse scalar. It is a multi-channel signal, and the interesting analysis is spectral, temporal, and cross-channel. Shoving this through a metrics store is both expensive and lossy.

The bag-file workflow breaks at fleet scale. Recording everything to MCAP is the right move. But humans scrubbing through Foxglove is not scalable fault analysis - it is an excellent last mile. Somewhere between "here is an MCAP archive for every robot-hour ever worked" and "please investigate this failure" an automated analytics layer is doing the real triage. That layer is what Orca is.

The streaming framework tax is high for robotics. Robotics signals are bursty, event-shaped, and arrive over middleware that is not Kafka. Spinning up Flink or Beam just to express "when this grasp event fires, run these three algorithms over the previous 500 ms of wrist force and the next 100 ms of joint current, then feed the result into a deviation detector" is a lot of framework for not much value. The hub and spoke model of Orca expresses the same idea as a window definition plus three processors.

Fleet SaaS is opinionated where it should be open. The vendor-specific fleet dashboards are strong on visualisation and on their own algorithms, but most of them do not let an in-house signal processing team drop in a new fault detector written in Rust or a new RUL model written in Python and have it run consistently across the fleet. The analytics IP that a serious robotics operator builds over years needs a home that is theirs.

Why Orca Fits Robotics So Well

Now the positive case. The same properties that make Orca a fit for vibration analytics are amplified in robotics.

Tasks, cycles and grasps are natural windows. Robotics workloads are deeply task-structured. A pick-and-place cycle has phases: approach, contact, close, lift, move, release. Each phase has its own physics. A screw-drive operation has a seating phase, a run-down phase and a final torque phase. A traversal has an acceleration window, a cruise window, and a stopping window. These map directly onto Orca's Windowing pattern, with a parent window representing the full process and child windows representing sub-phase regions, with even more granular winodws specifying higher resolution events. That is, the same model described in the architecture overview. Teams that have tried to shoehorn this into a sliding-window streaming framework understand the pain.

Multi-modal fusion maps onto multi-algorithm. Orca gives each modality a natural home. A joint-current fault detector is one Algorithm. A wrist force/torque seating-check is another. A vision-based screw head classifier is a third. Each is written in the language that suits it - C++ for the tight inner loops, Python for the ML, Go for the integration glue. The orchestrator fuses their outputs by windowing them over the same task region. This is exactly what the multi-sensor fusion literature describes as the hard part of cross-modal analysis, and it happens to be exactly what Orca centralises in it's feature set.

Algorithm-on-algorithm fits the robot health stack. The research frontier for predictive maintenance on robots stacks neatly: raw motor current and encoder streams feed harmonic-drive torque estimation, torque estimates feed joint-level condition indicators, condition indicators feed deviation detection, and deviation feeds remaining useful life. Each stage is a distinct algorithm written by a distinct person on a distinct cadence.

Retrospective and real-time coexist. A robotics fleet wants both. Real-time: "this joint just spiked, flag it now". Retrospective: "re-run the new deviation detector across the last six months of MCAP archives to rebuild the training set". In a streaming-first framework these are two codebases. In Orca they are the same processors running under different window schedules. Pointing a replay of an MCAP archive at the same hub that runs live traffic is how a fleet operator builds a genuine regression test harness for an algorithm before rolling it to production.

Language agnosticism matches the reality of robotics teams. Robotics organisations are linguistically diverse almost by necessity. Controls and perception in C++. ML and data science in Python. Ops tooling in Go. The team that runs an AMR fleet often has vendor code they cannot rewrite. Because processors are containers that talk to the hub over a network contract, the stack each team prefers is the stack each team keeps.

Fleet heterogeneity is absorbed at the hub, not the processors. Mixed ROS 1, ROS 2, VDA 5050 and vendor telemetry is reality. The translation to Orca's window and sensor-stream abstractions lives at the ingestion edge. Once inside the hub, a joint-current anomaly detector does not care whether the signal came off a KUKA, a Fanuc, a UR, or an in-house manipulator. That is the same argument tools like RobotOps make for normalisation - Orca applies it to the analytics layer, not just the dashboard layer.

A Concrete Example: A Robot Screw-Drive Fault Pipeline

To ground this, imagine the pipeline a serious fleet operator wants for screw-driving on an assembly line. The structure is:

• Window A - the full screw-drive operation, triggered on the planner state transition "screwdrive start" and closed on "screwdrive end".
• Window B1 - the seating sub-window, the first 200 ms of Window A.
• Window B2 - the run-down sub-window, the middle portion of Window A.
• Window B3 - the final torque sub-window, the last 300 ms of Window A.
• Algorithms:
  • Signal quality on the motor current and force/torque streams, gating the rest.
  • A seating-success classifier on Window B1, combining wrist force and joint current.
  • A run-down torque-ripple detector on Window B2 from the motor current spectrum, cross-checked against expected harmonic-drive ripple.
  • A final-torque verifier on Window B3 that fuses measured torque, commanded torque and SKU context.
  • A deviation detector on the per-robot rolling distribution of final torque error, watching for drift.
  • A remaining useful life projection on the torque-ripple signal over the previous thousand cycles, per joint.

In Orca, each of those are algorithms, each of those windows is a window definition, and each of the dependencies is a DAG edge the orchestrator validates at registration. When the team wants to add a new vision-based screw-head classifier in six months, they ship a new algorithm that subscribes to Window B1 and emits a result - no pipeline rewrite, no scheduler change. Rolling the new algorithm to a single cell first, then a line, then the fleet, is a configuration change.

What The Landscape Looks Like Alongside Orca

Orca does not replace Foxglove, MCAP, or a fleet SaaS - it sits underneath them. A healthy robotics analytics stack in 2026 looks something like:

• Recording layer: MCAP files, captured per robot, streamed to object storage.
• Edge and transport: ROS 2 and vendor middleware on the robot; normalisation at the edge.
• Analytics orchestrator (Orca): windows, processors, dependencies, real-time plus retrospective.
• Visualisation (Foxglove): human debugging of specific MCAP archives, with Orca's results overlaid.
• Fleet operations (InOrbit / RobotOps / Sift): dashboards, task queues, remote operation.
• Metrics and tracing (Prometheus / OpenTelemetry): the infrastructure layer, not the signal layer.

The gap this taxonomy highlights is the analytics orchestration layer. Without it, teams either stuff signal-level analytics into metrics-first tools (where they do not belong) or into bespoke Python scripts running on cron (which do not scale beyond a handful of algorithms). The hub and spoke shape is how that layer stops being bespoke.

When Not To Reach For Orca

For completeness, the honest negatives. Orca is not the right tool when:

• The workload is a single scalar health metric per robot - a fleet dashboard and Prometheus is plenty.
• There is one robot and one algorithm - a Python script on the robot is simpler.
• The team does not control the analytics they want to run - if all roads lead to a vendor's proprietary algorithms, a SaaS fleet tool is the faster adoption path.
• The workload is a pure batch ETL over a data warehouse with no windowing concerns - use a workflow orchestrator.

The common thread of the negative cases is the absence of the criteria listed at the top of this post - no layering, no windowing, no availability-vs-accuracy tuning. When those are present, Orca's value compounds; when they are absent, it is overkill.

Getting Started

The architecture overview and mental model cover the windowing and dependency concepts in depth. The Quickstart Guide walks through defining windows and registering processors. The toolboxes release post describes the signal-level algorithms that ship as production-grade processors - they are as applicable to robot joint currents as they are to vibration sensors on rotating equipment.

Robotics telemetry is about to get much, much larger - every forecast on fleet growth points the same direction, and the observability industry's recent appetite for the category is not accidental. The teams that come out of the next decade with scalable robot analytics platforms will be the ones that separated orchestration from computation early and gave their analysts a DAG they could iterate on without rewriting the pipeline each time.