Learning to Separate ROS Logs from Recorded Communication Data

A robotics lesson can produce several kinds of evidence: messages printed by a program, data published on a topic, the configuration used to start a node, and notes written by a learner. These records answer different questions. Knowing which kind of evidence is available makes it easier for a tutor and a student to discuss an exercise without guessing why an unexpected result occurred.

Identify the question before collecting evidence

Begin with a specific observation, such as “the sample application started, but the expected message did not appear in the terminal.” Record the lesson, software version, operating environment, start sequence and time of observation. If a detail is unknown, label it as unknown. This short context can be more useful than an unexplained screenshot containing a single line of output.

In a classroom, agree on where files may be saved and who may see them. A log or recording can contain machine names, network details or data from other users. Use a supervised simulation or a tutorial environment when learning; an online guide does not authorize changes to a physical robot or its safety settings.

Read a log message in context

The ROS 2 Jazzy logging documentation describes a logging subsystem that can send messages to the console, disk files and the /rosout topic. It also describes severity levels and configuration. A message labelled as a warning or error is information produced by a component; deciding what it means for a particular exercise still requires context.

When documenting a message, keep its text, approximate time and the node or program that produced it when that information is available. Capture the surrounding output if the class rules allow it. Do not remove the preceding lines and then present the remaining sentence as a complete diagnosis. Conversely, a quiet terminal does not prove that every other part of the exercise worked.

Distinguish a data recording from a program log

The official ROS 2 recording and playback tutorial explains how ros2 bag can record data published on topics and services for later examination or playback. A recording of selected communication data is not automatically a complete account of a computer, a physical scene or every action performed by a person.

Before an exercise, write down which data the instructor expects the group to record. Afterward, list what was actually captured, where the file is stored and whether it can be opened in the intended environment. If a topic was not included, write “not recorded”; do not infer its values from a later attempt. Keep the program output and the data recording as separate items linked by the exercise identifier.

Use a clearly labelled hypothetical exercise

Imagine a student runs a simulated sensor example and later cannot find an expected data stream in a recording. The initial note could identify the tutorial, start order, recording selection and the time at which the student looked for the stream. A tutor can then use those facts to decide what to inspect next. The missing stream alone does not establish that a sensor failed or that the application was defective.

If the group repeats the exercise, record which condition changed between attempts. Keep the earlier evidence rather than replacing it with the later result. Describe what was observed and what remains a hypothesis in separate sentences. This practice makes the result reviewable without turning a classroom exercise into an unsupported incident report.

Prepare a useful handover for a tutor

A compact handover can include the lesson name and version, the goal, the commands or interface actions used under supervision, the relevant log excerpt, the recording identifier, and a list of missing information. Include the version of the software and any local changes that are known. If the file is too large to share, describe its location and arrange access through the course’s approved process.

Before sharing, remove or protect information that the recipient does not need, such as credentials, personal details or customer data. Preserve an unmodified original only where the relevant policy permits it. If sensitive information cannot be separated safely, ask the responsible instructor or administrator how to provide the evidence.

Review the result without overstating it

At the end of the lesson, write down what the evidence supports and what it does not. A recorded message can show what a program reported under the recorded conditions; it does not by itself prove the cause of an unexpected outcome. A successful playback shows that a particular file was played back in a particular environment, not that every hardware condition has been reproduced.

For a related learning topic, read the site’s guide to reproducing a ROS tutorial environment. The industry information section provides additional background. Always check the documentation for the version actually used in the exercise, because examples and supported features can change.