A Factory Reset Is Not a Complete Used-Robot Handover

On the secondhand market for industrial robots, a factory reset is often mistaken for a clean slate. Buyers may assume that once a controller has been reset, the previous configuration disappears and the machine arrives as neutral hardware. For transaction records, however, that assumption leaves a documentation gap. A reset may clear one storage layer, but exported settings, parameter files, launch files and service-side configuration can persist in backups, maintenance laptops or commissioning archives. This article builds a checklist around backed-up configuration, recorded parameter types and the provenance of exported settings, using ROS 2 Jazzy parameter concepts and W3C PROV provenance ideas only as documentation anchors, not as repair guides.

Why a Reset Does Not End the Configuration Story

In ROS 2 Jazzy, parameters are associated with individual nodes and configure nodes at startup and during runtime without changing code; their lifetime is tied to the node, though a node may implement persistence to reload values after restart (ROS 2 Jazzy parameters documentation). That persistence point matters in a sale. If a node was designed to reload values after restart, a factory reset of one interface does not necessarily remove every stored value the node relied on. The transaction record should therefore ask not only whether a reset was performed, but whether reloaded persistence existed and where the reloaded source file is now kept.

For used-equipment records, the practical issue is not how to clear a machine. It is how to describe what the seller observed about configuration state at handover. A record can say that a reset routine was run on a specific date, while also noting that parameter values may be reloaded from a file the buyer has not yet seen. That distinction protects both sides: the seller documents what was observed, and the buyer knows to request the reload source during acceptance testing.

Recording Parameter Types Before the Sale

A parameter in ROS 2 Jazzy consists of a key, a value and a descriptor, and the value is one of the following types: bool, int64, float64, string, byte[], bool[], int64[], float64[] or string[] (ROS 2 Jazzy parameters documentation). Descriptors may be empty by default but can contain descriptions, value ranges, type information and additional constraints. In a used-robot transaction file, those types are a compact way to say what was exported.

The checklist should include a parameter-type inventory. Instead of writing “configuration included,” the record can list node names, parameter namespaces and the parameter type for each exported value, or cite a /node_name/get_parameter_types service response observed before export. That same source documents default services such as /node_name/get_parameter_types, which returns types for given parameter names, and /node_name/list_parameters, which lists available parameters by prefix. A transaction record can note that a parameter list was read through those interfaces on the seller side, without turning the note into a command tutorial.

Recording types also helps later audits. If a parameter later appears as a string where the record once showed int64, the discrepancy is visible. Recommended documentation practice is to store the exported type list beside the export timestamp and the node identity, so the file itself becomes part of the equipment history rather than a loose screenshot.

Provenance of Exported Settings

The W3C PROV model treats physical, digital, conceptual or other things as entities, and provenance records can describe the provenance of entities (W3C PROV Model Primer). In a used-robot handover, an exported parameter file is an entity. Its provenance is not merely “the file exists,” but who or what generated it, which activity produced it, and which earlier entities it used.

PROV also distinguishes agent-centered, object-centered and process-centered provenance, and describes agents as persons, software, organizations or other things that can be ascribed responsibility (W3C PROV Model Primer). For transaction documentation, a provenance note can say that the export activity used a prior parameter set, was associated with the seller’s maintenance laptop as an agent or software role, and produced a new YAML-style entity. This is metadata about origin, not a claim that the file is safe or licensed for transfer.

Recommended documentation practice is to keep provenance short but structured: entity name, export activity date, source parameter set, exporting agent or tool if known, and storage location. If the exact agent is unknown, the record should say “agent not recorded” rather than invent one. The PROV source is used here only to shape a record template, and the institutional source is not an endorsement of this checklist.

What Belongs in a Backed-Up Configuration Record

Backed-up configuration should be described as observed artifacts. A transaction file can list a YAML parameter file, a launch configuration snippet or a parameter dump, together with the node names and namespaces they address. In ROS 2 Jazzy, parameters are addressed by node name, node namespace, parameter name and parameter namespace, and the namespace part is optional (ROS 2 Jazzy parameters documentation). The checklist should therefore capture the addressing scope, because “all parameters” and “parameters under prefix X” are different records.

The record should also distinguish declared from possibly undeclared values. The same documentation notes that a node normally declares all parameters it will accept, but can be instantiated with allow_undeclared_parameters set to true so parameters can be get and set even if not declared (ROS 2 Jazzy parameters documentation). For a sale file, that means an export made before undeclared values were added may not match the running node later. Recommended documentation practice is to state whether the export was taken while undeclared parameters were permitted, or only after declaration was confirmed.

Initial values set through command-line arguments or YAML files are another entry. The ROS 2 source says initial parameter values can be set when running a node through individual command-line arguments or YAML files, and also through the ROS 2 launch facility (ROS 2 Jazzy parameters documentation). A used-robot record can note whether the backup covers only current runtime values, only startup YAML files, or both layers. This avoids the false completeness that a reset creates.

Hypothetical Handover Example

Consider a hypothetical example for a used mobile manipulator sold between two integrators. The seller performs a controller reset and provides a ZIP archive labeled “config backup.” The archive contains a YAML file with node /nav_controller parameters, including an int64 timeout value, a string frame name and a float64 speed limit. The transaction record should not say the robot was fully cleared. It should say: reset observed on the handover date; YAML entity exported from node /nav_controller on the prior day; parameter types recorded as int64, string and float64; reload persistence not confirmed. The buyer later finds the node reloads a speed value after restart, so the file remains relevant. The hypothetical example shows why the record must name the artifact and its observed origin rather than rely on the reset event alone.

In that same hypothetical example, the provenance note would identify the exported YAML as an entity produced by an export activity, using the earlier parameter set, and associated with the seller’s commissioning tool if that tool is named in the archive metadata. If no tool name is present, the note says “exporting agent not recorded.” No inference about license transfer or runtime safety is added.

A Transaction Documentation Checklist

The following checklist is recommended documentation practice for used-robot transaction records, not a claimed requirement of ROS 2 Jazzy or of the W3C PROV standard. Each item is observational and safe to store in a sales file.

• Reset observation: date and interface on which a reset was observed, plus whether node persistence reload behavior was confirmed or unknown.
• Parameter-type inventory: node name, optional namespace, parameter name and one of the ROS 2 Jazzy value types for each exported setting, or a cited get_parameter_types observation.
• Descriptor note: whether descriptors were empty or contained ranges, constraints or descriptions, if that was observed in the export.
• Declared-status note: whether the running node allowed undeclared parameters, and whether the export was taken before or after such values existed.
• Backup layers: separate entries for startup YAML files, launch-supplied initial values and runtime parameter dumps.
• Provenance of the file: entity name, export timestamp, source parameter set, exporting agent or tool if recorded, and storage location.
• Gap statement: explicit fields for “not observed,” “agent not recorded” or “reload source not provided,” so omissions are visible.

Used-equipment platforms such as this one can attach the checklist to a listing. Buyers comparing technical guides and sellers tracking industry updates both benefit from a record that separates observed configuration from assumed clearance. The goal is not to promise that a robot is clean, licensed or ready; it is to make the exported-settings history legible enough that the next owner knows what to test, what to request and what was never recorded at all.