Uçuş kontrolleri ve haberleşme protokelleri

Merhaba, bu yazımda haberleşme paketleri üzerinde konuşacağım, iha, siha, drone gibi cihazların hatta  uçakların bile kullandığı standart olan comunication packet language (CAN, RADİO, Seri haberleşme sistemleri de dahil) protokolleri üzerine değineceğiz, aralarında karşılaştıracak artı ve eksilerine bakacağız, haberleşme sırasında nasıl bir yöntem kullanıldığını anlatacağım. 

Ayrıca son üretilen geliştirme kartımın nasıl uçuş bilgisayarına (so drone) çevirdiğimi anlatarak bu yolda küçük çipleri zor ekonomik şartlarda nasıl limitleri zorladığıma değinmesem olmaz diye düşünüyorum, elinizde olan patlamış mısırla birlikte bir kaç dakikalık bu blog yazıma İnsansız hava araçları tanımıyla başlayalım.

İnsansız Hava Araçları (İHA)

Bir İHA iki şekilde çalıştırılabilir: bir kontrol sistemi kullanılarak

ve yer kontrol istasyonunu (GCS) kullanmak. Bir uzaktan kumanda sisteminde,

kullanıcı doğrudan İHA'ya bakar veya üzerine monte edilmiş bir kamerayı izler. Bunu çoğu zaman FPV dronlarında görüyoruz genelde 3 boyutlu gözlük kullanarak dronu akro mod ile kontrol edilebiliyor, gerçek zamanlı haberleşme için video vericisi kullanılıyor, kendiniz bir fvp dronu yapabilirsiniz. Çoğu hazır olmayan dronelar için wifi sinyalleri üzerinden iletim maliyetli olmakta ama siz özel video vericileride alabilirsiniz. 

Hem denetleyici hem de İHA, yürüten bir iletişim modülü aracılığıyla bağlanır

Özel yapılan fvp drone

Bu tarz drone'lar hazır uçuş kartları içerisinde bulunan UAVCAN vb iletişim protokolleri yardımıyla aralarındaki iletişim. Tipik olarak telemetri, Wi-Fi, ZigBee ve diğer birçok ağ aygıtı iletişim için kullanılmaktadır. Öte yandan, GCS tabanlı kontrol kullanır yazılımı İHA'ya bağlamak için bir bilgisayar, daha sonra kullanıcı tarafından yüklenen görev komutları. Çeşitli kaynaklardan bilgi toplayarak İHA üzerine kurulu sensörler, GCS gibi İHA durumlarını izleyebilir.

mevcut yükseklik, mesafe, harita konumu ve gerçek görev durumu [14].

İnsansız hava aracı sistemleri, sensörden oluşan farklı parçalar içerir.

Yerden yerleşik veya elektronik ekipman tarafından kontrol edilen faydalı yükler ve bir veya daha fazla yer kontrol istasyonu. uzaktan pilotlu araçlar (RPV'ler), bir yerden kontrol edilen İHA türleridir.

zemin ve bu amaç için optimum kablosuz iletişim gerektirir. Açık

Öte yandan, büyük İHA'ların yakından kontrol edilebilmesi için GKS'lere ihtiyaç duyulmaktadır.

Özel drone İHA

Menzil ve iletişim engellerini aşmak için, günümüzde İHA'lar, mürettebat üyelerine bilimsel, taktiksel, çevresel temelli uygulamalarda ve acil durum müdahale alanında yardımcı olmak için kullanılmaktadır. Onlar askeri uygulamalar gibi diğer uygulamalarda da destek sistemi olarak kullanılmaktadır.

Büyük iha modelleri

İHA'ların gelişen kullanımı: güvenli iletişim protokolü sorunları ve zorlukları 39 ticari uygulamalar. İHA'lar irtifa menzili, ağırlık, ve uçuş dayanıklılığı, genellikle küçük İHA'lar yer tarafından desteklenir

dizüstü bilgisayarlardan veya akıllı telefonlardan oluşan kontrol istasyonları ve diğer küçük

sırt çantalarında kolayca taşınabilen cihazlar. 

Ground control station (GCS)

GCS, bir işlem birimi, bir telemetri / uzaktan kumanda modülünden oluşur,  bir kullanıcı kontrol modülü, bir kablosuz veri bağlantısı alt sistemi ve terface veya komut satırı arabirimindeki wifi, radyo sinyalleri yada seri bağlantı noktaları ile İHA arasında iletişim kurar, genellikle uçuş cihazları için kablosuz veri bağlantısı alt sistemi yapılandırılmıştır alıcı ve verici sistemler hem mürettabatta hemde İHA içerisine yerleştirilmiştir. Telemetri / command, iha'dan yerleşik verileri indirmek ve yüklemek için kullanılır bu arada yukarıda bahsettiğim gibi ikili iletişim için haberleşme protokolleri arasında çevrim gerekir. 

Yüksek donanımlı İha'lar için Mobil yer kontrol sistemi

GCS ArduPilot

ArduPilot yazılım paketi, araçta (Helikopter, Uçak, Gezici, anten İzleyici veya Drone (İHA)) çalışan navigasyon yazılımından (mikrodenetleyici donanım hedefleri için ikili biçimde derlendiğinde tipik olarak bellenim olarak anılır) ve yer istasyonu kontrol yazılımından oluşur. Mission Planner, APM Planner, QGroundControl, MavProxy gibi özel yazılım araçlarından oluşur. Derlenmemiş haliyle github üzerinden bulabilirsiniz.

Yazılım paketi, Travis CI tarafından sağlanan sürekli entegrasyon ve birim testleri ve GNU çapraz platform derleyicisi ve Waf dahil olmak üzere bir derleme ve derleme ortamı ile her gece otomatik olarak oluşturulur. Çeşitli donanım platformlarında çalışan önceden derlenmiş ikili dosyalar, Ardupilot alt web sitelerinden kullanıcı tarafından indirilebilir.

Bu yer kontrol yazılımı ayrıca uçuş bilgisayarları (uçuş kartları) için gömülü yazılım desteği sunar bu konuyu uzun uzadıya araştırmıştım ama gördüğüm kadarıyla c++ için yazılan gömülü yazılım için epey parametre var bu sebeple yazılımın flash boyutu minimum 1kb o yüzden elimde bulunan flytracker kartım için  tersine mühendislik ile uğraşamayacağım kadar fazla vakit gerektirdiği için başka üst katman yazılım kullandım şimdi ardupilot hakkında biraz bilgi edinelim Mavlink haberleşme protokolünü kullanır kendi kartım içinde bu protokolü kullanacağım, hem öğrenmek hem de kolay ve güvenilir alt yapısı ile size zahmet vermeyecek hazır python dilinde yazılmış araçları ve custom dil için kolay okunur xml içeriği var.

Arduplot, Mission Planner yer kontrol yazılımı ve kontrolcü

Cleanflight, Betaflight

İnternette sağlam bilgi bulamadığım için kendi özelleştirdiğim Betaflight yazılım hakkında bir kaç bilgi yazmak istiyorum özel olarak paylaşacağım uçuş kontrol kartım üzerine yer kontrol veya uçuş konfigrasyon ayarları için kullandığım Nodejs yada javascript tabanlı kontrolcü yazılımından ibaret github üzerinden açık kaynak koduna ulaşabilirsiniz bir iha için 14 den fazla da uçuş cihaz modellerini destekler, Quad x, +, HexA, Y6, Tricopter ve bunun üzerine uçuş modları, telemetri, gps ve sensör okuma kamera ayarları veya osd gibi modülün desteklediği tüm ayarları konfigre edebilirsiniz onun dışında alıcı kumanda kontrolü ve motor çıkışlarını test edebilirsiniz.

Bu program MSP iletişim protokolünü kullanır, kendi projem için daha sonra Mavlink protokolünü destekleyen özel yazılımı paylaşacağım. Şuan için çoğu testleri tamamlanan Mavlink custom dil paketi ile haberleşen Betaflight üzerindeki yazılım için epey uğraştım. Dil paketinin tek bir js dosyası ile bütünleştiğinden özelleştirmek kolay oldu, örneğin ardupilot yazılımının desteklediği diğer kartları Betaflight ile de kontrol edebilirsiniz bunun üzerine custom dil paketiniz için Javascript dili biliyor olmanız gerekir kendi kartınızın desteklediği dil içeriği için Ardupilot'un Mavproxy yazılımı ile kendiniz üretebilirsiniz yazılım kendi içerisinde gömülü uçuş kontrolcü devre kartınızın dil paketini .js formatında ulaşulabilir kütüphaneye çeviriyor.

Betaflight GCS kontrolcü

Bir çok üretici kendi bünyesinde, Betaflight yada Cleanflight'ın gömülü devre kartları için çoğu Stm32f4 üzerindeki mikrodenetleyicilerin bulunduğu gömülü iha yazılımının açık halini github'a eklediğinden diğer insanların katılımı ile iha severlerin geniş ilgi alanına geliştiricileri toplamış durumda belkide Ardupilot kadar geniş yelpazesi yok henüz..  

Üreticiler kendi devre kartları için yazılıma vakit ayırmadan özel donanım yazılımı olan alt donanım katmanını bu dağıtım yazılımına ekleyerek uzaktan güncelleme gibi spot desteği de harika bir şekilde kullanmış oluyor. Buraya kadar tuhaf olan birşey olmasada hazırcılığa her geçen gün hayır çeken ben için biraz uğraşlar sonucu bu kontrolcü yazılımına haberleşme dil paketi desteğini ekledim. Mavlink adındanda anlaşılacağı üzere Ardupilot olarak tanınmış yer kontrol sistemlerinin usta yazılımında bulunan iletişim paketi geniş yelpazeli Betaflight konfigrasyon programında bu dil desteğinin olmaması şaşırtıcı değil çünkü adamlar kendi dağıtım dilini kullandığı özel işletim sistemi (üst katman donanım yazılımı) kullanıyor.

Uçuş kontrol bilgisayarı

Bu geçmite harika olan stm32f1 ailesinin şimdi pek yüzüne bakan yok çünkü özellikleri biraz eskidi ve hantal kaldı ee işe maliyet de girince eski çipleri değerlendirmek gerek konusu yine benim eylendiğim bir konuydu henüz bu denetleyici desteklemekten feregat eden iki büyük kontrolcü yazılımına öyle mi? derken bu mimariyi kullanan farklı bir üst katman yazılımını github da bulduktan sonra kendi donanım katman yazılımına uyarladım bu ayrıca drone kontrol kartlarının nasıl bir yaklaşım sağladığını kolay bir şekilde anlamama izin verdi. 

Şimdi elimde gerçekten çalışan bir drone kontrolcü kartı var ve bununla gurur duysamda bilgisayar kontrolcüsü konusunda sınıfta kalmıştı ayarlarını değiştirebileceğiniz bir lcd ye yada grafik arabirimine sahip olmayan ana kart.. Ya ana sistemin dil paketini değiştirecektim yada yeni kontrolcü yazılımı ile vaktimi biraz harcayaktım yada dadha iyi bir fikirle açık kaynak kodlu kontrolcü yazılımlarının birinin dil paketini değiştiricektim. 

Öyle yaptım Mavlink desteklemeyen **flight yazılımını kullanarak bu desteği bünyesine eklemiş oldum şimdi Ardupilot kullanan herhangi birisi daha güzel grafik arayüzüne sahip Betaflight yazılımı ile uçuş cihazının ayarlarını yapabilir. Yinede kullanmak için yazılımı kendi custom paketinize dahil etmeniz gerekir doğrudan Ardupilot iletişim dili (Mavlink özel mesajlara izin veren ancak hazır kodlayıcı yazılım dosyalarının bulunduğu bir haberleşme protokolü sunuyor) desteklenmesede benzer parametreleri kullanıyor. 

Haberleşme Protokolleri

Örneğin koordinat sistemini yada yeni motor hızı gibi bilgileri iki cihaz arasındaki bağlantı bozulsa bile eksiksiz göndermek çok daha önemli oluyor cihazınızın yanlış yere yönlenmesini istemeyiz. Tek kablo ile çalışan seri haberleşme donanımı UART %100 güvenli bir iletişim topolojisi sağlamaz.  Pcb kartları, geliştirme kartları, gömülü sistemler, gps modülleri, özel araçlar çoğu cihaz ASCI tablosunu kullanır ama bunun bir dezavantajı sınırlı bant genişliğine sahip olmasıdır (yaklaşık 64 byte sınırlı kodlama sağlar) bu doğruluk tablosu gömülü sistemlerde hazır dönüşebiliyor olsa da iletişim kanalının  sadece 1/4 oranında faydalanmış oluyoruz bunun yerine haberleşme protokolleri ile tek bir paket üzerinden çok fazla veriyi doğru şekilde iletebiliriz ve bant genişliğinin tamamını (256 byte) kullanabiliriz. Bu sebeple doğrudan bilgisayardan aktarım bilgisini gönderirken taşıyıcı modülasyonuna ihtiyaç duyuyoruz ki Modülasyon diyorum çünkü karşı tarafta da kod çözücü olması gerek.

Şuna benzetebiliriz insanlar arası iletişimde kullanılan dil bir araç olmakla birlikte ne kadar fazla aracı eden kelime türleri olursa derdimizi o kadar kolay anlatabiliriz günümüz Türkçesinde bilmediğimiz veya adını hatırlamadığımız herhangi bir somut yada somut örnek için "şey" kelimesini kullanırız bu o anda karşı tarafın ne demek istediğimizi anlamasına da pek şaşırmayız çünkü insan doğası henüz bilgisayarların ulaşamadığı bir yerde, doğrusu aynı dili konuşurken insanların yaptığı genelleme ile yada duygu durumunu da işin içine katarak 6. bir haberleşme yayınında sörf yapabiliriz. 

Konuyu uzatmadan söylemek istediğim bir paket dil sisteminde haberleşen kelime karşı tarafta doğrulamaya sokulmak yerine toplu bir iletişim sonunda 1 yada 2 byte toplamında olan checksum ile metnimizi doğrulayan bilgi şifresini de paylaşmış oluruz böylelikle karşı taraf paketi aldığında hem şifreyi kendi yeniden hesaplar ki bu çok kolay bir yöntem olan; "özel veya" chekcsum ^= "A" denklemi bu işi çözer. Anahtar şifre paketin sonundan alınarak mobil paketteki dahil edilen her bir bilgiyi yeniden hesapladığı yeni şifre ile karşılaştırarak iletişimin bozulmadığını anlayabilir.

Paket sistemini anladığımıza göre bu şekilde çalışan toplu haberleşme protokollerine ve illetişim methotlarına doğrudan bakalım.

MAVLINK

MAVLink veya Micro Air Vehicle Link, küçük insansız araçlarla iletişim için bir protokoldür. Yalnızca başlık içeren bir ileti sıralama kitaplığı olarak tasarlanmıştır. MAVLink ilk olarak 2009 yılının başlarında Lorenz Meier tarafından LGPL lisansı altında piyasaya sürüldü...

Mavlink protokolü için paket tanımı

STX, Yeni bir paketin başlangıcını belirtmek için kullanılan protokole özgü metin başlangıcı (STX) işaretçisi. Protokol sürümünü anlamayan herhangi bir sistem paketi atlayacaktır.

LEN, Aşağıdaki yük bölümünün uzunluğunu gösterir

INC FLAGS, MAVLink uyumluluğu için anlaşılması gereken bayraklar (uygulama, bayrağı anlamıyorsa paketi atar).

CMP FLAGS,  Anlaşılmadığı takdirde göz ardı edilebilecek bayraklar (uygulama, bayrağı anlamasa bile paketi yine de işleyebilir). 

SEQ, Paket kaybını algılamak için kullanılır. Bileşenler, gönderilen her mesaj için değeri artırır.

SYS ID, Mesajı gönderen sistemin (araç) kimliği. Ağdaki sistemleri ayırt etmek için kullanılır. Geçersiz bir kaynak adresi olduğu için yayın adresi 0'ın bu alanda kullanılamayacağını unutmayın.

COMP ID, Mesajı gönderen bileşenin kimliği.

MSG ID, Yükteki mesaj tipinin D'si. Verilerin mesaj nesnesine geri kodunu çözmek için kullanılır.

DATA (PAYLOAD), Mesaj verileri. Mesaj türüne (yani Mesaj Kimliği) ve içeriğine bağlıdır.

CS,  Checksum doğrulama fonksiyonu ile oluşturulmuş packet şifresi gömülü kart ile doğrulanmak için tekrar kullanılır.

MSP MULTIWII

MSP, tüm Betaflight'tan türetilmiş uçuş yığınları tarafından kullanılan ana iletişim protokolüdür. Kontrol, telemetri ve sensörler için kullanılan ikili mesaj tabanlı bir protokoldür. 

İlk olarak, MSP'nin nasıl çalıştığına bakalım. Bunu anlamak için bu bağlantıyı (alternatif bağlantı burada ) çok yararlı buldum, ancak burada özetleyeceğim. Gönderilebilecek üç tür mesaj vardır.

Command -- gönderilecek bazı bilgileri içeren uçuş kontrolörüne gönderilen bir mesaj.

Request -- uçuş kontrolörüne gönderilen ve bazı bilgilerin geri verilmesini isteyen bir mesaj.

Response -- uçuş kontrolörü tarafından bir talebe yanıt veren bilgilerle birlikte gönderilen bir mesaj.

MSP mesajlarının belirli bir yapısı vardır. Bu sırayla bir başlık, boyut, tür, veri ve sağlama toplamı vardır.

Mesaj içeriği

Header, Başlık üç bayttır ve "$M" mesaj başlangıç ​​karakterlerini ve mesajın hangi yöne gittiğini gösteren bir karakteri içerir. "<", uçuş kontrolörüne gitmeyi (komut ve istek), ">", uçuş kontrolöründen gelmeyi (yanıt) belirtir.

Size, Dördüncü bayt, veri bölümünün uzunluğudur (bayt olarak). Örneğin, veri bölümünde üç INT 16 değişkeni varsa, boyut baytı 6 olur.

Type, Tip baytı, mesajda hangi bilgilerin gönderildiğini belirtir. Türlerin bir listesini burada bulabilirsiniz . Bunun bir örneği, tip numarası 108 olan MSP_ATTITUDE olacaktır.

Data, Veriler, tüm bilgilerin gönderildiği yerdir. İstek mesajlarında veri yoktur. Bilgi içerdikleri için komutlar ve yanıtlar bunu yapar. Döndürülen veri türleri yine burada bulunabilir .

Veri bölümünün zor kısmı, baytların sırayla ters çevrilmiş olmasıdır ve bu, son derece zayıf bir şekilde belgelenmiştir. Örneğin, aşağıdaki iki baytı bu sırayla alırsam:

10011010

01001111

int16_t roll;

byte c;                       // The current byte we read in.

c = mspSerial.read();         // The first sent byte of the number.

roll = c;                     // Put the first sent byte into the second byte of the int 16.

c = mspSerial.read();         // The second sent byte of the number.

roll <<= 8;                   // Move the first sent byte into the first byte of the int16.

roll += c;                    // Put the second sent byte into the second byte of the int 16.

roll = (roll & 0xFF00) >> 8 | (roll & 0x00FF) << 8; // Reverse the order of bytes in the int 16.

Checksum, Bir MSP mesajının son baytı sağlama toplamıdır. "Sağlama toplamı, boyut, tür ve yük baytlarının XOR'udur". Bir istek mesajı için sağlama toplamı türe eşittir.

Özetle bir "MSP_ATTITUDE" isteği için örnek bir yanıt mesajı aşağıdaki gibi

1. 00100100 -- '$' - Byte 1 of the header.
2. 01001101 -- 'M' - Byte 2 of the header.
3. 00111110 -- '>' - Byte 3 of the header.
4. 00000110 -- '6' - The size byte.
5. 01101100 -- '108' - The type number corresponding to "MSP_ATTITUDE".
6. 11100010 -- The first sent byte of the roll INT16.
7. 11111111 -- The second sent byte of the roll INT16.
8. 00010010 -- The first sent byte of the pitch INT16.
9. 00000000 -- The second sent byte of the pitch INT16.
10. 11000010 -- The first sent byte of the yaw INT16.
11. 00000000 -- The second sent byte of the yaw INT16.
12. 10100111 -- The checksum byte.

Rulo şöyle olurdu: 11111111 11100010 = -30. Pitch şöyle olurdu: 00000000 00010010 = 18. Yaw olur: 11000010 00000000 = 194.

Burada belgelendiği gibi , dönüş ve eğim bir derecenin 1/10'u cinsindendir. Yani nihai değerler aşağıdaki gibi olacaktır:

Roll = -3.0

Pitch = 1.8

Yaw = 194

 

URANUSLINK

Temsili Uranuslink bağlantı şeması

UranusLink, paket odaklı bir protokol olarak güvenilmez ve güvenilir hizmetler sağlamak için oluşturulmuştur. Protokol paket yapısını belirler ve  iletilen veri gösterimi. Genel çalışma mekanizması ve UranusLink protokolünün açıklaması aşağıda yer almaktadır.

Paket yapısı 

Her pakette altı alan vardır:

1. önsöz (PRE),

2. sıra numarası (SQN),

3. mesaj tanımlama (MID),

4. veri uzunluğu (LEN),

5. genel mesajlar, parametreler, dinamik donanım bilgileri, cihaz status bilgilerini vb içerir(DATA)

6. sağlama toplamı (CS).

Uranuslink paket tanımı 

Uranüs Bağlantı protokolü, radyoda kullanılmak üzere özel olarak tasarlanmıştır. Telsiz iletişiminde normalde veri kayıpları ve yanlış veriler alma gerçekleşebilir. 

PRE, Paketin ilk alanı önsözdür bu  veri paketi her zaman böyle bir değerle (0xFD) başlar ve genellikle  giriş arabelleğindeki bir paketin geçerliliğini sağlamak için paket verileri ile alıcı taraf için ara numarasıdır (SQN). Her zaman bir  ”çift" sayı ve paketin sonunda sağlama toplamıdır. İyi  protokol arasındaki belirli ortam, yük e bağlantı kapasitesindeki dengeyi sağlamak için girişlere sağlama toplamları uzunluğu seçilmiştir.

SQN, bir protokolün paketlerdeki arızaları tanımlamasına sadece en güncel bilgiler, İHA iletişim sorunlarını tespit edebilmeli ve devam ederse uygun şekilde yanıt verebilmelidir. Alıcı tarafında, verilen SQN satırında eksik bir sayı arsa, paket kaybolmuş veya çok yollu bilgi bağlantıları mümkünse, bu paketler yanlış sırada gelebilir. Çünkü İHA'nın kontrolü ile en son veriler her zaman önemlidir, sahip olan bir paket gelirse düşecektir.

MID, paketin bilgi bölümündeki verilerin yorumlanmasını belirler. iha'da şu anda tespit edilen sekiz tür mesaj var yön ve baz veya kontrol istasyonu yönünde 16. Önemli olan 

türleri şunlardır: (1) yer istasyonundan iha'ya bağlantı ve (2) 

iha'dan yer istasyonuna bağlantısı için diğer bilgiler.

Avantaj

Son teknoloji, Uranüs Bağlantısı mevcut protokollerle çoğu

İHA ve düşük genel giderlerle etkileşim için MAVLink protokolünü yaygın olarak kullanr. Bununla birlikte,% 33'e varan ek ek yüke sahiptir, iha için bu cpu çalışma yükü olarak fazla gelebilir ama son zamanlarda üretilen çipler bunun üstesinden gelebilir.

UAVCAN

Boing uçağını hackleyen bir mühendisi duymuşsunuzdur, koltuğun yanında bulunan düğmeleri sökerek CAN hattına bağlanıp özel internet ağının şifresini çözerek uçuş bilgilerine ulaşır ve  hatta değiştirmektedir, ama ne güzeldir ki sadece hacklemek ile kalmış olan abimiz güvenliği riske atmadan bunu yetkililere bildirmiş. Şimdi bu güvenliği konusunda endişe duyacağımız CAN hattı için iha'larda durum nasıl bir bakalım.

UAVCAN, havacılıktaki CAN hattı gibi motorlu araçlarda sıkca kullanılan, sağlam araç ağları üzerinden güvenli bağlantı sağlamak için tasarlanmış açık kaynaklı bir protokoldür ve 

robotik uygulamalar. İHA protokolü yayınla-abone ol mimarisi üzerinde çalışır. Ana düğümü yoktur ve tüm düğümler aynı haklara sahiptir, bilgileri rastgele sıra ile sıralanır buda; 

tek bir başarısızlık noktası olmadığı anlamına gelir. Bu protokol aynı zamanda birden çok düğümü ve birden çok arabirimi de destekler; bu özellik normalde güvenlik endişesi uygulamalarında gereklidir. İHA ağ gibi standart üst düzey hizmetleri ve iletişimleri tanımlar 

keşif, düğüm kurulumu, ürün yazılımı düğümü yükseltmesi, düğüm durumunun izlenmesi, 

ağ genelinde zaman senkronizasyonu ve uyarlanabilir düğüm kimliği tahsisi (aka. 

tak ve çalıştır), vb. 

Bu protokol hafiftir kolayca iletilebilir doğrulanabilir Protokoldür. İHA'lar için uygun olan gerçek zamanlı sistemler. MIT lisansı, yüksek kaliteli açık kaynaklı referansların uygulanmasını öngörmektedir.

UAVCan protokolü, CAN veri yoluna (denetleyici alan ağına) dayanmaktadır., 

ana bilgisayar olmadan cihazlar e mikrodenetleyiciler arasındaki diğer uygulamalarda iletişime izin ermek için standart bir tasarım olarak çalışır. Başlangıçta protokol, multipleks elektrik tesisatı için oto cep telefonlarındaki bakırdan tasarruf etmek için tasarlanmıştı, ancak bahsedilen özelliklerden dolayı diğer alanlarda da yaygın olarak kullanılmaktadır 

Her UAVCAN düğümünün benzersiz bir veri yolu kimliği vardır. Aralıktaki tamsayıdır 

{1 – 127}, burada 1 değeri genellikle otopilot veya başka bir tür merkezdir 

kontrol ünitesi ve 126 ve 127 değerleri genellikle bir hata ayıklama veya izlemedir 

sistem. 1 Değeri, UAVCAN düğümünün en sık kullanılan değeridir.

MAVLink veya İHA aracılığıyla iletişim kurabilen herhangi bir birim aynı MAVLink Bileşen Kimliği (COMPID) numarasının yanı sıra UAVCAN Düğüm Kimliği farklıdr; aksi takdirde ciddi tutarsızlıklar oluşabilir. İçinde normal durumda, tek bir yedek olmayan otopilot mevcutsa, İHA Düğümü Kimliği ve MAVLink bileşeninin kimliği 1 (bir) olarak ayarlanacaktır.Giden / gelen mavlink'in her mesajı / komutu hakkında bir UAVCAN düğümü, COMPID alanı ile aynı değere ayarlanacaktır. 

Sonuçlar 

UranusLink, radyo yolları için tasarlanmıştır.

veri kaybı ve yanlış veri alımı olabilir. Sağlama toplamını şu şekilde içerir:

orijinal mesajın alınıp alınmadığını kontrol etmek için bileşen.

Sağlama toplamı yalnızca orijinal iletinin değiştirilip değiştirilmediğini doğrulayabilir

ya da değil. Bununla birlikte, iha'larda, bir davetsiz misafir bu hassas bilgileri okursa

bir görev başarısızlığına neden olur. Güvenlik konsunda sınıfta kalmıştır tıpkı bahsettiğim gibi ağa sızan hackerin bilgileri okuduğu gibi Bu nedenle komutların gizliliği

iha'larda çok önemlidir ve davetsiz misafirin işini zorlaştırmak için güvende olması gerekir

paketi okumak ve mesajı anlamak için. Basit sağlama toplamı değil

verilerin gizliliğini ve bütünlüğünü sağlamak gerekir.

UAVCan, kritik olmayan robotlar ve havacılık için tasarlanmıştır. Bu

uavcan'ın orijinal şartname belgesi, protokol pro'nun koruma sağlamadığını ve kritik görev ve güvenlik açısından kritik sistemler için önerilmediğini belirtir.

MAVLink, MSP iletisi üstbilgiyi temel aldığından, iletiyi veri paketinin ilk alanında (çerçeve) değerlendirir ve sınıflandırır. İlk çerçeve

Bu nedenle STX değeri doğrulanır ve değere dayanarak, bir değer olup olmadığına karar verir.

MAVLink paketi olsun ya da olmasın. Aktarım hızını ve verimliliğini artırmak için

iletişim için Mavlink'te doğrudan şifreleme mekanizması yoktur.

Ayrıca, mesaj şifrelenirse, başlık değeri değişir ve böylece bir

sistem bir MAVLink paketi olup olmadığını tanıyamaz. Bunun anlamı, rağmen

MAVLink daha iyi iletişim sağlar, ancak güvenlik mekanizmasından yoksundur.

UranusLink ve İHA için. MAVLink, UAVCan ve uranuslink'e kıyasla yaygın olarak kullanılan ve iyi bilinen bir protokoldür. Veri kaybı ve mavlink'teki gecikme, UAVCan gibi diğer protokollere göre rapor edilir.UranusLink protokolü küçük yükü olan İHA'lar için uygundur. Ancak, daha az ampirik var

uygulanabilirliği ve geliştirilmesiyle ilgili kanıtlar var. MAVLink  ve MSP daha fazlasına izin verir, daha eşzamanlı sistemlere izin verir ve birçok program ming dilini destekler. 

Buna karşılık UranusLink'in İHA desteği yok birden çok dil ve eşzamanlılık için. Bunların genel karşılaştırması

protokoller Tablo'da sunulmuştur.

Protocols	Artılar	Eksiler	Yok
UranusLink	Açık kaynak • Hafif araçlar yerine havacılık ve robotik uygulamalar için tasarlandı. • İkili destekler • Açık kaynak değil	Daha az ampirik kanıt • Çoklu programlama dili desteği yok • Eşzamanlı desteklemez. • Ölçeklenebilir değil • Güvenlik yok • Yüksek gecikme süresi • Daha az ampirik kanıt • Yaygın olarak kullanılmaz • Çoklu destek yok Programlama dilleri • Destek yok • Ölçeklenebilir değil •Sadece İHA'lar için tasarlandı	• Doğrulama mesajı yok paket güvenilir olmayabilir ve eski bir protokol
UAVCan	Açık kaynak • Hafiflik * Düşük gecikme süresi * Algılama yeteneği daha hızlı	Daha az ampirik kanıt * Yaygın olarak kullanılmaz * programlama dilleri Çoklu destek yok * Eşzamanlı değil * Ölçeklenebilir değil * İHA'lar için tasarlandı * Sınırlı şifreleme	• Güvenlik mekanızması yok.
MAVLink	• Yaygın olarak kabul edilen dil * Ölçeklenebilir * çoklu dili destekler * Eşzamanlı iletişim destekler * Büyük ampirik kanıtı • Hafiflik * Açık kaynak * Düşük gecikme süresi		• Güvenlik mekanızması yok.
MSP

 

Bu araştırma çalışması şunları önermektedir

belirtilen sorunun üstesinden gelen İHA'lar için yeni bir güvenlik protokolü tasarlamak ve geliştirmek.

Tartışma

İHA'ların hem askeri hem de sivil uygulamalarda genel önemini sunmaktadır. Geçmişte İHA'lar çoğunlukla askeri uygulamalar için kullanılıyordu, ancak kısa süre sonra İHA'ların sivil uygulamalarda kullanılması  askeri kullanımı aşacak. Teknolojinin ilk aşamalarında olduğu gibi 

uygulamalardaki gelişim ve yeni alanlar her geçen gün araştırılıyor, 

bu, bilgisayar korsanlarını ve saldırganları güvenliklerini tehlikeye atmaya çekti 

çeşitli amaçlanan amaçlar. Güvenlik saldırıları normalde gerçekleştirilir 

iletişim protokollerine karşı. Bu bölümde farklı sundum, her ne kadar bazı bilgileri alıntılamış olsamda doğrudan kaynak paylaşımı için çekinmiyorum. 

Mavlink'in İHA iletişimi için en yaygın kullanılan protokoll olduğu tespit edilmiştir. Ancak MAVLink, CAN daha iyi iletişim sağlasa da, mesajları şifrelemek için güvenlik mekanizmasından yoksundur ve  ciddi sonuçlara yol açabilir. Bu nedenle belirtilen sorunun üstesinden gelebilecek yeni ve güvenli iletişim diline ihtiyaç var.

Configrator

Rosflight için kontroller kodlarını yazdım mavlink üzerinden haberleşme kuruyor

https://github.com/hmz06967/rosflight-configrator

#kaynak

file:///C:/Users/flyozkan/Downloads/10.1016B978-0-12-819972-5.00003-3.pdf

https://en.wikipedia.org/wiki/ArduPilot

https://stackoverflow.com/questions/42877001/how-do-i-read-gyro-information-from-cleanflight-using-msp