### 0.0.1 통신 속도(Baudrate) 자동 감지 알고리즘 및 초기화 상태 머신

드론 조립자들이 겪는 가장 흔하면서도 치명적인 트러블슈팅 중 하나는 “GPS No Fix” 내지는 “GPS Not Found” 에러이다. 하드웨어 결함이 아님에도 시스템이 모듈을 인식하지 못하는 십중팔구의 이유는, 비행 제어기(FC) 하드웨어 시스템에 사전에 약속된 직렬 보드레이트(Serial Baudrate)와 GPS 모듈 내부 플래시에 저장된 초기 보드레이트가 서로 엇갈렸기 때문이다.

이러한 수동 설정의 번거로움을 원천적으로 제거하기 위해, 최신 기종의 PX4-Autopilot은 src/drivers/gps/gps.cpp 내부에 매우 정교하고 집요한 Baudrate Auto-detection (통신 속도 자동 감지) 휴리스틱(Heuristics) 구조를 내장하고 있다.

0.1 Auto-Baud 알고리즘의 필요성과 블라인드 스캐닝(Blind Scanning)

과거 Ardupilot 초기 버전이나 구형 상용 드론에서는 GPS 포트의 통신 속도를 파라미터(예: GPS_RATE = 38400)로 하드코딩(Hard-coding) 해두고, 사용자가 알아서 모듈을 해당 속도에 맞추어 프로그래밍해야만 통신이 붙었다.
그러나 Plug-and-Play (PnP) 철학을 지향하는 PX4 라인업에서는, 사용자가 어떤 제조사의, 어떤 속도로 출고된 GPS를 꽂더라도 FC가 스스로 속도를 탐색하여 ‘알아서’ 달라붙어야 한다.

만약 FC의 현재 직렬 포트 속도가 115200bps 이고 GPS 모듈이 내부적으로 9600bps로 문자를 쏘고 있다면, FC의 수신 버퍼(RX Data Register)에는 파편화된 가비지(Garbage) 바이트들만 무의미하게 쌓일 뿐이다. PX4는 이 가비지 속에서 아무런 유효 패킷이 파싱 되지 않을 경우, 즉각적으로 통신 속도가 엇갈렸음을 직감하고 **초기화 상태 머신(Initialization State Machine)**을 ’Auto-Baud 탐색 모드’로 직행시킨다.

0.2 초기화 상태 머신의 구조 및 단계별 폴링(Polling)

PX4의 GPS 드라이버 메인 루프는 시작과 동시 다음과 같은 단계적(Phased) 탐색 트리를 전개한다.

초기 파라미터 강제 시도:
먼저 QGroundControl 등을 통해 사용자가 고정 할당한 SER_GPSX_BAUD 파라미터가 비어있지 않다면(0이 아니라면), 제일 먼저 해당 속도로 tcsetattr POSIX API를 호출하여 직렬 포트를 열어본다. 여기서 약 1초 대기 후 정상 패킷이 들어오면 탐색 루틴은 즉시 종료된다.
계단식 속도 하향 스윕(Downward Sweep):
파라미터가 0(Auto)이거나 초기 시도에서 실패(Timeout)했다면, 가장 확률이 높은 고속 보드레이트부터 저속까지 순차적으로 훑어 내려간다.
통상적으로 탐색 배열은 { 115200, 38400, 57600, 9600, 230400 } 의 우선순위 순서(목록)를 가지며, PX4 제어기는 직렬 포트의 속도를 설정 배열 첫 번째 원소로 맞추고 약 0.5초에서 1초 동안 어둠 속에서 귀를 기울인다(Listening). 성공하면 스텝 종료, 실패하면 다음 원소로 넘어가 포트 하드웨어 레지스터를 재설정(tcsetattr)한다.
바이너리 및 ASCII 패킷 동시 프로빙(Probing):
각각의 속도 스텝에 머무는 동안, FC는 단순히 귀만 열어두는 것이 아니라 찔러보기(Probing) 동작을 병행한다. UBX 모듈을 깨우기 위해 바이너리 식별(Identification) 쿼리를 날려보고, 동시에 NMEA 문장도 수집해 본다. 만약 노이즈 속에서 NMEA의 $GPGGA 같은 헤더가 온전히 파싱되거나, 프로빙에 대한 UBX 펌웨어 버전 응답 메시지가 돌아온다면, 해당 타임 슬롯의 보드레이트가 ’정답’임을 확정(Lock-in)한다.

0.3 고속화(Step-up)를 향한 자동 재구성

가장 놀라운 메커니즘은 탐색 루틴이 정답 보드레이트를 찾아냈을 때 시작된다.

만약 상태 머신이 스와이프를 거듭하다 가장 하위 스텝인 9600 bps에서 겨우 모듈을 찾아내 파싱에 성공했다고 가정하자.
PX4는 이 9600 bps 속도에 아쉬워하며 안주하지 않는다. 10Hz 속도의 3D 측위를 9600 bps 통로로는 감당할 수 없음을 커널은 알고 있기 때문이다.
즉시 FC 메인 루프는 9600 bps로 열려 있는 터널을 통해 UBX-CFG-PRT (포트 설정) 제어 메시지를 쏘아보낸다. “너의 포트 속도를 강제로 115200 bps(또는 그 이상)로 상향 조절하라“는 명령어다.
이 명령을 수신한 모듈이 즉각적으로 자신의 하드웨어 칩셋 통신 속도를 높이는 그 짧은 순간, PX4 FC 역시 자신의 통신 포트를 빠르게 닫고 115200 bps로 다시 열어제치며 재결합(Re-connect)한다.

이 일련의 극한적 타협과 고집스러운 속도 최적화(Step-up) 과정이 기체 전원을 인가한 뒤 불과 3~4초 내외에 보이지 않는 백그라운드 런타임에서 자동으로 완수되는 것이다.