Day 30: Topics, message design, publishers, and subscribers

A ROS topic supports asynchronous publish-subscribe communication. A publisher sends typed messages under a topic name without naming a particular receiver or waiting for a reply. Zero, one, or several subscribers may listen, and a topic may also have multiple publishers if the system design permits it. This loose coupling is excellent for ongoing sensor data and state streams, but it means a publisher cannot treat message publication as proof that a specific consumer processed the data.

The topic name and message type form only part of the contract. A numeric field such as value: 2.4 is unusable unless a reader knows whether it is volts, metres, radians, or metres per second; which coordinate frame it belongs to; when it was measured; and whether the measurement is valid. Prefer established standard messages when their semantics fit. When designing a custom .msg, use clear field names, bounded sequences or strings where resource limits matter, a timestamp and frame where the data is spatial or time-sensitive, and comments that state units and valid ranges.

Measurement time and arrival time answer different questions. A camera can capture an image at 10.000 s, spend 35 ms processing it, and deliver it at 10.050 s. The image describes the earlier physical scene. A downstream node that substitutes arrival time may combine it with a newer robot pose and create a spatial error. Preserve source timestamps across the pipeline, measure age separately, and define what the consumer does when data is too old or out of order.

Rate affects freshness, bandwidth, and callback load. At frequency f, the ideal period is T=1/f. A 20 Hz publisher aims for one message every 50 ms, not twenty messages all at once each second. Payload bandwidth can be estimated as payload bytes × messages per second, but actual network use is higher because serialization, middleware, discovery, and transport add overhead. Measure message rate, size, age, and loss on the deployed path rather than turning the estimate into a guarantee.

A useful message is stable at its public boundary. Do not publish a whole internal object merely because it is convenient. Consumers then depend on fields they do not need and every internal refactor becomes an interface change. Design around physical meaning and consumer needs, version incompatible semantics deliberately, and write tests that reject wrong units, missing timestamps, invalid enum values, oversized arrays, and impossible ranges.