Posts

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 소켓으로 열어줍니다. ...

What ArduPilot SITL catches, and where it stops telling the truth

This post is also available in Korean . A bug found on a laptop costs an afternoon. The same bug found in the air costs an aircraft. Here is what ArduPilot SITL actually proves, and the four places where a green simulation run means nothing. SITL runs the firmware, not a model of it This is the part that makes SITL worth the setup, and the part most people skip past. Software In The Loop does not simulate an approximation of your flight controller. It compiles the real ArduPilot source for a sitl target and runs it as a native process. The same scheduler, the same EKF, the same mode transitions, the same failsafe logic that will run on the flight controller runs on your desktop. What gets replaced is the physics and the sensor drivers, not the code under test. So when a mode transition misbehaves in SITL, that is your bug. Not a modelling artifact. Getting a vehicle flying takes one command after the initial setup: git clone --recurse-submodules https://github.com/ArduPi...

App Sandbox를 켜면 손쉬운 사용 권한을 받을 수 없다

이 글은 영어판 도 있습니다. 메뉴 막대 앱이 시스템 설정의 손쉬운 사용 목록에 아예 나타나지 않았습니다. 오류도 없고, 권한 요청 창도 안 뜨고, 켜줄 항목조차 없었습니다. TCC 데몬이 로그에 실제로 뭐라고 남기는지, 그리고 원인을 하나로 좁힌 대조 실험을 정리했습니다. 지금 글을 입력하고 있는 앱에서 텍스트 캐럿 위치를 읽어오는 작은 메뉴 막대 유틸리티를 만들고 있었습니다. 시스템 전역 요소를 대상으로 AXUIElementCopyAttributeValue 를 호출해야 하는 일이라, 사용자가 손쉬운 사용 권한을 켜줘야 동작합니다. 그래서 앱을 띄우면서 흔히 하는 대로 권한을 요청했습니다. let trusted = AXIsProcessTrustedWithOptions( [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as String: true] as CFDictionary) 아무 반응이 없었습니다. 권한 요청 창이 뜨지 않았습니다. 더 이상한 건 시스템 설정 → 개인정보 보호 및 보안 → 손쉬운 사용 목록에 앱이 아예 없다는 점이었습니다. 켜줄 스위치 자체가 없으니 손쓸 방법이 없었습니다. + 버튼으로 앱을 직접 끌어다 넣어봐도 마찬가지였습니다. 검색하면 나오는 답은 전부 "시스템 설정에서 직접 추가하세요"의 변형이었습니다. 추가가 되는 앱에나 통하는 얘기입니다. 제 앱은 추가 자체가 안 됐습니다. 추측 대신 TCC 로그를 읽었다 macOS에서 권한을 판단하는 건 tccd 입니다. 그리고 이 데몬은 통합 로그에 꽤 자세히 남깁니다. 가장 쓸모 있었던 명령은 이겁니다. log show --last 5m --style compact --predicate 'process == "tccd"' \ | grep -i "<번들 ID>" 로그 두 줄에 답이 다 있었습니다. 첫 줄은 샌드박스든 아니든 실...

App Sandbox silently blocks Accessibility permission

This post is also available in Korean . My menu bar app never showed up in System Settings → Accessibility. No error, no prompt, no entry to toggle. Here is what the TCC daemon logs actually say, and the one-variable test that pinned it down. I was building a small menu bar utility that reads the text caret position of whatever app you are typing in. That requires the Accessibility API — AXUIElementCopyAttributeValue against the system-wide element — which requires the user to grant Accessibility permission. So I did the normal thing at launch: let trusted = AXIsProcessTrustedWithOptions( [kAXTrustedCheckOptionPrompt.takeUnretainedValue() as String: true] as CFDictionary) Nothing happened. No permission dialog. Worse, the app never appeared in System Settings → Privacy & Security → Accessibility at all — so there was nothing to toggle on. Dragging the app in with the + button did not help either. Every answer I found online says so...