Reading ROS 2 Logging Output as Provenance for Robot Daily Reports

When a robotics team publishes a daily update about field behavior, the raw console output from a ROS 2 node is often the most immediate piece of evidence available. The official ROS 2 Jazzy documentation describes how the logging subsystem delivers messages to the console, to log files on disk, and to the /rosout topic on the ROS 2 network, with each target able to be enabled or disabled per node. For a daily robotics source tracker, that published description gives us a fact with a clear scope: it tells us where messages go by default, but it does not by itself tell us why a particular mobile base stopped moving on a given afternoon. The date of the source is part of the Jazzy documentation stream, and its scope is the logging subsystem rather than any specific robot deployment. Treating the configuration description as a published fact means we can report that a node emitted a WARN at a certain severity threshold, while leaving the cause of the warning to separate editorial inference.

Severity Levels as a Separator Between Fact and Guess

The ROS 2 logging documentation specifies five severity levels in ascending order: DEBUG, INFO, WARN, ERROR and FATAL. A logger processes only those messages at or above a chosen level. Each node carries a logger whose name includes the node name and namespace, and logger names form a hierarchy where an unset level defers to a parent or to the default. For daily reporting, this hierarchy is a fact about configuration structure. If we see a stream of ERROR lines from a navigation logger, the published fact is that the threshold permitted those messages and the logger name resolved to that node. Our inference that the robot lost localization is separate; it rests on correlating log content with other telemetry, not on the severity scheme alone. Readers following our coverage of mobile platform behaviors will recognize that a level change alters what we can see, not what happened.

Where Provenance Language Fits the Logging Story

The W3C PROV Model Primer, published as a Working Group Note on 30 April 2013, introduces a data model for provenance interchange on the web. It defines entities, activities, agents and responsibility so that the origins of a digital object can be described. A ROS 2 log file on disk is an entity in that sense: it was generated by an activity involving the logging subsystem and influenced by the node acting as an agent with a specific role. The primer’s framing lets us say, as a published fact from the source, that provenance records describe what produced a thing; saying that a particular log file proves a maintenance lapse is our editorial step. You can read the primer at https://www.w3.org/TR/prov-primer/ and the logging description at https://raw.githubusercontent.com/ros2/ros2_documentation/jazzy/source/Concepts/Intermediate/About-Logging.rst to check the scope of both.

Console, Disk and Topic Are Distinct Publication Targets

By default, ROS 2 node log messages go to the console on stderr, to files on disk, and to the /rosout topic. That triple destination is a concrete fact with a defined scope in the Jazzy source. It matters for daily source tracking because a message seen only in a saved file may not have appeared on an attached console during a shift, and vice versa. The documentation also notes that RCUTILS_LOGGING_USE_STDOUT controls the stream, unset or zero meaning stderr and one meaning stdout. When we report that a team captured output during a warehouse test, we attribute the capture to the configured target rather than assuming a single universal sink. A hypothetical example may help: suppose a fleet operator sets ROS_LOG_DIR to a mounted volume and later reads warnings from that path; the fact is the configured directory from the environment variable, while the inference that the volume was reviewed that day is not in the source. Our section on fixed installation logging covers related capture practices.

APIs and Throttling Change the Sampling of Reality

The logging APIs listed for C++ and Python include variants such as _ONCE, _SKIPFIRST, _THROTTLE and stream forms, all taking a logger as the first argument or being called on a node logger in Python. These are published interface facts from the ROS 2 documentation. They have a direct effect on daily interpretation: a throttled message emitted at most once per integer-millisecond interval means the log we hold is a sampled subset, not a full trace. If a developer used RCLCPP_WARN_THROTTLE, the absence of repeated lines is explained by the API contract, not by the fault disappearing. Reporting that absence as “no further issues” would be an inference unsupported by the throttling fact. For perception stacks discussed under vision and sensor processing, this distinction decides whether a quiet log is reassuring or merely filtered.

Agents, Roles and Responsibility in a Log’s Origin

PROV’s intuitive overview separates agents and responsibility from usage and generation, allowing a provenance record to state who or what was involved in producing an object. Applied to a ROS 2 /rosout message, the agent is the node (or its process) and the activity is the logging call. The primer, as a W3C Working Group Note rather than a Recommendation, carries its own status caveat: it is a draft-like publication that may be updated. That publication status is itself a fact we must report when citing it, instead of presenting it as a finished standard. The ROS 2 Jazzy page similarly sits inside a versioned documentation tree, so its scope is Jazzy rather than all ROS 2 releases. Keeping those boundaries visible prevents a daily brief from implying a universal rule from a single-version source.

Daily Tracking Without Invented Endorsements

A daily robotics source tracker separates what a document says from what a newsroom concludes. The ROS 2 logging source tells us the mechanics of levels, names, targets and APIs; the PROV primer tells us how to describe origins, activities and agents in a structured way. Neither tells us a customer’s uptime, a certification outcome, or a quotation from a vendor. When we see a log line in a public field report, we can publish the severity, the logger hierarchy behavior and the destination fact, then explicitly mark any causal reading as inference. That discipline keeps the daily record useful: engineers can replay the configuration, and readers can see which part of the story came from the official page and which part came from our own reasoning about a robot’s day.