❤️ (VCS/VTC+VCC) JSON "Fragility"

[OppaAI]

⚠️ Issue:

High-Overhead Serialization (JSON String Coupling)
Everything is wrapped in a string message and manually calling json.dumps.

🎯 Location:

/robot/vital_pulse_generator
/server/vital_pulse_analyzer

🦠 Symptoms:

• JSON is string based, CPU load is large and slow for robot.
• Every callback needs to parse JSON string → High CPU overhead.
• No type safety → May cause type mismatch exceptions.

🩺 Diagnosis:

The use of json.dumps() created a Schema-less String Bottleneck.

• Computational Cost: JSON is a text-based format that requires intensive parsing/lexing.
• Bandwidth Inefficiency: Text-based keys (e.g., "timestamp":) are redundant and waste bandwidth compared to Binary Packed formats.
• Lack of Type Safety: There was no Compile-time Validation to ensure the data structure remained consistent between the Robot and the Server.

💡Propsal:

1. Use ROS2 message types

• Fast, binary serialization.
• Type safe, avoid parsing exceptions.
• Fully support ROS2 tools (ros2 topic echo, rosbag).

2. Use struct or flatbuffers or other formats (eg. TOON, MessagePack, Protobuf).

• Use struct.pack() / struck.unpack().
• Use FlatBuffers / Cap'n Proto (binary format, zero-copy).
• Fast, reduce bandwidth.

3. Hybrid approach

• Use JSON for debug/logging only.
• Use custom message type during ROS2 publish / subscribe.
• Easy debug JSON output, and high efficiency binary message.

➡️ Future Implementation:

• Check out the ROS2 built-in security layer: SROS2, that encrypt everything automatically.
• Develop an encoding / encryption scheme (Lite, Mid, Strong).

[OppaAI]

🩹 Remediation:

Migrating to Native ROS 2 IDL (Interface Definition Language)
The system was refactored to use a Strongly-Typed Binary Schema:

1. Implementation of Custom Msg Types: Defined a .msg file in a dedicated C++ CMake package. This utilizes the ROS 2 Middleware (RMW) for Binary Serialization, which is significantly faster than JSON.
2. Zero-Copy Potential: By using native messages, the system can eventually leverage Intra-Process Communication (IPC), allowing the Robot to share data with local nodes via shared memory rather than the network stack.
3. Architecture Decoupling: The logic now follows a Contract-First approach. The Robot and Server are "contractually obligated" to follow the message definition, eliminating the need for manual json.loads() error handling

📈 Results:

Optimized Computational Efficiency

• CPU Load Reduction: Eliminated the overhead of string parsing, freeing up cycles for the Jetson's AI/Vision tasks.
• Binary Packing: Reduced the payload size per packet, lowering Network Congestion and improving RTT stability.
• Tooling Compatibility: The system is now fully compatible with ros2 topic echo, ros2 bag, and rqt_plot without requiring custom JSON decoders.