❤️ (VCS) 🕒 Future Considerations

[OppaAI]

⚙️ Short-Term Optimizations:

1. "AI Latency" Bottleneck

• 🚩 Risk: Running AI/LLM analysis inside the pulse_callback will "freeze" the robot's reflexes.
• 📋 Proposal: Use a Threaded Worker or separate Node 2 (Analyzer) so the pulse can continue while the brain "dreams."

2. Python / GIL Dependance

• 🚩 Risk: Python is too slow for ROS2 high frequency message publishing.
• 📋 Proposal: Critical high frequency nodes should consider to code with C++, or at least implement multiprocessing / asyncio.

3. Lack of QoS Strategic Adjustment

• 🚩 Risk: Currently, QoSProfile(depth=10), no strategy for the high frequency heartbeat to adjust reliabilty / durablity / history.
• 📋 Proposal: Set the QoS according to each topic, eg. heartbeat use best_effort + small queue.

4. Lack of Error / Exception Handling

• 🚩 Risk: No error / exception at the publish fall, subscriber fall, clock fall, etc.
• 📋 Proposal: Check for potential error / exception points, and implement fallback / fail-safe procedures.

5. Lack of Metrics / Monitoring

• 🚩 Risk: No statistical publishing of frequency, latency, failure percentage
• 📋 Proposal: Add ros2 topic / rclpy timers to calculate latency; Use heartbeat frequency to monitor network and robot load.

6. Feedback Loop without time limit

• 🚩 Risk: Analyzer publishes feedback → Generate receives → Output display → If high frequency heartbeat / feedback not controlled, CPU load will explode exponentially.
• 📋 Proposal: Set speed limit / throttle in feedback rate

7. Terminal / Console Display Coupling too high

• 🚩 Risk: Display is built-in Generator / Analyzer, blocking async functions, debug not convenient.
• 📋 Proposal: Already addressed in ❤️ (VCS/VTC+VCC) print Bottleneck #2.

8. Encryption and Message Format not Separated

• 🚩 Risk: Right now is one big packet → eg. High frequency heartbeat use the same algorithm, will cause congestion.
• 📋 Proposal: Already addressed in ❤️ (VCS/VTC+VCC) Frequency & Synchronization #9.

9. Lack of ROS2 Native Tooling Integration

• 🚩 Risk: Currently use print / console animation → not compatible with ros2 topic echo, ros2 bag record, rqt_plot.
• 📋 Proposal: High frequency uses ROS2 msg type, binary; Display node uses non-blocking UI / console; Logging uses JSON / rosbag. Already addressed in ❤️ (VCS/VTC+VCC) JSON "Fragility" #5 and ❤️ (VCS/VTC+VCC) print Bottleneck #2.

10. Node launch / configuration too hardcoded

• 🚩 Risk: Robot ID, USER ID, topic names are all hardcoded → reduce scalability of robot / multi-user.
• 📋 Proposal: Already addressed in ❤️ (VCS/VTC+VCC) Hardcoded Namespaces #4.

💡 Long-Term Implementation:

1. Add SPI LED Screen for display

• Display the vital pulse in SPI LED Screen
• Use a separate vp_display_node to display on the LED