ArduPilot SITL이 잡아주는 것과, 더는 진실을 말해주지 않는 지점
이 글은 영어판 도 있습니다. 노트북에서 잡은 버그는 오후 반나절이면 끝납니다. 같은 버그를 공중에서 잡으면 기체 한 대가 날아갑니다. ArduPilot SITL이 실제로 증명해주는 게 무엇이고, 시뮬레이션이 멀쩡히 통과해도 아무 의미가 없는 지점이 어디인지 정리했습니다. SITL은 펌웨어를 흉내 내지 않는다, 그대로 돌린다 SITL을 굳이 세팅할 값어치가 여기 있는데, 대개 그냥 지나칩니다. Software In The Loop은 비행 컨트롤러를 흉내 낸 모델을 돌리는 게 아닙니다. 진짜 ArduPilot 소스를 sitl 타겟으로 컴파일해서 네이티브 프로세스로 띄웁니다. 같은 스케줄러, 같은 EKF, 같은 모드 전환, 같은 페일세이프 로직이 데스크톱에서 돕니다. 바뀌는 건 물리와 센서 드라이버뿐이고, 검증하려는 코드는 그대로입니다. 그래서 SITL에서 모드 전환이 이상하게 굴면 시뮬레이터 탓이 아니라 그냥 버그입니다. 환경만 한 번 잡아두면 기체 띄우는 데 명령 하나면 됩니다. git clone --recurse-submodules https://github.com/ArduPilot/ardupilot cd ardupilot ./Tools/environment_install/install-prereqs-ubuntu.sh -y ./Tools/autotest/sim_vehicle.py -v ArduCopter --console --map 첫 실행은 waf 로 펌웨어를 빌드하느라 몇 분 걸리고, 그다음부터는 몇 초면 뜹니다. MAVProxy 콘솔과 지도가 열리고, 기본 위치에 시동 걸 준비가 된 멀티콥터 한 대가 놓입니다. 컴패니언 컴퓨터가 쓸 그 경로로 붙는다 MAVProxy는 편하지만 여기가 핵심은 아닙니다. 중요한 건 컴패니언 컴퓨터가, 제 경우엔 Jetson인데, 실제 기체에서 쓸 바로 그 인터페이스로 가상 기체와 이야기하게 만드는 겁니다. SITL은 비행 컨트롤러의 시리얼 포트를 TCP 소켓으로 열어줍니다. ...