Reading a ROS 2 Log Line as Provenance Rather Than Noise

When a robot learner starts a ROS 2 node and sees lines of text appear on the console, the immediate reaction is often to treat those lines as transient noise to be scanned for obvious errors and then discarded. A more disciplined approach treats each logged message as a record with an origin, a scope and a source. The ROS 2 logging subsystem described in the official Jazzy documentation delivers messages to several targets by default: the console when one is attached, log files on disk when local storage exists, and the /rosout topic on the ROS 2 network. Every one of those targets can be individually enabled or disabled per node. Separating what the documentation states as a published fact from what a learner infers about a running system is the practical skill behind reliable robot learning pathways.

What the Logging Documentation States as Fact

The source file at the ROS 2 Jazzy logging documentation records that log messages carry a severity level drawn from DEBUG, INFO, WARN, ERROR and FATAL in ascending order. A logger processes only those messages at or above a chosen level. Each node owns a logger whose name automatically includes the node name and namespace, and if the node name is remapped externally the logger name reflects that remapping. Logger names form a hierarchy: an unset level on abc.def defers to abc, and changing abc affects descendants unless they were set explicitly. That is a dated, scoped statement about the Jazzy documentation source, not a claim about every runtime you will ever see.

The Date, Scope and Source Behind the Statement

The fact above has a source location in the ROS 2 documentation repository for the Jazzy distribution and a scope limited to the logging subsystem ideas the document chooses to describe: overview, severity, logger naming, APIs for C++ and Python, and configuration through environment variables. The document notes that ROS_LOG_DIR selects an exact directory when non-empty, otherwise a path is built from ROS_HOME as $ROS_HOME/.log, with ~ expanded. It also records that RCUTILS_LOGGING_USE_STDOUT sends output to stdout when set to 1 and stderr otherwise. These are process-wide settings applying to all nodes in one process. Knowing the date of the source, its Jazzy scope and its file location lets a learner cite a behaviour instead of guessing it. Our own walkthroughs on environment separation are gathered under ROS environment baselines for readers who want to keep that citation habit.

Provenance as a Separate Lens on the Same Record

The W3C's PROV Model Primer, published as a Working Group Note on 30 April 2013, introduces a data model for provenance interchange. Its abstract says provenance records describe the entities, people and processes involved in producing a piece of data or thing, and that provenance supports understanding how data was collected, judging trust, and reproducing how something was generated. The primer's introduction lists perspectives such as agent-centered provenance about who manipulated information. Applying that lens to a ROS 2 log line means asking which activity emitted it, which entity configured the logger level, and which process owns the node, rather than only asking whether the text looks like an error. The primer is dated 2013 and scoped to explaining core PROV concepts for interchange on the web; it does not specify ROS behaviour, so the connection is editorial inference built on two distinct sources.

Separating Published Fact from Learner Inference

A published fact in this pairing is that the ROS 2 document lists logger APIs such as RCLCPP_INFO, RCLCPP_INFO_ONCE and throttled variants, alongside Python equivalents using logger.info with keywords like throttle_duration_sec, skip_first and once. The date and source are the Jazzy documentation file already cited. A learner inference would be that a missing INFO line in a capture therefore proves the node did not reach a particular code path. The documentation supports the API existence and severity filtering as fact; it does not by itself confirm why a specific runtime omitted a line, because console, file and /rosout targets may differ per node. Recording the fact, its date, scope and source separately from the guess prevents a debugging session from hardening a wrong conclusion into a tutorial. Related practice material appears in ROS 2 diagnostic exercises.

Using Hierarchy Knowledge Without Overreaching

The hierarchical logger naming fact is useful when you set levels during experiments. Because a child logger defers to its parent when unset, a single assignment to a namespace-scoped logger can change several node loggers at once unless those children were pinned. The source for that behaviour is the same Jazzy logging document with the scope of logger configuration. A hypothetical example: suppose a learner remaps a node from camera to front_camera and then sets a level on a logger named for the old name; the remapped logger name in the hierarchy means the setting may not touch the intended node. This is hypothetical/假设示例 and only illustrates the naming rule the document gives. Learners who record such scenarios as explicit hypotheses rather than measured results keep their notes honest, and our scenario library at recorded ROS scenarios follows the same separation.

Why the Two Sources Do Not Merge Into One Claim

The ROS 2 documentation is evidence about a logging implementation in a specific distribution. The PROV primer is evidence about a generic provenance model intended for many domains and published years earlier by a different body. An editor can use the primer's vocabulary of entities, activities and agents to describe the ROS 2 logging outputs, but cannot present that vocabulary as part of the ROS 2 specification itself. The scope of the primer covers interchange of provenance descriptions on the web; the scope of the ROS 2 file covers console, disk and topic targets for nodes. Respecting both boundaries means a learner writes one paragraph citing the Jazzy file for severity and targets, and another paragraph citing the 2013 primer for why provenance framing helps trust and reproduction, without blending them into a single unsupported specification claim.