수정 전에 공장 기본 상태를 보존하기
로봇이 조립되고 접속도 가능해지자 벤더 소프트웨어를 바로 바꾸고 싶은 유혹이 생겼다.
하지만 그렇게 하지 않기로 했다.
더 좋은 첫 번째 milestone은 정상 동작이 확인되고 복구 가능한 baseline을 만드는 것이다.
내 규칙은 이렇게 정리됐다.
reference system을 없애기 전에 먼저 이해하고 보존한다.
즉, 로봇이 아직 공장 상태에 가까울 때 주요 하드웨어와 소프트웨어 경로를 확인한다.
- drive system
- robotic arm
- LiDAR
- camera
- display
- Jetson
- robot controller
- networking
- battery telemetry
- ROS nodes and topics
- packages and launch files
- TF relationships
단순히 벤더 데모를 실행하는 대신 ros2 node list, ros2 topic list, package/launch-file 검색 같은 도구로 ROS 2 환경을 직접 살펴보기 시작했다.
작지만 유용한 확인 중 하나는 배터리 telemetry였다. 충전 전 /battery 값이 약 11.05 V였고, 이후 충전 후에는 약 12.30 V를 확인했다. 물리적인 상태가 ROS를 통해 소프트웨어에서 관찰 가능한 상태로 바뀌는 초기 사례였다.
실험보다 먼저 백업
컴포넌트 테스트가 끝나면 단순히 workspace를 복사하는 것이 아니라 Jetson 저장장치 전체를 복구 가능한 이미지로 남길 계획이다.
원래 Linux, NVIDIA 소프트웨어, driver, ROS 환경, vendor package, system configuration을 보존해 이후 실험을 되돌릴 수 있게 하는 것이 목적이다.
의도한 사이클은 단순하다.
known-good baseline
↓
full-system backup
↓
experiment
↓
break something
↓
understand why
↓
recover if necessary
이것은 구매 전부터 생각했던 보안 목표에도 연결된다. 벤더의 reference environment는 보존하면서도 package, service, network behavior를 내가 점점 더 이해하는 시스템으로 이동할 수 있다.
원격 접속도 인프라다
SSH는 사용할 수 있었지만 authentication 구성을 개선하는 과정에서 ownership/permission 문제도 만났다. 로봇 엔지니어링에도 여전히 일반적인 platform engineering이 포함된다는 또 하나의 reminder였다. Linux permission, identity, networking, deployment, recovery가 안정되지 않으면 autonomy도 큰 의미가 없다.