ArduPilot GUIDED'e geçti diyor, ekrandaki modu doğrula
pymavlink ile GUIDED moduna geçiş komutu gönderiyorsun, otopilot ACK ile “kabul ettim” diyor, ama script'inde ya da yer istasyonunda mod hâlâ eskisi gibi görünüyor. Kodunu satır satır kontrol ediyorsun, hata yok gibi; sorun kodda değil, ACK'in gerçekte ne söylediğinde.
ACK'in arkasında çalışan kontrolü, ACK'in ne zaman hiçbir şey kanıtlamadığını ve moda gerçekten geçip geçmediğini nasıl doğrulayacağını, bugün ArduCopter SITL üzerinde incelediğimiz kaynak koddan takip ediyoruz.
ACK aslında neyi kabul ediyor
DO_SET_MODE komutu da, eski SET_MODE mesajı da otopilotta aynı fonksiyona düşüyor: GCS_MAVLink katmanındaki bu fonksiyon, aracın set_mode() çağrısının dönüş değerine bakıyor. true dönerse ACK “kabul edildi” oluyor, false dönerse “başarısız” oluyor; yani ACK, sadece mesajın sözdizimini değil, gerçek denemenin sonucunu yansıtıyor.
Yani asıl soru “ACK geldi mi” değil, “otopilot hangi kontrolden geçerek bu ACK'i üretti”.
Aynı moddaysan komut hiçbir şey kanıtlamaz
Kaynak kodda gördüğümüz en can alıcı ayrıntı şu: istenen mod, aracın mevcut moduyla aynıysa fonksiyon hiçbir kontrolü çalıştırmadan doğrudan true döner. Yani script'in zaten GUIDED'teyken tekrar GUIDED iste, ACK her zaman “kabul edildi” gelir; bu senin GPS'in, EKF'in ya da pozisyon durumun hakkında hiçbir şey söylemez.
En sık yapılan hata: mod değişmedi diye komutu döngüde tekrar tekrar göndermek. Zaten o moddaysan her tekrar “başarılı” görünür, asıl sorunu gizler.
Çözüm: ACK'e değil HEARTBEAT'e bak
Güvenilir tek doğrulama, HEARTBEAT akışındaki mod alanını okumak. Komutu gönder, ACK'i logla ama karar verme; birkaç HEARTBEAT paketi boyunca modun gerçekten değiştiğini gör.
mode_id = master.mode_mapping()['GUIDED']
master.mav.command_long_send(
master.target_system, master.target_component,
mavutil.mavlink.MAV_CMD_DO_SET_MODE, 0,
mavutil.mavlink.MAV_MODE_FLAG_CUSTOM_MODE_ENABLED, mode_id, 0, 0, 0, 0, 0)
ack = master.recv_match(type='COMMAND_ACK', blocking=True, timeout=5)
# ACK'e degil, HEARTBEAT'e guven
for _ in range(20):
hb = master.recv_match(type='HEARTBEAT', blocking=True, timeout=1)
if hb and mavutil.mode_string_v10(hb) == 'GUIDED':
print('mod gercekten degisti')
break
Hata Mesajları ve Anlamları
Mode change to Guided failed: requires position
GUIDED, requires_position() ile pozisyon kontrolü isteyen modlardan biri; otopilot EKF'ten geçerli bir mutlak ya da göreli pozisyon alamıyorsa, armed durumdayken bu modu reddeder.
PreArm: GPS 1: Bad fix
Bu satır mod değişimiyle ilgili değil, ayrı bir prearm denetim döngüsünden geliyor; SITL testimizde GPS'i geçici olarak bozduğumuzda bu uyarı sürekli aktı ama mod komutumuzla doğrudan bağlı değildi. İkisini aynı hata saymak yanlış teşhise götürür.
Mode change to Guided failed: GCS entry disabled (FLTMODE_GCSBLOCK)
FLTMODE_GCSBLOCK parametresi yer istasyonundan belirli modlara girişi bit maskesiyle engelliyor; bu mesajı görüyorsan sorun GPS ya da EKF değil, bu parametrenin değeri.
Doğrulama
Bu bulguları yayından önce kendi ArduCopter SITL kurulumumuzda test ettik; aşağıdaki çıktı bizim doğrulama koşumuzun sonucu; okurun tekrarlaması gereken bir adım değil.
COMMAND_ACK {command : 176, result : 0, ...}
STATUSTEXT: PreArm: GPS 1: Bad fix
mod_sonrasi: GUIDED
Saha tarafında da fark var: forumda paylaşılan bir vakada LOITER'dan GUIDED istendiğinde bazı kartlar GCS failsafe yüzünden RTL'e geçiyor; bizim SITL koşumuzda görmediğimiz, donanım/telemetri kurulumuna bağlı ayrı bir davranış.
Mod geçişlerini, ACK/HEARTBEAT ayrımını ve pymavlink ile GUIDED/AUTO komutlarını baştan sona kurduğumuz kurs: Python ile Sıfırdan İHA Kontrolü.
İNDİRİM KUPONU
Kupon kodu: SOFTIVATION15
Eğitimi alırken ödeme ekranındaki “Kupon kodu” kutusuna bu kodu yaz, %15 iner.




Yorumlar