GSoC/2020/StatusReports/KitaeKim: Difference between revisions

Revision as of 13:32, 30 June 2020

Imporove MAVLink integration of Kirogi

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

It's comparatively young project so it dose not support all standards of MAVLink protocol which is used to communicate with drone's firmware like PX4 and Ardupilot.

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

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

Progress Reports

Community Bonding Period

Study about MAVLink protocol. - Done
Read code of Kirogi and QGroundControl in comparison. - Done
Study about Qt and C++ development. - Done

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

The MAVLink protocol packet is structured in this way:

^[1]

This protocol uses sub-protocols to extend it's functionality. Those are identified using 'MSG ID' section of the packet. Additional information for sub-protocol is transported through 'PAYLOAD' section of the packet.

First feature that will be implemented during phase 1 is integration of heartbeat protocol.

The heartbeat protocol is one of MAVLink's sub-protocols. It is used to identify existence of vehicle along with its properties. This allows us to discover vehicle connected to the network and notice when they have been disconnected. It also allows us to handle incoming messages appropriately based on type of the vehicle and route messages to system on different interface.

Second thing i did during this period is reading code of Kirogi and QGroundControl in comparison. The QGroundControl is a standard de facto control station for MAVLink drones.

The QGroundControl has MultiVehicleManager and LinkManager which are used to manage vehicles and links as name suggests. The MultiVehicleManager creates vehicle object when incoming message has unknown system id. The vehicle object contains information of the actual vehicle like system id and connection status. The LinkManager creates link object when user wants to establish new connection. Both have pointer to ToolBox which contains pointer to main components like MultiVehicleManager and LinkManager so they can reference each other when it's needed.

The Kirogi aims to support various firmwares including PX4 and Ardupilot. For that, it uses KPlugin.

Kirogi's Ui is general to all plugins. I felt that this generality prevent me to implement various features for plugins. It would be modified to load some plugin-specific elements at runtime in future.

Main components of MAVLink plugin are MAVLinkVehicle and MAVLinkConnection. The MAVLinkVehicle contains information of the actual vehicle. This class has method to processes incoming message and manage connection. The MAVLinkConnection contains QUdpSocket and method to receive and parse incoming messages. Other plugins of Kirogi have same structure.

It seems implementing all functionalities of MAVLink not breaking general structure of Kirogi is quite challenging.

Coding Period Phase 1

Improve integration of command protocol. - Done
Implement vehicle manager for managing multiple vehicles. - Done
Write unit tests of implementation. - To be done
Write documentations about implementation. - To be done

Command protocol specifies that every commands should be followed by ack message from the vehicle that receives the command. If no ack message was received, GCS should resend message until it reaches max count. This feature was implemented before GSoC begins.

New MAVLinkVehicleManager class creates vehicle object when incoming message has unknown system id. It stores vehicle object in MAVLinkVehicleModel class. This class inherits from QAbstractList so that in can provide list of vehicles to UI.

The Kirogi is using KPlugin XT but it can't configure plugin-specific options. The MAVLinkConnectionConfig class is for configuring MAVLink's UDP/TCP/Serial connection. This class is connected to Ui so that users can configure options using methods.

About the future works, Kirogi's UI is generic to every plugins but it seems some plugins need it's own UI. In example, Plan Manager for MAVLink plugin. My conclusion is that i can't implement really generic UI to every plugins so i need to load some UI elements at runtime based on the plugin. Check List, Global Drawer, Navigation Map, Settings pages would be appropriate places to load elements.

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:

Connect vehicle model to Ui so that user can select vehicle to control. - To be done
Implement TCP and Serial connection. - To be done
Implement connection manager for managing multiple connections. - To be done
Check packet sequence and measure loss. - To be done
Write unit tests of implementation. - To be done
Write documentation about implementation. - To be done

Contacts

Email: [email protected]

LinkedIn: https://www.linkedin.com/in/kitae-kim-511032182/

Footnotes

↑ https://mavlink.io/en/

[1] ttps://mavlink.io/en/

[1]

@@ Line 42: / Line 42: @@
 === Coding Period Phase 1 ===
-# Implement command queue to send and receive commands properly. ''- Done''
+# Improve integration of command protocol. ''- Done''
 # Implement vehicle manager for managing multiple vehicles. ''- Done''
 # Write unit tests of implementation. ''- To be done''
 # 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.
+Command protocol specifies that every commands should be followed by ack message from the vehicle that receives the command. If no ack message was received, GCS should resend message until it reaches max count. This feature was implemented before GSoC begins.
-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.
+New MAVLinkVehicleManager class creates vehicle object when incoming message has unknown system id. It stores vehicle object in MAVLinkVehicleModel class. This class inherits from QAbstractList so that in can provide list of vehicles to UI.
-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.
+The Kirogi is using KPlugin XT but it can't configure plugin-specific options. The MAVLinkConnectionConfig class is for configuring MAVLink's UDP/TCP/Serial connection. This class is connected to Ui so that users can configure options using methods.
-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.
+About the future works, Kirogi's UI is generic to every plugins but it seems some plugins need it's own UI. In example, Plan Manager for MAVLink plugin. My conclusion is that i can't implement really generic UI to every plugins so i need to load some UI elements at runtime based on the plugin. Check List, Global Drawer, Navigation Map, Settings pages would be appropriate places to load elements.
-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.
 Some miscellaneous works like renaming some redundant variables or modifying existing classes are done during this phase.