19.6.1.2. 다중 센서 중복(Redundancy) 구성 시(예: 듀얼 GPS) uORB 토폴로지 설계

19.6.1.2. 다중 센서 중복(Redundancy) 구성 시(예: 듀얼 GPS) uORB 토폴로지 설계

앞선 19.6.1.1 단원에서 인스턴스 ID의 동적 성질과 다중 방 분할의 철학을 깨우쳤다면, 이제 이 시스템 추상화를 실제 하드웨어 세계의 가장 크리티컬한 생존 아키텍처, 바로 **‘듀얼(Dual) / 트리플(Triple) 센서 중복(Redundancy) 토폴로지 설계’**로 뻗어 나가 적용해 볼 차례이다.

수천만 원을 호가하는 방제 드론이나 인명 구조용 군용 픽스호크 기체에는 생명선과도 같은 GPS 모듈이 절대 1개만 매달려 있지 않는다. 태양 흑점 폭발이나 주변의 강력한 전파 간섭(Jamming)으로 인해 메인 GPS 모듈이 ‘No Fix’ 상태로 뻗어버리는 끔찍한 순간, 기체의 목숨을 살려줄 두 번째 예비 GPS 칩셋이 CAN 버스나 시리얼(Serial) 포켓에 듀얼로 묶여 대기하고 있어야만 한다.
이 듀얼 GPS 생태계를 PX4 uORB 스케줄링 망 위에 가장 우아하게 안착시키는 다중 인스턴스 물리 토폴로지(Topology) 디자인 철학을 역해부해 보자.

1. 물리 데몬 독립성: 2개의 하드웨어, 2개의 퍼블리셔 데몬

하드웨어 엔지니어가 픽스호크 마더보드에 GPS A와 GPS B를 각기 다른 포트(예: Serial 1, Serial 2)에 납땜했다고 가정하자. 소프트웨어 엔지니어가 저지를 수 있는 가장 하급의 아키텍처 실수는 단 1개의 거대한 C++ 스레드 안에서 Serial 1과 Serial 2를 순차적으로 번갈아 가며 읽게(Polling) 묶어버리는 짓이다. 만약 Serial 1 포트가 칩셋이 타버려 블로킹 대기에 걸리게 되면, 멀쩡한 Serial 2 포트의 데이터까지 단 1줄도 읽히지 못한 채 통째로 병목에 걸려 데몬 전체가 완전히 멈춰버리기(Deadlock) 때문이다.

완벽한 페일세이프 토폴로지 설계는 **“물리적인 하드웨어가 2개라면, 메모리에 뜨는 C++ 퍼블리셔 데몬 워커 스레드도 완벽히 독립된 2개로 분리 결속해야 한다”**는 대전제에서 출발한다.

  • gps_driver_main 데몬 1호기 (메인 스레드 풀 탑승): Serial 1 포트를 독점 점유하여 죽어라 감시한다.
  • gps_driver_main 데몬 2호기 (메인 스레드 풀 탑승): Serial 2 포트를 독점 점유하여 죽어라 감시한다.

이 두 데몬은 커널 상에서 메모리를 공유하지 않으며 완벽히 독립적으로 움직인다. 한 놈이 커널 패닉으로 죽어 자빠져도, 다른 한 놈은 그 사실 자체를 모른 채 자신의 포트에서 들어오는 데이터를 묵묵히 처리한다.

2. VFS 링커의 충돌 없는 병합: uORB 다중 인스턴스 꼬리표(Instance Labeling)

이제 독고다이로 움직이는 저 두 개의 GPS 퍼블리셔 데몬들이 데이터를 읽어 들였을 때, 그 결과를 어떻게 VFS 링 버퍼에 뿌릴 것인가의 문제가 남는다. 이때 우리가 배운 **vehicle_gps_position**이라는 단일 공통 토픽 이름표망이 마법처럼 작용한다.

  1. **퍼블리셔 1호기 (GPS A)**가 부팅 직후 먼저 정신을 차려 orb_advertise_multi를 타격한다. 커널은 그에게 vehicle_gps_position의 Instance 0번 방 열쇠를 던져준다. 앞으로 1호기는 오직 0번 방에만 자신이 수확한 GPS 위성 데이터를 맹렬히 퍼붓는다.
  2. **퍼블리셔 2호기 (GPS B)**가 약간 늦게 부팅되어 orb_advertise_multi를 타격한다. 커널은 0번이 알박기 되어 있으므로 재빠르게 방을 하나 더 쪼개어 Instance 1번 방 열쇠를 2호기에게 준다. 2호기는 영원히 1번 방에만 데이터를 퍼넣는다.

이 토폴로지를 통해 커널 VFS 내부에는 서로 단 1비트의 락(Lock) 충돌도 없는 완벽히 분리된 2개의 GPS 링 버퍼(0번, 1번)가 동시에 독립적으로 요동치게 된다.

3. 블렌더 레이어(Blender Layer): 최상위 항법 EKF 모듈의 다중 멀티플렉싱

퍼블리셔단에서 듀얼 인스턴스 하드웨어 방폭 설계를 완벽하게 마쳤다면, 이제 가장 밑단에서 이 GPS 데이터를 먹고 기체의 좌표를 그려내야 하는 EKF 항법 제어 구독 데몬의 수신 토폴로지 설계가 시스템의 대미를 장식한다.

EKF 데몬은 자신이 섭취해야 할 vehicle_gps_position 토픽의 방이 시스템에 대체 몇 개나 쪼개져 열려있는지(예: 2개) orb_group_count를 때려 동적 개수를 확인한다. 그리고 자기가 배운 19.5 단원의 다중 px4_poll 감시 그물망 배열을 2칸짜리로 임시 생성하여 0번과 1번 방 모두에 수신 빨대 파이프를 동시에 양방향으로 교차 연결시켜 버린다.
이제 EKF 스레드는 0번 방과 1번 방 어디서든 새 GPS 프레임이 도착하면 즉각 깨어나 두 데이터의 HDOP(수평 오차율), Fix Type(3D 락킹) 등의 품질 메타데이터 스펙을 거칠게 C++ 로직 심사대 위에서 비교 평가(Voting)한다.
그리고 더 품질이 우수한 쪽의 배열 방 데이터를 실시간으로 메인 항법 변위를 계산하는 알고리즘 트랙에 밀어 넣는 **절대 무결점 선택기(Selector / Blender)**의 역할을 완벽히 수행해 낸다.

1호기 GPS가 대파되어 0번 방의 업데이트 주기가 Timeout으로 죽어버려도, EKF 데몬은 1번 방에서 계속 쏟아져 나오는 예비 GPS 데이터 스트림을 끊임없이 받아 씹으므로 시스템 모듈 아키텍처 전체에는 단 1초의 추락 패닉도 허용되지 않는 것이다.