Message contract
Implicit state → structured event
Before A state change is only a local observation.
Now The event carries kind, user_id, code, and text.
Task 2 · Refined ROS2 Telemetry and CPU Resource Allocation
Make robot state visible, routable, and schedulable.
This project refines telemetry from an ad-hoc event into a defined ROS 2 message path and a visible runtime workload. Use the switch below to compare the starting model with the current architecture.
← Back to the independent project overviewArchitecture delta
What changed in the system model.
The transport stays familiar. The telemetry boundary becomes explicit.
01 · signal source
Robot / client nodeobserves formation or health state
publish structured record ↓
02 · ROS 2 transport
/ros_chat/client/<user-id>one outbound topic owned by the client
ROS CHAT HUBidentifies sender · validates payload · adds timestamp
/ros_chat/broadcastshared topic delivered to all clients
fan out one validated event ↓
03 · runtime handling
Telemetry processingparse, classify, and expose the event
CPU allocation boundaryreason about telemetry work beside control work
Client responsedisplay, log, or select a response
persistent / observable outputShared event recordsame telemetry item is available to every subscribed client
Validation boundary
Local report → hub-owned record
Before Consumers must infer who produced the signal.
Now The hub validates the sender and publishes one canonical record.
Distribution
Single recipient → fleet visibility
Before A fault can remain inside one client.
Now `/ros_chat/broadcast` gives each subscribed client the same event.
Resource model
Hidden callback → explicit workload
Before Telemetry cost is mixed into general node activity.
Now Telemetry processing is a named workload for CPU allocation decisions.
Runtime sequence
One event. Four controlled boundaries.
The important change is not only the JSON shape. It is the ownership of each step.
01Detect The client observes a robot state change.
02Publish It sends the record on its own outbound topic.
03Refine The hub validates identity and produces the canonical event.
04React Each client receives the broadcast and can display, log, or act.
Message contract
Small payload. Useful semantics.
The contract stays easy to inspect while giving the runtime enough information to classify the event.
{
"kind": "telemetry",
"user_id": "user-2",
"code": "FORMATION_LOST",
"text": "Robot left formation"
}
CPU resource allocation
Make the trade-off visible.
The page separates message delivery from the runtime question: how much attention should telemetry receive?
Robot controltime-sensitive decisions
priorityTelemetry processingparse, classify, and expose
budgetLogging / displayhuman-facing observability
best effortDesign decision: keep control protected, give telemetry a visible allocation boundary, and allow presentation work to yield when resources are constrained.