Native ROS 2 Remote Development Instead of VNC
The M3 Pro's local display and camera experience were usable. VNC was not good enough to become my normal development workflow.
At first I treated that as a remote-desktop problem.
Then the architecture looked backwards.
ROS 2 is already a distributed system. Instead of rendering tools on the Jetson and sending desktop pixels across the network, the robot should publish its state and my workstation should consume it directly.
The setup I want to validate is:
M3 Pro / Jetson
LiDAR
camera
odometry
TF
battery
navigation state
|
| ROS 2 / DDS
v
Ubuntu PC / RTX 4090
RViz
ROS CLI
debugging
visualization
development
The immediate experiment is to see whether the RTX 4090 Ubuntu workstation can reliably discover and subscribe to the M3 Pro's existing ROS 2 topics.
I want to test this progressively:
- ROS 2 discovery
- basic topics
- TF and odometry
- LiDAR
- camera streams
- RViz running locally on the workstation
- QoS behavior
- latency and bandwidth
- long-running stability
Possible complications include DDS discovery, multicast, ROS_DOMAIN_ID, firewalls, Wi-Fi bandwidth, QoS mismatches, and camera-stream volume.
I do not want to assume the architecture works merely because ROS 2 supports distributed nodes. I want to prove it on this hardware and network.
Why this becomes a Physical AI question
If this works, the next question is no longer only about remote visualization.
It becomes:
Which workloads belong on the Jetson, and which can move to the RTX 4090?
The Jetson should eventually own work that needs to stay with the robot: hardware interfaces, local control, low-latency sensing, and behavior that must survive network loss.
The larger workstation can potentially handle simulation, large-model experimentation, heavier perception, and future VLM/VLA workloads.
This is the first small version of a much larger edge-versus-external-compute architecture problem.