VNC 대신 네이티브 ROS 2 원격 개발
M3 Pro의 로컬 디스플레이와 카메라 사용성은 괜찮았다. 하지만 VNC는 일상적인 개발 방식으로 쓰기에는 충분하지 않았다.
처음에는 이것을 remote desktop 문제라고 생각했다.
그런데 생각해보니 아키텍처가 거꾸로 되어 있었다.
ROS 2 자체가 이미 분산 시스템이다. Jetson에서 도구를 렌더링하고 desktop pixel을 네트워크로 보내는 대신, 로봇이 자신의 상태를 publish하고 내 워크스테이션이 그것을 직접 consume하는 편이 더 자연스럽다.
검증하고 싶은 구조는 다음과 같다.
M3 Pro / Jetson
LiDAR
camera
odometry
TF
battery
navigation state
|
| ROS 2 / DDS
v
Ubuntu PC / RTX 4090
RViz
ROS CLI
debugging
visualization
development
즉시 해보고 싶은 실험은 RTX 4090 Ubuntu 워크스테이션이 M3 Pro의 기존 ROS 2 topic을 안정적으로 discover하고 subscribe할 수 있는지 확인하는 것이다.
다음 순서로 단계적으로 시험하려고 한다.
- ROS 2 discovery
- 기본 topic
- TF와 odometry
- LiDAR
- camera stream
- 워크스테이션에서 로컬로 실행하는 RViz
- QoS behavior
- latency와 bandwidth
- 장시간 안정성
문제가 될 수 있는 요소는 DDS discovery, multicast, ROS_DOMAIN_ID, firewall, Wi-Fi bandwidth, QoS mismatch, camera stream volume 등이다.
ROS 2가 분산 node를 지원한다는 이유만으로 이 구조가 잘 작동할 것이라고 가정하고 싶지는 않다. 실제 하드웨어와 네트워크에서 증명하고 싶다.
이것이 왜 Physical AI 문제가 되는가
이 구성이 잘 작동하면 다음 질문은 단순한 원격 시각화를 넘어선다.
어떤 workload가 Jetson에 있어야 하고, 어떤 workload를 RTX 4090으로 옮길 수 있을까?
Jetson은 결국 하드웨어 인터페이스, 로컬 제어, 저지연 sensing, 네트워크가 끊겨도 유지되어야 하는 동작처럼 로봇에 붙어 있어야 하는 일을 맡아야 한다.
더 큰 워크스테이션은 simulation, 대형 모델 실험, 더 무거운 perception, 그리고 미래의 VLM/VLA workload를 맡을 수 있다.
이것은 훨씬 큰 edge-vs-external-compute 아키텍처 문제의 첫 번째 작은 버전이다.