Mavlink協議理解

來源：blog.csdn.net/super_mice/article/details/44836585

以前看了mavlink協議，網上關於mavlink的資料很少。本文大概總結了下對mavlink協議的理解。如下如不說明都是說mavlink v1.0版本。

首先附上mavlink的各個消息的簡介https://pixhawk.ethz.ch/mavlink/（這裏的內容不少，建議大概瞭解mavlink後再去瀏覽），

mavlink協議介紹http://qgroundcontrol.org/mavlink/start

以後會在個人資源裏上傳一份爲初學者準備的mavlink資料（轉載）已經上傳至筆者資源，免費下載。mavlink 純小白教程(英文)它用通俗的說法幫助新人理解什麼是mavlink，mavlink能幹嗎等等。資料只有第一部分，第二部分筆者沒有找到（多是原做者沒繼續第二部分吧）。

先簡單介紹下mavlink協議。Mavlink協議最先由 蘇黎世聯邦理工學院 計算機視覺與幾何實驗組 的 Lorenz Meier 於2009年發佈，並遵循LGPL開源協議。Mavlink協議是在串口通信基礎上的一種更高層的開源通信協議，主要應用在微型飛行器（micro aerial vehicle）的通信上。Mavlink是爲小型飛行器和地面站（或者其餘飛行器）通信時經常用到的那些數據制定一種發送和接收的規則並加入了校驗 （checksum）功能。

【1】下面開始說介紹mavlink所發送的數據結構。Mavlink傳輸時的基本單位是消息幀。

如圖所示，每一個消息幀都是上述的結構，除了灰色外，其餘的格子都表明了一個字節的數據。

紅色的是起始標誌位（stx），在v1.0版本中以「FE」做爲起始標誌。這個標誌位在mavlink消息幀接收端進行消息解碼時有用處。

第二個格子表明的是灰色部分（payload，稱做有效載荷，要用的數據在有效載荷裏面）的字節長度（len），範圍從0到255之間。在mavlink消息幀接收端能夠用它和實際收到的有效載荷的長度比較，以驗證有效載荷的長度是否正確。

第三個格子表明的是本次消息幀的序號（seq），每次發完一個消息，這個字節的內容會加1，加到255後會從0從新開始。這個序號用於mavlink消息幀接收端計算消息丟失比例用的，至關因而信號強度。

第四個格子表明了發送本條消息幀的設備的系統編號（sys），使用PIXHAWK刷PX4固件時默認的系統編號爲1，用於mavlink消息幀接收端識別是哪一個設備發來的消息。

第五個格子表明了發送本條消息幀的設備的單元編號（comp），使用PIXHAWK刷PX4固件時默認的單元編號爲50，用於mavlink消息幀接收端識別是設備的哪一個單元發來的消息（暫時沒什麼用） 。

第六個格子表明了有效載荷中消息包的編號（msg），注意它和序號是不一樣的，這個字節很重要，mavlink消息幀接收端要根據這個編號來肯定有效載荷裏到底放了什麼消息包並根據編號選擇對應的方式來處理有效載荷裏的信息包。

  最後兩 個 字節是16位校驗位，ckb是高八位，cka是低八位。校驗碼由crc16算法獲得，算法將整個消息（從起始位開始到有效載荷結束，還要額外加上個 MAVLINK_CRC_EXTRA字節）進行crc16計算，得出一個16位的校驗碼。以前提到的每種有效載荷裏信息包（由消息包編號來代表是哪一種消息 包）會對應一個MAVLINK_CRC_EXTRA，這個 MAVLINK_CRC_EXTRA 是由生成mavlink代碼的xml文件生成的，加入這個額外的東西是爲了當飛行器和地面站使用不一樣版本的mavlink協議時，雙方計算獲得的校驗碼會 不一樣，這樣不一樣版本間的mavlink協議就不會在一塊兒正常工做，避免了因爲不一樣版本間通信時帶來的重大潛在問題。

爲了方便敘述，消息包將稱做包，包所表明的信息稱做消息。上圖中的sys將稱爲sysid，comp將稱爲compid，msg將稱爲msgid。

官方的介紹以下圖：

 

【2】下面主要介紹mavlink裏消息的種類和如何看懂開始時提到的那個官方的mavlink消息介紹。

（一）中已經提到了在mavlink消息幀裏最重要的兩個東西，一個是msgid；一個是payload，前者是payload中內容的編號，後者則存放了消息。消息有許多種類型，在官網的網頁中中以藍色的「#」加數字的方式來表示消息的編號如 「#0」（這樣的表示方法應該是爲了方便在網頁中查找相應編號消息的定義）。在官網介紹網頁裏往下拉，大概拉到二分之一的位置處，開始出現「MAVLink Messages」的介紹，往下看是各類消息的數據組成說明。下面將以幾個消息爲例，講解mavlink消息。

先以 #0 消息爲例，這個消息叫心跳包（heartbeat）。它通常用來代表發出該消息的設備是活躍的，飛行器和地面站都會發出這個信號（通常以1Hz發送），地面站和飛行器會根據是否及時收到了心跳包來判斷是否和飛行器或地面站失去了聯繫。

                         

從圖上能夠看出，心跳包由6個數據組 成，第一個是佔一個字節的飛行器類型數據（type），這個數據表示了當前發消息的是什麼飛行器，好比四旋翼，固定翼等等。type的取值如何與飛行器類 型對應，這要在官方的mavlink消息介紹網頁上找，位於網頁開始出的數據枚舉中。以下圖所示：

  這裏只是一部分的類型，第一個是通用 飛行器，對應的type數值是0；第二個是固定翼類型，對應的數值是1；第三個對應的是四旋翼，對應的數值是2.這個飛行器類型，其實對於發心跳包的地面 站來講可能沒什麼意義（不一樣飛控對該消息的處理方法不一樣，至少刷了PX4固件的Pixhawk飛控對地面站發來的心跳包裏的這個參數並不關心，如無特殊說 明，以後所說的Pixhawk飛控都是指刷PX4固件的飛控），對於飛行器端來講表明了當前飛行器的類型，地面站能夠根據這個參數來判斷飛行器的類型並做 出其餘的反應。

第二個參數是自駕儀（即一般所說的飛控）類型，好比apm，ppz，Pixhawk等飛控，具體定義查找和以前查找飛行器類型時的方法同樣。一樣的，對於發送心跳包的飛行器來講表明了本身的飛控類性，對地面站發出的心跳包來講意義不大。

第三個參數是基本模式（base mode），是指飛控如今處在哪一個基本模式，對於發心跳包的地面站來講沒有意義，對於發送心跳包的飛控來講是有意義的。這個參數要看各個飛控本身的定義方 式，mavlink介紹網頁並不會給出具體的模式。在Pixhawk中基本模式能夠分爲使用用戶模式（custom mode）仍是基本模式（這裏有點繞，實際上是就是是否使用用戶模式）。使用用戶模式將在講下個參數時說明，使用基本模式又會分爲自動模式（auto），位 置控制模式（posctl）和手動模式（manual）。通常狀況下都會使用用戶模式，普通用戶不用關心這個參數。開發者在使用mavlink修改飛行器 模式時須要注意基本模式的設置，具體請看PX4代碼。

第四個參數是用戶模式（custom mode），大概說一下Pixhawk的用戶模式。以多軸爲例。它分爲主模式（main mode）和子模式（sub mode），兩種模式組合在一塊兒成爲最終的模式，主模式分爲3種，手動（manual），輔助（assist），自動（auto）。手動模式相似apm的姿態模式。在輔助模式中，又分爲高度控制模式（altctl）和位置控制模式（posctl）兩個子模式，高度控制模式就相似apm的定高模式，油門對應到飛行器高度控制上。位置模式控制飛行器相對地面的速度，油門和高度控制模式同樣，yaw軸控制和手動模式同樣。自動模式裏又分爲3個子模式，任務模式（mission），留待模式（loiter），返航模式（return）， 任務模式就是執行設定好的航點任務，留待模式就是gps懸停模式，返航模式就是直線返回home點並自動降落。在apm裏這個參數貌似是沒有用的，注意這 個數據佔了4個字節，在Pixhawk中，前兩個字節（低位）是保留的，沒有用，第三個字節是主模式，第四個字節是子模式。普通用戶請無視，開發者請注意：官網給出的經過程序設置模式的代碼是錯誤的。如圖，最後一行代碼有誤，應該爲：

  第五個是系統狀態（system status），查定義就行了，其中的standby狀態在Pixhawk裏就是還沒解鎖的狀態，active狀態就是已經解鎖，準備起飛的狀態。

第六個是mavlink版本（mavlink version），如今是「3」版本。

其他的消息也是相似的結構，各個數據的定義能夠查看mavlink官方網頁的說明，這些說明通常在網頁的前面部分。具體說明以飛控爲準，mavlink僅提供基本的定義。

有幾個相對特殊和容易混淆的消息再特別說明下：

#76消 息（command long），該消息是發送長命令，通常是地面站發送給飛控命令用的。該消息組成以下圖。目標系統（命令的接收方，就是目標系統編號sysid），目標單元 （命令的接收單元，就是目標單元編號compid）。command數據是這條命令的編號，用於區別不一樣的命令。confirmation數據，筆者還不 是很明白，大概是是否須要收到命令後回覆確認信號的意思。接下去有七個參數，這些參數是執行這條命令所須要告訴飛控的，許多命令都用不到七個參數，多餘的 參數清0就能夠了。

  Pixhawk支持的命令有許多種 （但不是全部mavlink命令都支持）。要看mavlink提供了哪些命令請在介紹mavlink的官網查詢mav_cmd，在網頁的中上部分。好比： 第176號命令 MAV_CMD_DO_SET_MODE。這條命令用於改變飛行器的飛行模式，第一個參數就是設置飛控的base_mode，第二個是設置 custom_mode。想要經過這條命令正確設置pixhawk的模式須要查看PX4代碼，mavlink對參數的描述不夠具體。

現 在應該對介紹mavlink官網的佈局有所瞭解了吧。網頁前面主要講了各種數據的取值和含義，好比飛控類型（mav_autopilot）,飛行器類型 （mav_type）等，其中mav_cmd是比較特殊和重要的一種數據。網頁的後半部分主要講了mavlink消息的種類和數據組成，這裏會用到各類數 據，具體數據定義的能夠回到前半部分去找。可是mavlink是個通用的通信協議，不一樣的飛控支對mavlink支持方式不同，通常都只支持一部分mavlink消息，還會本身擴展一些mavlink協議所沒有定義的消息（pixhawk和apm都是如此），具體都以飛控代碼爲準。

大概說說地面站和飛控的通信流程，由 於沒看過地面站的代碼，因此極可能有誤，還望發評論指正！通常飛控在鏈接上地面站後都會主動向地面站發送心跳包，飛行器姿態，系統狀態，遙控器信號等組成 的數據流。各個數據都會以必定的頻率發送，好比心跳包通常是1Hz，姿態信息會快些，pixhawk用數傳鏈接QGC時的姿態數據發送頻率在7-8Hz左 右。通常地面站會在剛鏈接上飛控時發送命令，請求飛控傳回全部參數（QGC就是這樣），飛控根據本身的狀況判斷是否接受地面站的請求，並根據不一樣的命令執 行相應的操做（有些命令須要飛控回覆地面站確認信號）。以後地面站根據用戶的操做會發送相應的mavlink消息給飛控，好比設置航點，改寫飛控參數等。 聽說數傳是半雙工的（在同一時刻只能選擇發送或者選擇接受數據，不能同時收發數據），地面站和飛控之間如何避免數據衝突（即雙方同時向對方發送消息）的機 制筆者並不清楚，但願能拋磚引玉。

mavlink有不少的版本，雖然都是mavlink v1.0，但仍是有不少不同的地方，不一樣飛控，不一樣時間的mavlink文件都會不同，筆者講的mavlink是在這裏下載的https://github.com/mavlink/c_library。mavlink代碼所有由頭文件組成，能夠很方便的添加到你本身的代碼中。  

  能夠看到，裏面有多個文件夾和幾個頭 文件。pixhawk，ardupilotmega（apm），matrixpilot這類的文件夾裏都是各個飛控本身定義的mavlink消息類型，原 始的mavlink消息放在common文件夾裏面（大部分消息都在common文件夾中）。checksum.h中存放的是計算校驗碼的代碼。 mavlink_helper.h裏面是將各個消息包補充完整（調用checksum.h中的函數計算校驗碼並補上消息幀的頭，好比sysid和 compid等）成爲mavlink消息幀再發送。最主要的功能集中在這兩個文件夾中。mavlink_conversions.h裏是dcm，歐拉角， 四元數三種姿態表示方法之間的轉換代碼。

下面以發送心跳包 （heartbeat）爲例，說明下如何使用mavlink頭文件來發送心跳包。首先打開common文件夾中的 mavlink_msg_heartbeat.h 頭文件。這個頭文件能夠分爲兩部分，一部分用來打包、發送heartbeat消息，另外一部分用來接收到heartbeat消息時解碼消息。 heartbeat.h定義了heartbeat消息對應的數據類型：

     
     
     
     

      
      
      
      

      
      
      
      

      
      
      
      

      
      
      
      

      
      
      
      

      
      
      
      

      
      
      
      

      
      
      
      

      
      
      
      

     
     
     
     
typedef struct __mavlink_heartbeat_t{ uint32_t custom_mode; ///< A bitfield for use for autopilot-specific flags. uint8_t type; ///< Type of the MAV (quadrotor, helicopter, etc., up to 15 types, defined in MAV_TYPE ENUM) uint8_t autopilot; ///< Autopilot type / class. defined in MAV_AUTOPILOT ENUM uint8_t base_mode; ///< System mode bitfield, see MAV_MODE_FLAG ENUM in mavlink/include/mavlink_types.h uint8_t system_status; ///< System status flag, see MAV_STATE ENUM uint8_t mavlink_version; ///< MAVLink version, not writable by user, gets added by protocol because of magic data type: uint8_t_mavlink_version} mavlink_heartbeat_t;

若是mavlink的發送方式可使用（串口發送，函數接口也兼容），則能夠調用 【1】

     
     
     
     

      
      
      
      

     
     
     
     
static inline void mavlink_msg_heartbeat_send(mavlink_channel_t chan, uint8_t type, uint8_t autopilot, uint8_t base_mode, uint32_t custom_mode, uint8_t system_status)

其中的chan是channel的縮寫，用於選擇發送的串口或者usb口。type就是飛行器類型，其他參數不明的能夠看看本博客的上面文章。

該函數功能是將傳入的各個參數按照對應的格式放到heartbeat消息包中（即打包）

這個函數內部有一句預處理：

     
     
     
     

      
      
      
      

     
     
     
     
#if MAVLINK_CRC_EXTRA

是說是否使用額外的crc校驗字符（默認使用），詳情請看第一篇博客中對於兩個校驗字節的說明。

函數中會調用函數【2】

      
      
      
      

       
       
       
       

      
      
      
      
_mav_finalize_message_chan_send(chan, MAVLINK_MSG_ID_HEARTBEAT, buf, MAVLINK_MSG_ID_HEARTBEAT_LEN, MAVLINK_MSG_ID_HEARTBEAT_CRC);

       
       
       
       

        
        
        
        

       
       
       
       
MAVLINK_MSG_ID_HEARTBEAT//這個是心跳包消息對應的編號 這裏=0

        
        
        
        

         
         
         
         

        
        
        
        
MAVLINK_MSG_ID_HEARTBEAT_LEN//這個是心跳包的長度 注意這個長度僅僅是payload的長度，不包括幀的頭尾。

         
         
         
         

          
          
          
          

         
         
         
         
MAVLINK_MSG_ID_HEARTBEAT_CRC//這個是heartbeat消息對應的額外的crc校驗碼 這裏=50

這個函數位於mavlink_helper.h中，用於更新消息幀的編號（seq 每發送一幀加1）並將消息幀的頭和計算校驗碼，使得成爲完整的一個mavlink消息幀。最後調用串口發送函數進行消息幀的發送。

若是隻是想將對應的心跳包參數按照心跳包的格式存放好，則能夠只調用

      
      
      
      

       
       
       
       

       
       
       
       

      
      
      
      
static inline uint16_t mavlink_msg_heartbeat_pack(uint8_t system_id, uint8_t component_id, mavlink_message_t* msg, uint8_t type, uint8_t autopilot, uint8_t base_mode, uint32_t custom_mode, uint8_t system_status)

將參數打包爲heartbeat消息幀，待以後使用。

解碼消息幀時能夠調用mavlink_helper.h中的

      
      
      
      

       
       
       
       

      
      
      
      
MAVLINK_HELPER uint8_t mavlink_parse_char(uint8_t chan, uint8_t c, mavlink_message_t* r_message, mavlink_status_t* r_mavlink_status)

它會將收到的字符一個個進行解碼，會檢驗收到的校驗碼是否正確；有效載荷的長度小於最大長度而且和該消息的長度一致。若是一切順利，將會獲得解碼到的消息，放在解碼獲得的消息幀類型中

      
      
      
      

       
       
       
       

       
       
       
       

       
       
       
       

       
       
       
       

       
       
       
       

       
       
       
       

       
       
       
       

       
       
       
       

       
       
       
       

       
       
       
       

      
      
      
      
typedef struct __mavlink_message { uint16_t checksum; ///< sent at end of packet uint8_t magic; ///< protocol magic marker uint8_t len; ///< Length of payload uint8_t seq; ///< Sequence of packet uint8_t sysid; ///< ID of message sender system/aircraft uint8_t compid; ///< ID of the message sender component uint8_t msgid; ///< ID of message in payload uint64_t payload64[(MAVLINK_MAX_PAYLOAD_LEN+MAVLINK_NUM_CHECKSUM_BYTES+7)/8];}

其中的magic是一幀的起始標誌（FE=254），就是mavlink_stx的值。

其他的mavlink消息也是相似 的，舊的mavlink代碼中有些類型的消息類型可能會找不到，使用時要注意接受和發送方使用的mavlink版本是否兼容。common文件夾中的 common.h裏面包含了要用到的數據類型和全部消息的頭文件，使用時直接包含進來便可。

來自爲知筆記(Wiz)