Measure Robot Cycle Time Without Hiding Waits and Failures

Define which cycle you mean

Write the measurement question before starting a stopwatch. Robot motion duration, request-to-completion latency, and time between accepted parts are different quantities. Choose observable events for each and state where they are detected. A robot can finish its path while downstream equipment remains busy, and a part can reach a station before its job request is accepted. A label such as cycle time is incomplete until those boundaries are explicit.

Use a measurement contract containing start event, end event, clock, units, outcome rule, and exclusions. The manufacturer example used here is Universal Robots' RTDE documentation under SW10.10, checked September 5, 2026. It describes access to controller status and I/O data, but it does not define your production cycle. Confirm interface availability and fields against the actual controller version. Your process owner must decide which events correspond to a completed, acceptable result.

References: Real-Time Data Exchange, official SW10.10 documentation

Map the event sequence before collecting numbers

Draw or list the meaningful transitions: work available, request accepted, motion started, process confirmation received, result transferred, and station ready again. Associate each event with its producer and identify events that can overlap. This reveals whether an apparent robot delay is actually a wait for upstream presentation or downstream acceptance. Preserve transaction identity so events from neighboring jobs cannot be combined into an implausibly short or long duration.

Record both the event and the condition supporting it. A gripper command is not equivalent to confirmed acquisition, and program completion is not automatically a quality acceptance event. Universal Robots' SW5.21 I/O Setup page describes signals linked to program state; treat those as controller observations whose process meaning must be established locally. Keep missing or contradictory events visible in the analysis. Silently substituting a convenient timestamp changes the question being measured.

References: I/O Setup, PolyScope SW5.21

Understand clocks and sampling limits

Prefer elapsed durations measured within a common clock domain. If events originate on different devices, document their synchronization method and uncertainty before subtracting timestamps. A PC receive time includes transport and scheduling effects, while a controller timestamp may use a different origin. The cited RTDE page defines its timestamp relative to controller startup and warns that output packages can be skipped under load. Do not count received packets as a guaranteed timebase.

Consider a hypothetical logger that observes state every 100 milliseconds. If a transition occurs between observations, the exact transition time is bounded by those observations, not known to arbitrary decimal precision. A pulse shorter than the observation interval might be missed entirely. These numbers illustrate sampling, not a product's capability. Select an approved event-capture method appropriate to the decision, record gaps, and avoid asserting an improvement smaller than the measurement uncertainty. Recheck instrumentation if the required decision becomes more precise.

References: Real-Time Data Exchange, official SW10.10 documentation

Choose instrumentation that answers the question

A process event log can explain handshake waits; controller telemetry can contextualize motion and program state; a software trace can investigate internal execution. Select the smallest useful evidence set that covers the suspected delay. The official ROS 2 Jazzy recording tutorial explains message recording and inspection, while its tracing tutorial demonstrates analysis of callback durations. A callback duration measures software execution, not the complete time from a physical stimulus to an accepted part.

For a ROS-based cell, decide which message and application events connect those layers. Record the relevant software revision, topic or event definitions, timestamp provenance, and logging configuration. Inspect a pilot record before collecting a long run. Check whether instrumentation materially changes the workload, and disclose any limitation that cannot be removed. Perform analysis and playback in an isolated environment unless physical interaction has been specifically approved by the responsible integration team.

References: Recording and playing back data, official ROS 2 Jazzy documentation source · How to use ros2_tracing to trace and analyze an application, official Jazzy documentation source

Collect representative attempts and retain outcomes

Define the collection window and starting conditions before looking at the results. Record task variant, program revision, tool setup, relevant speed settings, supply conditions, and whether the run followed startup or an established operating period. Separate changed conditions rather than blending them into one attractive average. Decide in advance how interrupted, invalid, and unsuccessful attempts will be labeled, including the reason an attempt does not belong in a particular duration comparison.

Retain all attempts in the master record. You can report successful-cycle duration alongside failure count and recovery time without pretending they are the same measure. For throughput, use accepted output over the declared elapsed window, with downtime treatment stated. Do not remove slow observations solely because they are inconvenient. Investigate whether they represent a different process condition, a measurement defect, or real variability that the next improvement must address. Capture enough context that another reviewer can distinguish those explanations.

References: Real-Time Data Exchange, official SW10.10 documentation · Recording and playing back data, official ROS 2 Jazzy documentation source

Worked hypothetical example: motion is only part of the cycle

Suppose an invented serial process spends 3 seconds waiting for a part, 8 seconds moving and performing the task, and 4 seconds waiting for downstream acceptance. With these non-overlapping assumptions, request-to-ready time is 15 seconds. Reducing the middle segment to 7 seconds produces a 14-second total, saving 1 second or about 6.7 percent. It does not produce the 12.5 percent overall improvement suggested by considering the middle segment alone.

Now suppose preparation for the next part overlaps the current task. You can no longer add all segment durations to predict the interval between completed parts; identify the limiting resource and measure output intervals directly. Also consider a hypothetical observation window of 600 seconds yielding 30 accepted parts. Its observed rate is 3 accepted parts per minute, regardless of a selected fast-cycle clip. These calculations are illustrative arithmetic, not measurements of a robot or promises of achievable performance.

References: Real-Time Data Exchange, official SW10.10 documentation · How to use ros2_tracing to trace and analyze an application, official Jazzy documentation source

Compare distributions and causes, not just averages

Report the number of attempts, successful outcomes, median duration, and an appropriate view of the slower observations. Explain your percentile calculation when using one, and avoid treating a small sample's tail estimate as a firm guarantee. Break results down by meaningful conditions if the process mixes task variants. Preserve the underlying event records so a reviewer can reproduce the calculation and check the treatment of missing or failed attempts.

Investigate delay categories before proposing motion changes. If variability appears between an image arriving and its result being published, software tracing may help distinguish callback work from scheduling or other intervals, depending on the available trace events. Jazzy's tracing example specifically analyzes callback durations; do not infer an entire system delay from that metric alone. If the delay occurs at downstream acceptance, a robot acceleration change may have little effect on accepted output. Let the event sequence identify the relevant owner.

References: How to use ros2_tracing to trace and analyze an application, official Jazzy documentation source

Verify improvements under controlled change

For each proposed improvement, write the suspected cause, intended change, comparison conditions, and acceptance rule. Change one interpretable factor where practical and retain the previous configuration. Any alteration to physical motion, timing-dependent interactions, or process limits belongs within qualified integration review and the required validation. Never defeat safeguards, weaken a confirmed-process condition, or hide recovery work to improve a timing chart.

Repeat the affected measurement under comparable conditions, then compare duration, accepted output, failure behavior, and measurement uncertainty. A quicker nominal path may be a poor result if it increases retries or creates unstable downstream delivery. Finish with a bounded statement naming the tested configuration and observation window, along with remaining uncertainty. Store the event contract and analysis with the result so a later software update or tooling change can be evaluated against the same question.

References: I/O Setup, PolyScope SW5.21 · Real-Time Data Exchange, official SW10.10 documentation

Checklist

• Define start and completion events for each duration being reported.
• Distinguish robot motion, request latency, accepted output, and recovery.
• Record clock origins, synchronization assumptions, sampling gaps, and uncertainty.
• Validate a pilot log before collecting a representative observation window.
• Retain failed and interrupted attempts with explicit outcome labels.
• Inspect waiting categories and overlapping operations before proposing changes.
• Compare representative distributions and accepted output under matched conditions.
• Submit physical changes to qualified integration review and required validation.

Common questions