Great proposal. Reducing the transport overhead of PointCloud2 is crucial for avoiding ‘network congestion’ that eventually poisons the entire control loop.
In my tests with ros2_kinematic_guard, I’ve noticed that when DDS struggles with high-bandwidth sensors (like your Lidar case), the first victim is often the timing consistency of /cmd_vel. Even if we move to a leaner LidarScan format, transient wireless jitter will still exist.
My project handles the ‘physical’ consequence of the issues you described: when those 2D grid packets eventually burst or arrive stale, the Guard ensures they don’t turn into dangerous robot motions. Looking forward to seeing this new message type—it would certainly make the ‘Command-vs-Odom’ consistency check much more predictable by reducing RMW-level overhead.