Visualizing ROS Data

We're going to have to design a good layout that allows the in-car supervisor to allow them to see vital information to ensure our stack is functioning properly, including seeing pointcloud data, pathing, and node statuses, while being able to also diagnose issues. This means creating an interface that allows us to see macro data (general) and micro data (console logs, etc).

Priority:

• Data from CAN buses (Car view)
• Status of ROS nodes (Node view)
• Low-level stack output (Console view)
• Point cloud and classification viewer (3D view)
• Car in relation to the map (Map view)
• Implementation of soft and hard stop (soft = request to stop, hard = force stop)

Possible ways to move away from rviz

• Live and 3D Data can be done through webviz -- already done. Need to fork this and equip it to function with our streams. Can do this with retrofitting the current bridge to work with ros2_to_ros bridge. The layout is great for webviz, allowing us to create visible modules to see different types of data quickly.
• More specialized option is to create a new viewport from scratch rather than using Cruise's libraries which only work on ROS and not ROS2. Using ros2_web_bridge, subscribe to topics that we want to view (post-format from behavior/perception, we'll have to work with both teams to ensure that we get proper formatted data from them). From here, we can interpret this to the client with roslibjs, using actionclient to send goals and receive responses from our local server (or in the future remote server).

Things to keep in mind

• Data from the car's stock CAN bus including speed, steering angle, other telemetry data can be viewed in another panel. These should interact directly with the car to keep these systems running in the event of a total failure with the SD systems Self-driving data and stock car data should be handled separately and compartmentalized in case of a fault or error.
• It's important to create better live visualizations quickly for the team as a whole to be able to diagnose problems quicker, meaning that forking over webviz to be used with our stack might be better in the short term, and then working on either further tailoring this for our own use case, or creating a new visualizer entirely. The initial forking of webviz will let us know if the creation of a new visualization tool from scratch will be necessary.
• We will have to redesign the output of some nodes to log to a new console with various priority levels and be able to group outputs by node groups or specific keys. Being able to interpret outputs quickly will be important to quicker debugging.

Possible libraries:

• ros2_web_bridge and ros2_to_ros (If creating from scratch -- ros2_web_bridge, other wise convert ROS2 data to ROS interpretable data for webviz bridge)
• webviz (maybe fork this instead of using roslibjs? To save time)
• Worldview will be important for pointcloud/classified data, and perhaps using this for a more appealing map view.