hello, robot

온실 로봇은 길을 찾고, 작물을 보고, 팔을 움직이는 기능을 따로 붙이는 것으로 끝나지 않아요. 한쪽에서 만든 센서 관측과 좌표가 다른 쪽의 계획으로 이어지고, 그 결과가 다시 기체 상태로 돌아와야 합니다. Agri-Sim은 이 연결을 Agri-Sim이라는 ROS2Unity 기반 플랫폼으로 묶은 논문이에요.

로봇 알고리즘보다 연결 경로를 먼저 시험했어요

논문이 겨냥한 대상은 토마토 온실에서 움직이는 이동형 양팔 수확 로봇입니다. Unity는 온실 장면, 강체 물리, 충돌, 가상 센서와 작업 상태를 맡고, ROS2 쪽은 위치 추정·경로 계획·조작 계획을 맡습니다. 논문은 RGB-D 카메라, LiDAR, IMU, 관절 상태와 충돌 상태를 Unity에서 ROS2로 보냅니다. 반대 방향에서는 이동 바퀴의 속도 명령, 팔의 관절 궤적, 그리퍼 명령이 Unity로 돌아갑니다.

이 구조에서 중요한 것은 센서 하나를 흉내 내는 일이 아니라, 관측·계획·실행이 같은 장면에서 끊기지 않는지 확인하는 일입니다. 목표 토마토의 자세는 Unity가 ROS2로 보내고, ROS2는 이를 MoveIt 2의 계획 좌표로 옮겨 충돌 검사를 한 뒤 관절 궤적을 돌려보냅니다. 논문은 이 과정을 인식 모델이나 경로 계획 알고리즘의 성능 대결이 아니라, 여러 구성 요소가 한 번의 작업 루프를 만들 수 있는지 보는 기능 검증으로 한정합니다.

Unity가 센서와 로봇 상태를 ROS2로 보내고 ROS2가 이동·관절·그리퍼 명령을 Unity로 돌려보내는 Agri-Sim 통신 구조
Unity와 ROS2 사이를 오가는 관측·상태·명령의 경로. 원문 그림 7을 본문에서 논평하는 범위로 인용했다
Agri-Sim의 양방향 Unity와 ROS2 통신 구조(출처: Shi 외, Agri-Sim)

좌표와 시간을 맞춰야 기능 루프를 검증할 수 있어요

Unity와 ROS2는 기본 좌표 관습이 달라요. 논문은 Unity의 오른쪽·위·앞 축을 ROS2의 앞·왼쪽·위 축으로 명시적으로 변환하고, 목표 자세·속도·충돌 위치까지 같은 변환 규칙을 적용합니다. TF 트리도 이 계약에 포함되므로, 화면에서는 맞아 보이는 팔이 계획기에서는 다른 방향으로 해석되는 문제를 줄일 수 있습니다.

시간도 같은 방식으로 다뤘어요. Unity 물리 시간 간격은 0.02초이고, 명목 물리 갱신은 50 Hz입니다. 센서와 명령의 양방향 발행은 10 Hz로 맞췄으므로 메시지 하나 사이에 물리 갱신이 약 다섯 번 일어납니다. 렌더링 프레임 속도가 아니라 시뮬레이션 시각을 기준으로 센서를 예약해, RGB-D, LiDAR, IMU, 관절과 TF 메시지의 시간 관계를 유지하려 한 점이 이 논문의 실질적인 설계 선택입니다.

로봇 시뮬레이터를 연결할 때는 메시지 통로의 이름만 맞추면 된다고 보기 쉽습니다. 좌표 변환은 TF 관계로, 메시지 시각은 공통 시뮬레이션 시계로 맞춰야 해요. 링크 계층·관절 제한·충돌 형상·관성은 같은 URDF를 공유해야 계획 결과가 실행 결과와 이어집니다. 이 문제는 UR10e에 SmolVLA를 올려 색상 편향까지 드러낸 ROS2SmolVLA가 정책과 하드웨어 사이의 제어 경로를 다룬 방식과도 닿아 있어요.

성공률은 연결의 범위를 보여줄 뿐입니다

온실 전체는 70×55×10 m, 작물 행은 160개로 만들었지만 실험에는 여섯 행만 켰습니다. 내비게이션은 목표 반경 250 mm 안에 충돌 없이 120초 안에 들어오면 성공으로 판정했고, 50회 중 45회가 성공해 90%가 나왔습니다. 시행별 궤적과 세부 실패 기록을 남기지 않았으므로, 이 성공률을 위치 정확도로 읽으면 안 됩니다.

양팔 수확은 궤적 생성, 첫 팔의 토마토 파지, 팔 사이 전달, 상자 배치까지 모두 끝나야 성공입니다. 50회 중 48회에서 모든 계획 요청의 궤적을 만들었고, 전체 수확 순서를 끝낸 것은 43회였습니다. 따라서 계획 성공률 96%와 전체 작업 성공률 86%는 같은 뜻이 아닙니다. 충돌 없는 궤적을 찾는 것과, 파지·전달·놓기를 끝내는 것은 서로 다른 실패 지점을 가진다는 점을 결과가 보여 줍니다.

다만 이 실험에는 명령이 갔다가 응답이 돌아오는 시간, 메시지 도착 간격의 흔들림, 대역폭, 전송 중 사라진 메시지를 재는 시험이 없습니다. 프레임 속도와 렌더링 시간 분포도 보고하지 않았고, 160행 전체 장면의 부하도 검증하지 않았습니다. 논문이 입증한 것은 정해진 하드웨어와 여섯 행 조건에서 메시지 루프가 작업을 수행했다는 사실이며, 실시간성의 보증은 아닙니다.

인식과 실기체 전이는 아직 남아 있어요

수확 실험의 토마토 자세는 Unity 장면에서 직접 제공됩니다. 그래서 이 결과에는 열매를 찾거나 자세를 추정하는 비전 모델의 실패가 들어가지 않습니다. 토마토 부착도 물리적 접촉력을 재는 대신 Unity 내부의 부착 사건으로 판정하며, 과실 변형·줄기 분리·손상·힘 제어는 현재 범위 밖이라고 저자들이 분명히 적었습니다.

가상 센서도 실제 장비를 완전히 재현한 것은 아닙니다. Sim-to-Real을 주장하려면 깊이 영상의 누락과 반사, LiDAR의 실제 주사 패턴, 조명과 작물의 변형, 실기체의 접촉까지 따로 평가해야 합니다. Agri-Sim은 그 전 단계인 인터페이스 통합과 반복 가능한 기능 시험을 제공하고, 전이 성능 자체는 아직 측정하지 않았습니다.

다음 실험은 실패를 다시 읽을 수 있게 남겨야 해요

이 논문의 설계는 시뮬레이터를 만들 때 측정 단위를 먼저 고정해야 한다는 쪽으로 읽힙니다. 성공·실패만 모으면 45/50과 43/50은 남지만, 왜 실패했는지는 나중에 복원할 수 없어요. 실행 식별자마다 입력 센서 시각, TF 최신성, 계획 요청·응답, 충돌 상태, 궤적 결과와 종료 사유를 함께 저장하면 좌표 문제·계획 문제·메시지 문제를 구분할 수 있습니다.

그 기록은 성능을 과장하려는 장식이 아니라 다음 조건을 고를 근거가 됩니다. 같은 조건에서 반복해도 계속 실패하면 로직이나 좌표 계약을 먼저 의심하고, 조명·행 배치·대상 위치에 따라 성공률이 갈리면 평가 조건을 분리해 보아야 해요. Agri-Sim은 온실 로봇의 모든 어려움을 해결한 결과가 아니라, 그 어려움을 한 루프 안에서 관찰하고 다시 시험할 수 있게 만든 기반으로 읽는 편이 정확합니다.


출처 — https://arxiv.org/abs/2608.29100