19.6.3.1. `orb_subscribe_multi()`를 활용한 특정 인스턴스 지정 구독

19.6.3.1. orb_subscribe_multi()를 활용한 특정 인스턴스 지정 구독

다중 인스턴스의 토폴로지 전장에서 개발자가 맞닥뜨리게 될 구독자 데몬 설계의 첫 번째 장벽은 바로 **“수많은 중복 센서 방들 중에서, 정확히 핀포인트로 내가 원하는 특정 방(Instance) 꼬리에만 수신 파이프라인(FD) 빨대를 어떻게 꽂을 것인가?”**이다.

이 절대적인 핀셋 구독을 커널 스케줄러에 청원하는 명령 래퍼가 바로 orb_subscribe_multi() 함수이다. 과거 단 하나의 파라미터(ORB_ID)만을 무식하게 넘기며 0번 방만을 강제 구인했던 낡은 orb_subscribe()와 달리, 멀티 버전 API는 내가 노골적으로 요구하는 인스턴스 번호를 직접 두 번째 인자로 넘겨 VFS 노드의 정확한 분기점(Branch)을 폭력적으로 관통 개통해 낸다.

1. 명시적 핀셋 락온(Lock-on): orb_subscribe_multi 타설 아키텍처

만약 시스템 부팅 과정에서 이미 여러 퍼블리셔 데몬들이 0, 1, 2번 방을 모두 차지해두었다고 극한 가정해 보자. 내 구독자 데몬 코드는 아주 오만하고 자립적으로 “나는 저 쓰레기 0번 메인 센서 데이터를 믿지 않아! 나는 오직 내가 신뢰하는 1번 예비 보조 센서 방(Instance 1)의 생짜 데이터만을 먹겠다!“라고 하드코딩된 선택 결론을 내릴 수 있다.

이때 커널 링 버퍼에 빨대를 꽂는 C API 코어를 단 한 줄로 아래와 같이 타격한다.

#include <uORB/uORB.h>
#include <uORB/topics/vehicle_gps_position.h>

// 1. [핀셋 구독 핸들의 타설] 특정 인스턴스 파이프를 가리킬 고유 파일 디스크립터(FD) 텍스트 명 선언
int gps_sub_instance_1_fd = -1;

// 2. [명시적 커널 청원 타격] orb_subscribe_multi 함수 호출
// - 첫 번째 인자 ORB_ID: 내가 접근하길 원하는 거시적인 토픽 우체통 이름표 (예: GPS 메타데이터)
// - 두 번째 인자 1 (Instance ID): 그 수많은 쪼개진 방들 중 '정확히' 1번 방(Instance 1)의 마스터 키를 다오!
gps_sub_instance_1_fd = orb_subscribe_multi(ORB_ID(vehicle_gps_position), 1);

// 3. 개통 방어막 레이더 기지 확보
if (gps_sub_instance_1_fd < 0) {
    PX4_ERR("Failed to forcefully subscribe to GPS Instance #1. Buffer may not exist yet.");
    // 구독 실패. 해당 인스턴스 방이 시스템에 아직 생성되지 않았거나, 파일 디스크립터 고갈 등 커널 오류 발생 상황!
} else {
    PX4_INFO("Successfully locked on to GPS Instance #1 FD: %d", gps_sub_instance_1_fd);
}

2. 동적 매체 의존성의 치명적 딜레마와 C++ 래퍼(Wrapper) 클래스 한계

위처럼 숫자를 1로 못 박아 핀셋 개통하는 하드코딩 방식은, 내가 디버깅 테스트를 위해 임시로 특정 칩셋 데이터망을 무작정 노리고 싶을 때만 사용하는 아주 하급의 단순 스크립트 작성에 불과하다. 19.6.1.1 단원에서 누차 지적했듯, 실제 양산 기체가 공중에 떴을 때 저 1번 방에 내가 그토록 신뢰하던 보조 GPS 칩셋 데이터가 정확히 잘 들어가 있다고 누가 물리적으로 100% 보장한단 말인가?

게다가 앞선 19.5.3 단원에서 우리가 환호하며 이식했던 궁극의 C++ 최적화 모던 객체 uORB::SubscriptionCallbackWorkItem 클래스 생성자를 생각해 보라. _sensor_sub{this, ORB_ID(sensor_test_data)} 처럼 설계된 이 하이엔드 래퍼 클래스는 태생적으로 다중 인스턴스의 핀셋 번호를 동적으로 끼워 넣는 백도어 생성자 문법의 런타임 한계를 가지고 있다 (주로 단일 0번 방이나, Default 인스턴스만을 무식하게 자동 추종해 캡슐화시켜 버린다).

이 끔찍한 객체 지향의 동적 매체 한계와 1차원적인 핀셋 락온의 문제를 동시에 박살 내기 위해, 비행 제어기 코어 아키텍트는 저 무작위의 orb_subscribe_multi 함수를 무한 for 루프 속에 가두어 버린 뒤, “도대체 시스템 전체에 몇 개의 인스턴스 방이 있는가?“를 실시간으로 세어보고 0번 방부터 N번 방 끝까지 싹 다 동적으로 모조리 구독 개통 폭격을 때려버리는(Aggregating Iteration) 궁극의 전수 조사 아키텍처로 넘어가야만 한다. 그 거대하고 포악한 전체 순회 논블로킹 검색망 타설법이 바로 이어지는 19.6.3.2 단원의 피의 해부 대상이다.