19.6.3. 다중 인스턴스 구독(Subscriber) 구현

퍼블리셔 데몬들이 각자의 치열한 자리싸움 끝에 커널로부터 0번, 1번, 2번 방을 순서대로 할당받아 vehicle_gps_position의 다중 인스턴스 파이프라인 우주를 찬란하게 구축해 놓았다면, 이제 반대편에서 이 거대한 분할 데이터망을 수신하고 융합해야 하는 19.6.3 단원의 ‘다중 인스턴스 구독자(Multi-instance Subscriber)’ 데몬의 무자비한 하베스팅(Harvesting) 구현 단계로 돌입한다.

과거 단일 인스턴스 튜토리얼에서 썼던 맹목적인 orb_subscribe(ORB_ID(topic)) API는 앞서 말했듯 무조건 **“0번 방만 맹목적으로 연결해 줘”**라는 치명적인 하드코딩 독약과 같다.
다중 중복 센서가 판을 치는 실전 비행 제어기 보드에서 이 옛날 함수를 그대로 쓰게 되면, 당신의 모듈은 VFS에 멀쩡히 살아 숨 쉬는 우수한 품질의 1번 메인 센서 방을 깡그리 무시한 채, 부팅이 빨라 운 좋게 0번 방을 선점한 쓰레기 싸구려 예비 센서의 노이즈 가득한 데이터만을 영원히 빨아먹다가 곧바로 추락하게 된다.

따라서 진정한 코어 다중 인스턴스 통합 아키텍트는 철저히 능동적(Active)이고 병렬적인 관점에서 VFS를 융단 폭격하듯 수색해야만 한다. 이 수색과 포획 작전을 위해 PX4 미들웨어는 구독자에게 다음과 같은 세 가지 치명적인 하위 아키텍처 스킬 트리를 요구한다.

• 1. 핀셋 포획 타격 (orb_subscribe_multi): 내가 찾고자 하는 특정 인스턴스 번호(ID)를 명확히 지목하여 정확히 그 파이프의 꼬리에만 단독으로 수신 인터럽트 호스를 꽂아 개통하는 기술. (19.6.3.1 단원 타설 예정)
• 2. VFS 우주 전수 조사 (orb_group_count & Iteration): 도대체 시스템이 켜지고 나서 저 파편화된 건너편 퍼블리셔들이 vehicle_gps_position이라는 이름표 밑에 총 몇 개의 방을 쪼개 만들었는지(Count) 런타임에 동적으로 개수를 역추산해 내고, 0번부터 N번 방까지 모조리 문을 열고 들어가 각 방의 데이터 생존 상태를 크롤링하는 전체 순회(Iteration) 탐색 기술. (19.6.3.2 단원 타설 예정)
• 3. 하드웨어 바인딩(Binding) 및 품질 융합 통제: 단순히 데이터가 있다고 먹는 것이 짐승이 아니라면, “0번 방 데이터는 SPI 버스 센서인가 I2C 센서인가?”, “에러 카운트가 몇인가?“를 실시간 점수(Voting) 매겨, 최종적으로 단 1개의 무결점 항법 데이터를 추출해 내어 메인 필터에 쑤셔 넣는 마에스트로 브레인 로직. (19.6.3.3 단원 타설 예정)

이 세 단계를 완전히 지배하는 순간, 당신의 제어 모듈은 어떤 센서 하드웨어가 비행 중 물리적으로 부서지고 타버리더라도, 흔들림 없이 다음 랭킹의 예비 센서 버퍼망으로 매끄럽게 호흡을 넘기는(Hot-swapping) 궁극의 불멸 페일세이프(Failsafe) 아키텍처를 완성하게 된다.