A Rental Return Record Is Different from the Delivery Acceptance Record

On a rental fleet desk, the paperwork created when a mobile robot comes back often looks like a photocopy of the delivery acceptance sheet. The two documents serve different moments in the rental lifecycle. A pre-arrival rental brief describes what was supposed to arrive and the scope agreed before the unit was powered on. A return record captures what actually came back, which configuration values survived field use, and which observation steps both sides agreed to perform at the gate. Keeping them separate reduces disputes later, because the return record is not a restatement of the outbound checklist; it is a new observation log made at a later point in time.

Why the Return Record Is a Later Observation Event

Delivery acceptance happens before operational exposure. Return happens after the unit has been in a customer site, possibly under changing workloads and repeated restarts. In ROS 2 Jazzy, parameters are associated with individual nodes and are used to configure nodes at startup and during runtime without changing code, and the lifetime of a parameter is tied to the lifetime of the node, though the node could implement persistence to reload values after restart (ROS 2 Jazzy documentation). That means a return-side reviewer cannot assume the node still holds the same values seen at delivery. The return record should therefore describe the state observed at return, including node names, namespaces, and the parameter names actually read at that moment, rather than quoting the outbound configuration as if it were still present.

Identity at Return: Node Name, Namespace, and Parameter Address

The return form should start with identity, not with condition. ROS 2 parameters are addressed by node name, node namespace, parameter name, and parameter namespace, and providing a parameter namespace is optional (ROS 2 Jazzy documentation). A practical return record lists the node name and namespace used for the readback, then the parameter names as returned by the node’s own services. If the rental operator used the /node_name/list_parameters service, the record can note the prefixes used and the resulting parameter list. This recommended documentation practice helps later reviewers see whether the same address was used at delivery and return. If the namespace changed during the rental, the return record should show the new address rather than silently reusing the old one.

Configuration Changes: Readable Types and Service-Based Verification

At return, reviewers often want to know whether a field engineer changed a tuning value. Each parameter consists of a key, a value, and a descriptor, and each parameter has one of several pre-defined types such as bool, int64, float64, string, and array forms (ROS 2 Jazzy documentation). External processes can read values through services created by default when a node is instantiated, including /node_name/get_parameters and /node_name/get_parameter_types (ROS 2 Jazzy documentation). A recommended documentation practice is to log the type returned by get_parameter_types alongside the value, because a mismatch between expected and returned type is itself a recordable observation. The return sheet should not claim the setting was “repaired” or “restored”; it should say what was read and whether the read matched the outbound described type.

Retained Exports: What the Return Packet Should Contain

A return acknowledgment is stronger when it retains an export rather than only a human summary. The ROS 2 Jazzy source describes services such as describe_parameters, get_parameter_types, get_parameters, list_parameters, set_parameters, and set_parameters_atomically (ROS 2 Jazzy documentation). For return purposes, the read-only responses from list_parameters, get_parameters, and get_parameter_types are the natural export set. The return packet can include the service request prefixes, the response values, and the timestamp of the observation. This is an export of observed state, not a machine repair action. Operators should avoid recording set or atomic-set attempts in the return file unless both parties explicitly agreed to a configuration-change step; otherwise the return record mixes observation with intervention.

Agreed Observation Scope: A Hypothetical Return Check

Consider a hypothetical example for a rented inspection robot returned after a two-week deployment. The agreed observation scope is read-only. The technician powers the unit in a staging area, brings up the relevant nodes, and runs a parameter listing with no prefixes to see all available parameters. They then call get_parameters for the navigation and sensor configuration names used in the outbound brief, and get_parameter_types for the same names. The return record logs the node namespace, the returned values, the returned types, and the fact that no set_parameters call was made. This scenario is hypothetical; no actual client or test result is claimed. The key editorial point is that the scope says “observe and record,” not “adjust, reset, or fix.”

Where a rental uses a hash digest to fingerprint an exported parameter file, the documentation can note the algorithm family used for the digest. Approved hash algorithms for generating a condensed representation of a message are specified in FIPS 180-4 and FIPS 202, and NIST summarizes expected properties such as collision resistance, preimage resistance, and second preimage resistance for approved functions (Hash Functions | CSRC). This is a recordkeeping aid for file identity, not a safety or compliance guarantee. The rental return record should state the digest method as an export-labeling choice only.

Separating Return Records from the Pre-Arrival Brief

The earlier technical guides on this site cover what to confirm before equipment arrives; that document belongs to the outbound phase. The return record should not repeat the pre-arrival brief as its own content. Instead it can reference the brief by date and say that the return observation is a separate later event. This separation matters because the outbound brief may describe intended initial values set through command-line arguments, YAML files, or launch configurations, while return describes the observed node state after runtime exposure. 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 documentation). The return record can note those outbound sources as background while keeping its own body focused on the return readback.

Practical Return Checklist for Rental Desks

A compact return checklist works better than a long narrative. Recommended fields include return date, unit serial, node name and namespace observed, prefixes used for list_parameters, the parameter names read via get_parameters, the types returned via get_parameter_types, the export file name, the digest method if one is used, and the names of both observers. The checklist should also record whether any undeclared parameters were encountered. By default a node needs to declare all parameters it will accept, but some nodes can be instantiated with allow_undeclared_parameters set to true so parameters can be get and set even if not declared (ROS 2 Jazzy documentation). A return record can simply note whether the observed node exposed undeclared-readable parameters, as an observation rather than a defect verdict.

For fleets that track broader deployment context, the return log can be filed beside industry updates on rental programs, but the return document itself stays narrow: identity, observed configuration, retained read-only exports, and agreed observation scope. That narrowness is what makes the return record useful when a later question arises about what the robot looked like at the moment it came back.