18.1.2 uORB 설계 철학과 코어 요구사항

18.1.2 uORB 설계 철학과 코어 요구사항

로봇 미들웨어의 세계에는 이미 ROS 1의 TCPROS나 ROS 2의 DDS(Data Distribution Service)와 같이 산업계 표준으로 자리 잡은 훌륭한 시스템들이 존재한다. 그럼에도 불구하고 리눅스가 아닌 NuttX RTOS 기반의 PX4-Autopilot 생태계에서 독자적인 uORB (Micro Object Request Broker) 아키텍처를 고집하여 발전시킨 이유는 무엇일까?

이 질문에 대한 해답은 자원 제약이 극심한 임베디드 비행 제어기(FCC) 환경에서 자율 비행 소프트웨어가 충족해야만 하는 가혹한 코어 요구사항(Core Requirements) 속에서 찾을 수 있다.

1. 극단적인 경량화 (Micro-Footprint)

가장 흔히 사용되는 비행 제어 보드인 Pixhawk 시리즈(예: STM32F4/F7/H7 기반)의 메인 칩셋은 고작 수십~수백 메가헤르츠(MHz)의 클럭 속도와 1~2 메가바이트(MB) 수준의 RAM을 가진다.

  • 배경: 범용 DDS나 TCP/IP 기반의 미들웨어는 데이터 라우팅, 직렬화(Serialization), 네트워킹 스택 처리 과정에서 필연적으로 상당한 양의 동적 메모리 할당(malloc)과 CPU 오버헤드를 발생시킨다.
  • uORB의 철학: uORB는 이러한 오버헤드를 용납하지 않는다. uORB는 오직 단일 보드 내의 공유 메모리(Shared Memory) 상에서 단순한 포인터 오프셋과 memcpy() 수준의 메커니즘만으로 작동하도록 설계되었다. 구조체(struct) 형태 그대로 메모리를 복사하므로 직렬화/역직렬화 오버헤드가 제로(Zero-overhead)에 수렴한다.

2. 하드 실시간성(Hard Real-time)과 시간 결정론성(Determinism)

드론의 자세 제어는 수백 분의 1초만 지연되어도 기체가 뒤집어질 수 있는 하드 실시간 시스템(Hard Real-time System)이다.

  • 배경: 범용 운영체제(Linux) 환경의 IPC(Inter-Process Communication) 메커니즘은 커널의 스케줄링 상황이나 네트워크 스택 버퍼 상태에 따라 메시지 전달 시간이 크게 요동(Jitter)칠 수 있다. 즉, “언제 데이터가 도착할지” 확신할 수 없는 비결정론적(Non-deterministic) 특성을 갖는다.
  • uORB의 철학: uORB는 RTOS(NuttX)의 스케줄러와 깊숙이 통합되어 있다. 발행자(Publisher)가 데이터를 uORB 버퍼에 갱신하는 즉시, 인터럽트 방식이나 하드웨어 세마포어(Semaphore)를 통해 블로킹(Blocking) 상태로 대기하던 구독자(Subscriber) 스레드를 즉각적으로 기상(Wake-up)시킨다. 이는 마이크로초(μs) 단위의 지연 시간 결정론성을 완벽하게 보장한다.

3. 인터럽트 서비스 루틴(ISR) 대응의 안정성

가장 중요한 코어 요구사항 중 하나는, 데이터를 생산하는 주체가 일반적인 스레드(Thread)뿐만 아니라 인터럽트 문맥(ISR: Interrupt Service Routine) 이 될 수도 있다는 점이다.

  • 배경: 하드웨어 타이머나 외장 센서의 핀 변화(EXTI)에 의해 트리거되는 인터럽트 최상위 계층에서는 뮤텍스(Mutex) 입방아를 찧으며 락(Lock)을 획득하기 위해 대기(Sleep)할 수 없다.
  • uORB의 철학: uORB의 내부 링 버퍼(Ring Buffer) 쓰기 로직은 인터럽트 안전성(Interrupt-safe)을 보장하는 매우 짧은 임계 구역(Critical Section) 보호 기법(예: 일시적인 IRQ 마스킹)과 세대 카운터(Generation Counter)를 활용한 락프리(Lock-free) 읽기 메커니즘을 적용했다. 이 덕분에 어떤 하드웨어 드라이버라도 (심지어 가장 우선순위가 높은 인터럽트 핸들러 내에서도) 병목 없이 즉각적으로 데이터를 Publish하고 본연의 하드웨어 감시 임무로 복귀할 수 있다.

결과적으로, uORB의 설계 철학은 “무한한 유연성과 네트워크 확장성“을 추구하는 IT 업계의 미들웨어 패러다임을 정면으로 거부하고, 철저히 “단일 보드 내에서의 가장 빠르고(Fastest), 가장 가벼우며(Lightest), 가장 예측 가능한(Most Predictable) 데이터 교환 체계“를 구축하는 데 모든 초점이 맞추어져 있다.