GSoC/2020/StatusReports/KitaeKim

Imporove MAVLink integration of Kirogi

The Kirogi is Ground Control Station(GCS) for controlling Unmanned Vehicles like drones which is developed recently.

It's comparatively young project so it dose not support all standards of MAVLink protocol which is the famous protocol between GCS and UAVs yet.

My goal is to imporove MAVLink protocol integration of Kirogi so that it supports all functionalities of the MAVLink protocol.

Mentors: Tomaz Canabrava, Eike Hein, Patrick José Pereira, Sung Jae Cho

Progress Reports

Community Bonding Period

The first thing i did during this period is studying about MAVLink protocol.

I studied about it before GSoC begins but i felt that i need to study about it more.

Through this, i got familiarized much more with the protocol and become able to think clearly what i should implement.

The MAVLink protocol packet is structured in this way:

The protocol uses sub-protocols to extend it's functionality. The sub-protocols are identified using 'MSG ID' section of the packet.

The sub-protocols use 'PAYLOAD' section to transport information for the sub-protocol. (e.g., arguments for the sub-protocol)

The thing i need to focus on about the protocol during phase 1 is:

1. Heartbeat Protocol: It is used to identify existence of system along with its system id, component id, vehicle type, component type, flight mode and flight stack. This allows us to discover system connected to the network and notice when they have been disconnected and handle incoming messages appropriately based on type of vehicle and route messages to system on different interface.
2. Message Channel: It is used by helper functions provided by MAVLink library. The MAVLink library manages buffers per channels internally. So we need to manage channels to manage multiple vehicles. It seems one channel per one connection is suffice.

The protocol can control up to 255 vehicles at the same time because 'SYS ID' section of the packet is 1 byte size.

So i will implement vehicle manager for managing multiple vehicles during the phase 1. The vehicle manager should be able to identify vehicles based on the heartbeat message, manage vehicle's channel and parse incoming messages based on the vehicle's channel.

Second thing i did during this period is reading code of Kirogi and QGroundControl in comparison. QGroundControl is the most famous GCS for the MAVLink out there.

Through this i learned about MAVLink protocol much more and the way the QGroundControl supports the protocol.

The QGroundControl has MultiVehicleManager and LinkManager class which are used to manage vehicles and links.

The MultiVehicleManager creates vehicle object when incoming message has unknown system id just like what i wrote on the proposal. The vehicle object contains information for the vehicle like system id.

The link in QGroundControl contains actual interface like QSerialPort and information for that like port number.

The LinkManager creates link object when user wants to create new one. One thing interesting is that the link class inherits QThread so that it can run on new thread by creating it. But the Kirogi community's developers are quite skeptical about this because one or up to three thread seems enough to handle incoming messages of 255 vehicles.

Both have pointer to toolbox which contains pointer to MultiVehicleManager, LinkManager, MAVLinkProtocol and name a few. So they can reference each other when it's needed.

The link passes incoming message to MAVLinkProtocol class. It dose MAVLink-specific jobs like parsing packet to message or checking packet sequence and measuring packet lost using 'SEQ' section of the packet. It passes the parsed message to every component like vehicle object or LinkManager. This looks quite inefficient because every components need to process message to check if it's destination is itself.

The Kirogi aims to support various firmwares like tello, parrot, ardupilot and px4. For that purpose it uses KPlugin to load functionalities dynamically in runtime.

One thing interesting is that the Kirogi's Ui is general to all of plugins. The Kirogi uses same QML code for the Ui and loads information from abstract classes like AbstractVehicle. Plugin-specific classes inherit those abstract classes.

This generality was obstacle to me because it seems, for me, different model needs different Ui. I'm still thinking about this.

MAVLink plugin of Kirogi consists of two main components:

1. MAVLinkVehicle: This is used to store information of vehicle. This also processes incoming message and manage connection.
2. MAVLinkConnection: This is used to establish connection. This class receives and parses incoming message and passes it to MAVLinkVehicle. Currently it supports UDP connection only.

It's apparent that we need more classes to manage multiple vehicles and connections.

The challenging thing is that i need to implement all functionalities not breaking the general structure of Kirogi. Or i need to modify other plugins too. I can modify all plugins because i have much time and effort to spend on this but i think it's better to not or minimally touch them because what assigned to me is MAVLink plugin and other plugins are not mine. And modifying already working code can create bugs.

Coding Period Phase 1

Main goals of this phase are:

1. Implement command queue to send and receive commands properly. - Done
2. Implement vehicle manager for managing multiple vehicles. - Done
3. Write unit tests of implementation. - To be done
4. Write documentations about implementation. - To be done

The command queue was implemented before GSoC begins. Command Protocol specifies that every commands should be followed by ack message. If no ack message was received, GCS should resend message until it reaches max count.

The MAVLinkVehicleManager class is implemented during this phase. It creates vehicle object when incoming message has unknown system id. It stores vehicle object in MAVLinkVehicleModel class. This class inherits QAbstractList so that in can provide list of vehicles to QML Ui in future.

The idea is simple. MAVLinkVehicleManager class processes message before MAVLinkVehicle class and creates vehicle object based on it. It passes message to vehicle object if message has known system id.

I thought about future works during this period too. The Kirogi's Ui is generic to every plugins but it seems i need to implement plugin-specific Ui. In example, Plan Manager Ui for MAVLink plugin. My conclusion is that i can't implement really generic Ui so i need to load Ui components at runtime. Patrick and Tomaz created MR about this.

The Kirogi's Ui loads information from currentVehicle variable in main.qml. This variable changes it's value based on signal vehicleAdded from plugin. So it would enough to emit vehicleAdded when user wants to change current vehicle. The signal vehicleAdded is renamed to currentVehicleChanged for that purpose.

And i implemented MAVLinkConnectionConfig class. Kirogi is using KPlugin XT for configuring but it can't configure options per plugins. The MAVLinkConnectionConfig class is for configuring MAVLink's UDP/TCP/Serial connection which will be implemented in future. This class provides information and methods to QML Ui so that users can configure options.

The unit test and documentation are not done mostly because of wry neck. It will be finished before phase 2 begins.

Some miscellaneous works like renaming some redundant variables or modifying existing classes are done during this phase.

Coding Period Phase 2

Main goals of this phase are:

1. Connect vehicle model to Ui so that user can select vehicle to control. - To be done
2. Implement TCP and Serial connection.
3. Implement connection manager for managing multiple connections. - To be done
4. Write unit tests of implementation. - To be done
5. Write documentation about implementation. - To be done

Related Links

• Proposal: Improve MAVLink integration of Kirogi
• Kitae Kim / Kirogi