Store sending node and wall-clock time in BB.Message

[jimsynz]

Summary

BB.Message should store the sending node and wall-clock time in addition to the existing monotonic timestamp.

Current Structure

%BB.Message{
  timestamp: integer(),   # System.monotonic_time(:nanosecond)
  frame_id: atom(),
  payload: struct()
}

Proposed Structure

%BB.Message{
  monotonic_time: integer(),  # System.monotonic_time(:nanosecond)
  wall_time: integer(),       # System.system_time(:nanosecond)
  node: node(),               # node()
  frame_id: atom(),
  payload: struct()
}

Rationale

The current monotonic timestamp is only meaningful within a single BEAM VM instance. For a general-purpose robotics framework, we need to support:

Single robot use cases:

• Data recording/playback (need wall-clock to know when events occurred)
• Log correlation with external systems
• Debugging (matching events to real-world time)

Distributed use cases:

• Multi-robot coordination
• Single robot with multiple nodes (perception, planning, control on separate nodes)
• Integration with external systems (ROS, cloud services)

What each field provides:

Field	Use Case
monotonic_time	Event ordering and duration calculations within a node
wall_time	Correlation with real-world time, recording, external systems
node	Identifying message origin in distributed deployments

Notes

• For tight multi-robot coordination requiring precise cross-node ordering, users may still need additional infrastructure (PTP, GPS time, HLC, etc.)
• This proposal covers the common cases; advanced distributed scenarios can build on top
• The node field enables users to implement their own distributed ordering schemes if needed

Migration

This is a breaking change to the struct. Consider:

1. Renaming timestamp → monotonic_time for clarity
2. Adding wall_time and node fields
3. Updating BB.Message.new/3 to populate all fields