[Drone] FC와 Ardupilot/PX4

드론 제어 시스템을 구축하는데 드론에 대한 공부가 부족한 것 같아서 스스로 이해하고 있는 내용을 적어보고 계속해서 보완해 볼 예정입니다. 회사에서 선배님들께 들은 용어들 적어놓고 추가적으로 공부해서 계속해서 업데이트 할 예정.  제품개발부에서 들은 하드웨어 용어도 다시 점검할 예정!

---

1. FC (Flight Controller) 란

드론 안에는 비행 컨트롤러 (Flight Controller, FC)라는 손바닥보다 작은 회로 기판(보드)가 들어있다.
자이로, 가속도계, 기압계, GPS와 같은 센서가 여기에 연결되고, 모터로 나가는 출력도 여기서 나온다.

- 비유 : FC는 드론의 소뇌와 가깝다. "기체가 3도 기울었다. -> 왼쪽 모터 출력을 살짝 높인다." 와 같은 판단을 초당 수백 번씩 자동으로 한다.
- 사람이 걸을 때 넘어지지 않으려고 무의식적으로 균형을 잡는 일을 FC가 대신 해준다고 생각하면 된다.

캐리어 보드 (carrier board)란?
Pixhawk 같은 FC는 보통 캐리어 보드 (베이스 보드) 위에 꽂힌다.
FC 본체 = 센서 및 연산 담당 핵심 모듈, carrier board = 전원 분배와 각종 포트 (GPS, 텔레메트리, 모터 신호선) 연결 담당
비유하자면 FC = CPU 모듈, carrier board = 메인 보드 같은 느낌

FC vs 펌웨어

FC는 하드웨어 (보드)이고 그 위에서 도는 소프트웨어 (펌웨어)가 따로 있다.

구분	비유	설명
FC 보드	서버(물리 머신)	센서·연산·출력을 담당하는 하드웨어
펌웨어	그 서버에 설치하는 OS	하드웨어를 직접 제어하는 소프트웨어 = ArduPilot / PX4

같은 보드에 ArduPilot을 깔 수도, PX4를 깔 수도 있다. 마치 같은 서버에 Ubuntu를 깔 수도, Debian을 깔 수도 있는 것처럼.

펌웨어(firmware)란? software(무른)와 hardware(딱딱한)의 중간(firm). 일반 앱은 OS 위에 여러 계층을 두고 돌지만, 펌웨어는 그 계층이 거의 없이 하드웨어에 딱 붙어 센서 값을 직접 읽고 모터 신호를 직접 만든다. 특정 하드웨어에 맞춰져 있고, 웬만해선 자주 안 바꾼다.

Pixhawk란

• FC = 카테고리 (드론의 뇌 역할을 하는 보드 일반, "노트북")
• Pixhawk = 그 카테고리의 대표 제품 브랜드 ("맥북")
• ArduPilot / PX4 = 그 위에 까는 펌웨어(OS 격)

Pixhawk가 사실상 표준처럼 자리 잡아서, FC를 말할 때 대명사처럼 쓰이곤 한다. (이름이 비슷한 PX4 펌웨어와 Pixhawk 보드는 초기 같은 프로젝트에서 갈라져 나온 형제지만, 지금은 별개다. Pixhawk 보드에 ArduPilot도 얼마든지 설치 가능.)

---

2. Ardupilot vs PX4

둘 다 오픈소스 autopilot 펌웨어이다. 같은 FC 보드에 골라서 설치한다.

	ArduPilot	PX4
성격	오래됨, 기능 방대, 커뮤니티 중심	상대적으로 모던, 기업/연구 친화, 구조가 깔끔
라이선스	GPLv3 (강한 카피레프트)	BSD (상업적으로 부담 적음)
지원 기체	멀티콥터·고정익·로버·잠수정 등 매우 광범위	주로 드론(멀티콥터·VTOL) 중심
개발자 관점	설정 옵션이 많고 "뭐든 된다" 스타일	코드가 모듈화되어 있고 정돈된 스타일

- Ardupilot =  방대한 기능, 뭐든 되고 옵션이 많음
-      PX4     = 구조가 깔끔한 잘 설계된 프레임워크

+) 라이선스가 왜 실무적으로 중요한가?

• ArduPilot(GPL): 소스를 수정하면 그 수정 사항을 오픈소스로 공개해야 한다.
• PX4(BSD): 수정 내용을 공개하지 않아도 된다 → 상업적으로 부담이 적어 기업이 선호하기도 한다.

즉, 라이선스는 단순 표기가 아니라 회사가 어느 펌웨어를 고르느냐에 실제로 영향을 주는 요소다.

---

3. 데이터를 단순히 받기만 하는 내가 왜 FC/펌웨어를 알아야 할까

핵심: 나는 FC 펌웨어를 직접 수정하지 않는다. ArduPilot/PX4는 이미 완성된 펌웨어이고, 나는 그게 내보내는 데이터를 받는 소비자(consumer) 쪽이다. (백엔드로 치면, 남이 운영하는 외부 API의 응답을 파싱하는 입장. API 서버 코드를 고치는 입장이 아니다.)

그럼에도 이 둘을 알아야 하는 이유:

1. MAVLink 데이터를 만들어내는 주체가 바로 이 펌웨어다. 데이터의 출처이자 생산자. 어느 펌웨어인지에 따라 보내는 메시지 종류·주기·dialect가 미묘하게 다를 수 있다.
2. SITL로 가짜 드론을 띄울 때 ArduPilot 계열이냐 PX4 계열이냐를 골라야 한다. (시뮬레이터가 다름)
3. 비행 모드 번호, 파라미터 이름이 펌웨어마다 조금씩 다르다. 디코딩한 값을 해석할 때 해당 펌웨어 문서를 봐야 한다.

dialect(방언)란? MAVLink는 드론↔지상의 공통 언어(프로토콜) = 표준어. 그 위에 특정 진영이 얹은 추가 어휘 묶음이 방언이다. (영어는 공통이지만 미국식엔 영국엔 없는 단어가 있는 것과 같다.) ArduPilot의 방언 이름은 ardupilotmega. 나중에 pymavlink로 디코딩할 때 이 방언을 지정하게 된다.

참고: MAVLink는 펌웨어 공통

MAVLink 프로토콜 자체는 ArduPilot·PX4 공통이다. 그래서 "ArduPilot이냐 PX4냐"를 지금 급하게 정할 필요는 없다. (다만 회사가 ArduPilot을 쓴다면, 실습과 문서는 ArduPilot 기준으로 몰아서 배우는 게 효율적이다.) 또한 둘 다 MAVLink를 쓰기 때문에 QGroundControl 같은 지상국 소프트웨어가 양쪽 모두와 호환된다.

참고: MAVLink에는 v1.0 / v2.0 두 버전이 있고, v2는 v1과 하위 호환된다. 나중에 디코더가 어느 버전을 파싱하는지가 실무에서 중요해진다. 

---

이해 점검 (셀프 Q&A)

Q. FC 하드웨어와 펌웨어의 관계를 서버/OS 비유로?

보드 = 서버, 펌웨어 = 서버에 설치하는 OS. Windows/Linux를 고르듯 ArduPilot/PX4를 고른다.

Q. 나는 펌웨어 코드를 수정하나, 데이터를 받나?

받는 쪽. ArduPilot/PX4는 완성된 펌웨어이고, 나는 그 출력을 소비한다.

Q. ArduPilot/PX4를 지금 안 정해도 되는 이유?

MAVLink 프로토콜이 공통이라, 펌웨어별 차이는 나중에 생각해도 된다.

---

참고 자료

• ArduPilot 공식 문서: https://ardupilot.org/ardupilot/
• PX4 공식 문서: https://docs.px4.io/
• MAVLink 공식 문서: https://mavlink.io/en/
• pymavlink (파이썬 MAVLink 라이브러리): https://github.com/ArduPilot/pymavlink
• Intro to ArduPilot and PX4 (Circuit Cellar): https://circuitcellar.com/research-design-hub/intro-to-ardupilot-and-px4-part-1/
• PX4 vs ArduPilot 비교 (ThinkRobotics): https://thinkrobotics.com/blogs/learn/px4-vs-ardupilot-complete-comparison-guide-for-drone-developers