Project

General

Profile

Task #224

Updated by Sanghoon Lee about 1 month ago

The 2F sidecar Web UI, should be designed as a non-invasive visualization adapter, requiring no changes to the upper-level tactile publisher or lower-level control logic. 

 Design intent: 
 - Transform ROS tactile payloads into browser-ready states with low integration costs. 
 - Provide runtime mode switching as a stable ROS service contract. 
 - Support both global and namespace-based TF delivery models via launch remapping. 

 This ensures that the web visualization remains evolving independently of the control stack release cycle. 

 --------------- 
 !{width:800px}clipboard-202602281630-qxviz.png! 

 --------------- 

 h1. xela_taxel_sidecar_2f 

 h2. 1. Overview and design objective 

 The 2F sidecar is designed as a non-invasive visualization adapter: it does not alter upstream tactile publishers or downstream control logic. 

 Design intent: 

 * transform ROS tactile payloads into browser-consumable state with low integration cost 
 * expose runtime mode switching as a stable ROS service contract 
 * support both global and namespaced TF transport models through launch remapping 

 This keeps web visualization evolvable independently of control-stack release cycles. 

 h2. 2. Node architecture 

 h3. 2.1 Bridge node (@xela_taxel_web_bridge_node@) 

 * subscribes tactile array topic 
 * optionally subscribes grasp telemetry/event topics and embeds recent JSON metadata 
 * normalizes/maps values 
 * publishes compact JSON payload 
 * optional TF lookups for URDF points 

 h3. 2.2 Mode manager (@xela_viz_mode_manager_node@) 

 * service facade: @/xela_viz_mode_manager/set_mode@ 
 * writes bridge params: @viz_mode@, @emit_urdf_points@, @freeze_urdf_positions@ 
 * forwards request to viz node service 
 * startup sync retry timer 

 h3. 2.3 Web transport 

 * static HTTP server for @web/taxel_sidecar@ 
 * optional dedicated rosbridge instance 
 * browser websocket fallback order: @:9090@, @:3201@, @/ros@ 

 h3. 2.4 Web UI runtime 

 * browser-side display modes are @GridMode@, @XelaModel@, and @RobotModel@ 
 * @GridMode/XelaModel/RobotModel@ are distinct from ROS-side @grid/urdf@ 
 * RobotModel includes optional FollowCam logic and telemetry analysis rendering 
 * FollowCam / Analysis toolbar exposure can be toggled independently from the underlying code paths 

 h3. 2.5 Runtime wiring diagram 

 Generated PNG: @docs/runtime_wiring_diagram.png@ 
 !{width:1000px}runtime_wiring_diagram.png! 

 <pre> 
 Browser (index.html + rosbridge_client.js) 
   |-- HTTP GET / ----------------------------> sidecar_http_server.py (:8765) 
   | 
   |-- WebSocket ws://&lt;host&gt;:9090 -----------> rosbridge_websocket_sidecar 
   |                                              (rosbridge_server/rosbridge_websocket) 
   |                                                | 
   |                                                |-- subscribe / publish --> /x_taxel_2f/web_state 
   |                                                |-- service call ---------> /xela_viz_mode_manager/set_mode 
   |                                                |-- optional access ------> /tf, /tf_static, /robot_description 
   |                                                                        or namespaced std-viz equivalents 
   | 
   `-- sidecar UI renders GridMode / XelaModel / RobotModel 

 /x_taxel_2f ----------------------------------> xela_taxel_web_bridge_cpp 
 /x_telemetry_2f/grasp_telemetry --------------> xela_taxel_web_bridge_cpp 
 /x_telemetry_2f/grasp_event ------------------> xela_taxel_web_bridge_cpp 
 /tf, /tf_static (or namespaced TF) -----------> xela_taxel_web_bridge_cpp 
 xela_taxel_web_bridge_cpp --------------------> /x_taxel_2f/web_state 

 /xela_viz_mode_manager/set_mode --------------> xela_viz_mode_manager_cpp 
 xela_viz_mode_manager_cpp -- set_parameters --> xela_taxel_web_bridge_cpp 
 xela_viz_mode_manager_cpp -- SetBool -------> /xela_taxel_viz_2f/set_mode 
                                            or /xviz2f/std_xela_taxel_viz_2f/set_mode 
 </pre> 

 Notes: 

 * The browser uses two separate paths: HTTP for static assets and WebSocket for ROS traffic. 
 * @rosbridge_client.js@ tries @:9090@ first; @:3201@ and @/ros@ are fallbacks. 
 * @xela_viz_mode_manager_cpp@ is the ROS-facing mode-switch facade. 

 h2. 3. Launch architecture 

 * primary: @xela_taxel_sidecar_cpp.launch.py@ 
 * compatibility: @xela_taxel_sidecar.launch.py@ 
 * primary launch exposes bind hosts for the static web server and sidecar rosbridge (default @0.0.0.0@) 

 h2. 4. Integration strategy 

 * default target: @viz_node_name=/xela_taxel_viz_2f@ 
 * std-viz namespaced target via overrides: 
 ** @viz_node_name:=/xviz2f/std_xela_taxel_viz_2f@ 
 ** @bridge_tf_topic:=/xviz2f/tf@ 
 ** @bridge_tf_static_topic:=/xviz2f/tf_static@ 

 h2. 5. Design risks 

 * target viz service unavailable 
 * TF remap mismatch in URDF mode 
 * duplicate transport nodes from multiple launch variants 

 h2. 6. Validation 

 * launch smoke test 
 * topic publish-rate observation 
 * service toggle test 
 * web render check on sidecar URL 
 * browser websocket fallback check (@9090 -> 3201 -> /ros@) 
 * verify URL query defaults are used when no @follow_cam_*@ overrides are present 

 -------- 

 !{width:1000px}clipboard-202602281631-l9vpa.png! 

 ----------- 

Back