GSoC/2020/StatusReports/KitaeKim: Difference between revisions
m (→Related Links) |
|||
| Line 9: | Line 9: | ||
'''Mentors:''' Tomaz Canabrava, Eike Hein, Patrick José Pereira, Sung Jae Cho | '''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: | |||
[[File:A mavlink packet structure.png|frame|center]]<ref>https://mavlink.io/en/</ref> | |||
The | 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 uses '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: | |||
# '''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. | |||
# '''Message Channel:''' It is used by helper functions provided by MAVLink library. The MAVLink library manages buffers per channels internally.<ref>mavlink_helpers.h</ref> 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. | |||
Both has pointer to toolbox which contains pointer to MultiVehicleManager, LinkManager, MAVLinkProtocol and name a few. So they can reference each other when needed. | |||
The link passes incoming message to MAVLinkProtocol class. It dose MAVLink-specific jobs like parsing or checking packet sequence and lost using 'SEQ' section of packet. It passes the parsed message to every component like vehicle object and LinkManager. This looks quite inefficient because the signal passes message parameter not an reference and every components need to process message to check if it need to be received by the component. (TODO: Wrute more clear sentence.) | |||
== Related Links == | == Related Links == | ||
Revision as of 13:55, 28 June 2020
Imporove MAVLink integration of Kirogi
The Kirogi is Ground Control Station(GCS) for controlling Unmanned Vehicles like drones 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 uses '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:
- 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.
- Message Channel: It is used by helper functions provided by MAVLink library. The MAVLink library manages buffers per channels internally.[2] 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.
Both has pointer to toolbox which contains pointer to MultiVehicleManager, LinkManager, MAVLinkProtocol and name a few. So they can reference each other when needed.
The link passes incoming message to MAVLinkProtocol class. It dose MAVLink-specific jobs like parsing or checking packet sequence and lost using 'SEQ' section of packet. It passes the parsed message to every component like vehicle object and LinkManager. This looks quite inefficient because the signal passes message parameter not an reference and every components need to process message to check if it need to be received by the component. (TODO: Wrute more clear sentence.)
Related Links
Project Proposal
Improve MAVLink integration of Kirogi
GitLab Personal Repository
- ↑ https://mavlink.io/en/
- ↑ mavlink_helpers.h