센서마다 데이터율부터 계산한다
연산을 어디에 둘지 정하려면 먼저 얼마나 자주, 얼마나 많이 흐르는지를 숫자로 알아야 한다. 주기와 1회 전송량만 있으면 데이터율은 바로 나온다.
$$ Time(ms) = \frac{1}{Frequency(kHz)}, \qquad 데이터율 = \frac{1회;전송량}{주기} $$
| 센서 | 주기 | 1회 데이터 | 데이터율 |
|---|---|---|---|
| 바퀴 엔코더 (2륜) | $1kHz = 1ms$ | 카운터 4B × 2륜 = 8B | $8kB/s$ |
| IMU | $200Hz = 5ms$ | $(a_x, a_y, a_z, \omega_x, \omega_y, \omega_z)$ 각 4B + timestamp 8B = 32B | $6.4kB/s$ |
| 2D Lidar | $10Hz = 100ms$ | 360점 × (거리 4B + 세기 4B) = 2880B | $28.8kB/s$ |
| RGB 카메라 (1080p) | $30fps = 33ms$ | $1920 \times 1080 \times 3 = 6.22MB$ | $186.6MB/s = 1492.8Mbps$ |
| LTE 업링크 (Cat4) | - | 규격 50Mbps, 실측 5~20Mbps | 왕복 지연(RTT) 30~100ms |
- 카메라 한 대가 나머지 전부의 4000배를 만든다. 문제는 언제나 카메라다
연산 분담 — 무엇을 어디에 둘 것인가
배치 기준은 두 개뿐이다. 마감을 지킬 수 있는가(지연 예산), 보낼 수 있는 양인가(데이터양).
| 작업 | 위치 | 지연 예산 | 데이터양 | 근거 |
|---|---|---|---|---|
| 모터 속도 제어 | 임베디드 | ≤ 1ms | 8kB/s | 엔코더 주기 자체가 1ms. 네트워크를 한 번이라도 타면 이 주기를 못 지킨다 |
| 장애물 감지 | Edge AI | ≤ 100ms | 28.8kB/s | 라이다 주기 100ms. 클라우드 왕복(30~100ms)을 끼우면 정지거리가 늘어난다 |
| 보행자 인식 | Edge AI | ≤ 100ms | 186.6MB/s (원시) | 원시 영상을 보낼 수 없으니 계산이 데이터 옆으로 가야 한다 |
| 지도 기반 경로 계획 | 클라우드 | ≤ 1~2s | pose·목적지 수백 B | 재계획이 늦어도 로봇은 기존 경로를 계속 따라간다. 전역 지도·교통 정보는 클라우드에만 있다 |
| 배달 완료 사진 업로드 | 클라우드 | ≤ 수십 초 (비동기) | JPEG 0.5~1MB | 주행과 무관. 실패하면 재시도하면 된다 |
| 운행 로그 집계 | 클라우드 | 분~시간 (배치) | 수 kB/s | 사후 분석용. 실시간성이 아예 없다 |
Why — 배치표를 채우다가 클라우드 항목의 지연 예산을 전부
?로 비워둔 채 넘어갔다. 임베디드 1ms, Edge 100ms는 센서 주기를 그대로 옮겨 적은 것뿐이고, “그럼 클라우드는 몇 초까지 괜찮은데?“에 답할 근거가 없었다. 지연 예산이라는 숫자가 어디서 오는지를 몰랐던 거다.How — 제동거리 공식에 지연 동안 그냥 굴러가는 거리를 더해봤다. 보도 주행 속도 $v = 1.5m/s$, 감속도 $a = 1.5m/s^2$로 놓으면 제동거리는 $v^2/2a = 0.75m$다. 여기에 감지부터 제동까지의 지연 $t$ 동안 $v \cdot t$만큼 더 간다 — 100ms면 0.15m, 클라우드 왕복 100ms를 끼우면 0.3m가 추가돼 정지거리가 0.75m에서 1.2m로 늘어난다. 60%가 늘어나는 셈이다.
What — 지연 예산은 “적당히 빠르게"가 아니라 물리에서 역산되는 값이었다. 안전 경로(감지 → 제동)에 걸린 작업은 정지거리가 곧 예산이고, 그래서 네트워크를 못 탄다. 반대로 경로 계획·사진 업로드·로그는 늦어도 로봇이 멈추지 않는 일들이라 초 단위 예산을 줘도 된다. 위치를 정하는 건 계산량이 아니라 마감이다.
카메라 원시 영상은 왜 LTE로 못 보내나
$$ 1920 \times 1080 \times 3 = 6.22MB/frame,\quad \times 30fps = 186.6MB/s = 1492.8Mbps $$
- LTE Cat4 실측 업링크를 10Mbps로 잡으면 필요량이 약 150배 초과한다. 규격 최대 50Mbps로 잡아도 30배다
- 즉 원시 영상 전송은 “조금 부족"이 아니라 자릿수가 다른 부족이다
Why — 계산으로 “LTE로는 못 보낸다"까지는 나왔는데, 그러면 카메라를 대체 어떻게 쓰라는 건지에서 막혔다. 못 보낸다는 결론만 있고 그 다음이 없었다.
How — 카메라 용도를 실시간 인지와 사후 증빙 두 가지로 쪼개니 답이 갈렸다. 실시간 인지는 원본을 보내는 대신 엣지에서 추론하고 결과만 보낸다 - 보행자 박스 몇 개면 수백 바이트라 라이다 28.8kB/s보다도 작다. 배달 완료 사진은 JPEG로 압축하면 6.22MB가 0.5 ~ 1MB가 되고, 어차피 비동기라 실패하면 재시도하면 된다. 원격 관제로 화면을 봐야 하면 H.264로 4~8Mbps 정도에 맞춰 스트리밍한다.
What — 내가 쓴 문장이 틀렸다. “카메라는 클라우드로 못 보낸다"가 아니라 **“원시 픽셀을 실시간으로 못 보낸다”**가 맞다. 대역폭 문제는 파이프를 키워서가 아니라 보낼 데이터의 형태를 바꿔서 푼다 — 픽셀 대신 의미(추론 결과), 실시간 대신 비동기, 무손실 대신 압축. 그래서 Edge AI라는 계층이 존재하는 거였다.
인지 → 판단 → 제어 계층과 주기
로봇은 하나의 루프로 도는 게 아니라 주기가 다른 루프 여러 개가 겹쳐서 돈다. 빠른 루프는 느린 루프를 기다리지 않는다.
| 계층 | 하는 일 | 입력 | 주기 | 위치 |
|---|---|---|---|---|
| 인지 (Perception) | 센서 원시값 → 세상의 상태 | 라이다 10Hz, 카메라 30Hz, IMU 200Hz | 10~30Hz | Edge AI |
| 판단 (Planning) | 상태 → 어디로 갈지 | 인지 결과 + 지도 | 지역 경로 10Hz / 전역 경로 0.5~1Hz | Edge AI + 클라우드 |
| 제어 (Control) | 목표 속도 → 모터 전류 | 엔코더 1kHz | 100Hz~1kHz | 임베디드 |
- 위로 갈수록 느리고 똑똑하고, 아래로 갈수록 빠르고 단순하다. 그리고 아래로 갈수록 실패가 치명적이다
- 상위가 죽어도 하위는 계속 돌아야 한다 — 인지가 멈추면 마지막 명령을 붙들고 감속·정지하는 게 임베디드의 몫이다
Hard / Firm / Soft — 마감을 넘기면 무슨 일이 생기나
| 작업 | 분류 | 마감 초과 시 결과 |
|---|---|---|
| 모터 속도 제어 | Hard | 제어 루프가 발산해 불안정. 급격한 전류 변동으로 하드웨어 손상 |
| 장애물 감지 | Hard | 제동 시작이 늦어져 정지거리가 늘고, 그대로 충돌 |
| 보행자 인식 | Firm | 늦은 결과는 버린다. 몇 프레임 놓쳐도 라이다 기반 장애물 감지가 받쳐준다 |
| 지도 기반 경로 계획 | Firm | 재계획 결과가 늦으면 폐기하고 기존 경로 유지. 돌아가게 될 뿐 사고는 아니다 |
| 배달 완료 사진 업로드 | Soft | 늦어도 가치가 남는다. 재시도하면 됨 |
| 운행 로그 집계 | Soft | 배치로 몰아서 처리해도 무방 |
세 분류의 차이는 마감을 넘긴 결과의 가치로 갈린다. Hard는 가치가 음수가 되고(늦은 정답은 정답이 아니라 사고다), Firm은 0이 되며(그냥 버린다), Soft는 줄어들 뿐이다. 그래서 Hard 작업은 평균 지연이 아니라 **최악 지연(WCET)**으로 설계해야 한다 — 평균 0.5ms인데 가끔 3ms가 나오는 시스템은 1ms 마감을 지키는 시스템이 아니다.
주기 · 지연 · 지터
셋 다 시간에 관한 말이라 섞어 쓰기 쉬운데, 재는 대상이 전혀 다르다.
| 용어 | 무엇을 재나 | 이 로봇에서는 |
|---|---|---|
| 주기 (Period) | 같은 일이 반복되는 간격 | 라이다 100ms가 사실상 로봇의 인지 주기를 정한다 |
| 지연 (Latency) | 원인이 결과로 이어지기까지 걸린 시간 | 라이다·카메라에 장애물이 잡힌 순간부터 모터에 제동 신호가 가기까지 |
| 지터 (Jitter) | 주기나 지연의 흔들림(편차) | 1ms마다 돌아야 할 제어 루프가 0.9ms, 1.3ms로 들쭉날쭉한 정도 |
- 주기가 짧다 ≠ 지연이 짧다. 30fps 카메라라도 인지가 80ms 걸리면 지연은 80ms 이상이다. 파이프라인이 길면 주기는 빨라도 결과는 늦게 나온다
- 지터가 제일 조용한 살인자다. 평균은 멀쩡한데 제어 주기가 흔들리면 미분항이 튀면서 진동이 생긴다. 그래서 임베디드 제어는 처리량이 아니라 예측 가능성을 산다 — 리눅스 대신 RTOS나 MCU를 쓰는 이유
정리
오늘 배운 건 결국 “로봇의 아키텍처는 물리가 정한다” 한 줄로 꿰인다.
- 배치의 출발점은 취향이 아니라 계산이다. 주기와 1회 전송량으로 데이터율을 내면 엔코더·IMU·라이다 합이 43.2kB/s, 카메라 혼자 186.6MB/s — 어디가 병목인지가 표 하나로 드러난다.
- 지연 예산은 제동거리에서 역산된다. $v=1.5m/s$, $a=1.5m/s^2$면 제동거리 0.75m인데, 클라우드 왕복 100ms를 끼우면 정지거리가 1.2m로 늘어난다. 안전 경로가 네트워크를 못 타는 이유가 이 숫자다.
- 대역폭 부족은 파이프를 키워서 푸는 게 아니라 보낼 데이터의 형태를 바꿔서 푼다. 픽셀 대신 추론 결과, 실시간 대신 비동기, 무손실 대신 압축 — Edge AI 계층은 이 요구에서 나온 구조다.
- Hard/Firm/Soft는 계산량이 아니라 마감을 넘겼을 때 가치가 음수인가, 0인가, 줄어들 뿐인가로 갈린다. Hard는 평균이 아니라 최악 지연으로 설계한다.
- 주기·지연·지터는 다른 것을 잰다. 주기가 빨라도 지연이 길 수 있고, 평균 지연이 좋아도 지터가 크면 제어는 무너진다.