18.3.3.2 최대 허용 인스턴스 수(ORB_MULTI_MAX_INSTANCES)의 메모리 제약적 이유

uORB의 다중 인스턴스(Multi-instance) 기능은 센서 이중화를 위해 완벽한 메커니즘을 제공하지만, 무한정으로 센서를 증설할 수 있는 것은 아니다. PX4의 소스 코드를 열어보면 ORB_MULTI_MAX_INSTANCES 매크로가 하드 코딩(Hard Coding)되어 있으며, 기본적으로 그 값은 4로 설정되어 있다.

즉, 동일한 타입의 센서(예: sensor_accel)는 기체당 최대 4개까지만 활성화될 수 있다. 왜 이런 한계를 두었을까? 그 근본적인 원인은 마이크로컨트롤러(MCU) 환경의 치명적인 메모리(RAM) 제약과 운영체제의 비트 플래그(Bit Flag) 최적화 설계에 맞닿아 있다.

1. 비트맵(Bitmap) 기반 구독자 상태 관리

NuttX와 uORB는 각 구독자(Subscriber)가 특정 토픽의 어떤 인스턴스를 구독하고 있는지, 혹은 어떤 인스턴스의 데이터가 업데이트되었는지 빠르게 마킹(Marking)하기 위해 32비트나 64비트 정수형 배열 대신 가장 가벼운 8비트 정수(uint8_t) 비트맵 마스크를 널리 사용한다.

인스턴스 개수가 4개로 제한된다면, 이 상태 정보를 저장하는 데 단 4비트(하위 0~3번 비트)만 소모하면 되므로 메모리 접근 단위(Byte/Word) 측면에서 계산 및 복사 오버헤드가 극도로 축소된다. 이 O(1) 비트 연산은 센서 데이터가 1000Hz로 쏟아지는 하드 리얼타임 루프에서 눈부신 성능 최적화를 이끌어낸다.

2. VFS 노드의 정적/동적 할당과 Sizing 문제

또 다른 결정적인 이유는 메모리 단편화(Memory Fragmentation) 리스크다.
가상 파일 시스템(VFS)에 /obj/sensor_accel0 부터 /obj/sensor_accel3 까지 등록된다는 것은, 커널 힙(Heap) 메모리에 각 노드를 관리하는 uORBDeviceNode C++ 객체와 그 속의 링 버퍼(Ring Buffer)가 각각 별도로 통째로 할당된다는 것을 의미한다.

픽스호크(Pixhawk) 시리즈의 핵심 두뇌인 STM32F4/F7/H7 계열 칩셋들은 RAM 용량이 불과 수백 킬로바이트(KB) 남짓이다. 수십 종류의 토픽이 존재하는데, 각 토픽마다 인스턴스 제한을 10개, 20개로 풀어놓아 버리면, 의도치 않은 중복 드라이버 실행이나 버그로 인해 힙(Heap) 메모리가 순식간에 고갈(OOM, Out of Memory)되어 기체가 공중에서 즉시 시스템 패닉(Panic) 상태에 빠지고 만다.

따라서 ORB_MULTI_MAX_INSTANCES = 4 는 “현실적인 센서 삼중화(Triple Redundancy) + 1개의 예비(Spare) 채널“을 안정적으로 커버하면서도, VFS 노드 테이블의 크기와 메모리 파편화를 극도로 통제하기 위해 설계자들이 타협한 가장 아름다운 물리적 리미트(Limit) 모델인 것이다.