This is my first progress report about my GSoC 2020 project.
Please feel free to notice me if you have any question or idea. 😀
What will be implemented during this phase?
The MAVLink protocol supports up to 255 protocols at the same time.
The protocol identifies vehicles using an unique integer value called system id. MAVLink library's helper functions use this value to manage buffers for decoding messages.
To take advantage of this feature, I decided to implement class for managing vehicles. This class will create, delete and manage vehicles on the network.
The vehicle objects will be created in two ways.
First, it will be created if a heartbeat message with unknown system id is received. In this case, vehicle object will be initialized using information in the heartbeat message.
Second, it will be created by user as a offline vehicle. That means users can configure vehicle with system id defined by user even if there is no vehicle with that system id on the network. The vehicle object will be online when a heartbeat message with that system id is received.
The vehicle manager stores vehicle objects in model class that inherits from QListModel. This model allows users to select vehicle on the QML UI.
Vehicle manager implementation
Kirogi uses plugins to load functionalities for specific model at runtime. That means, it loads MAVLinkPlugin class at runtime.
Previously it uses just one vehicle class only. It now uses vehicle manager class to manage multiple vehicles at the same time.
The vehicle manager class has MAVLinkConnection class as a member which is used to communicate with actual vehicle on the newtork.
The vehicle manager communicates vehicles on network using MAVLinkConnection class. It was connected to vehicle class before so vehicle class processed messages. But now, the vehicle manager processes messages and fetch them to vehicle classes based on the message's contents.
About the way how message's fetched to vehicles, we have two options.
First, we can connect vehicle instance to the connection via signal and make it to process incoming messages. In this case, the vehicle will discard message if system id of the message is not matched.
Second, we can query the vehicle with same system id to vehicle model and route the message to returned instance.
As i mentioned, I chose the latter one because if we have many vehicles instances, triggering all of them every time to process message when we receive message is inefficient compared to latter one.
When new vehicle object is created, the vehicle manager emits signal
vehicleAdded() with newly created vehicle to notify to UI elements.
Changes of connection class
Connection class was a member of vehicle class. The only way to establish connection was
MAVLinkVehicle::connectToVehicle(). So we had to create vehicle instance first to establish connection.
I changed it to allow us to establish connection without vehicle class. This change allows us to create vehicle object based on incoming message send by vehicles on network.
As well as things i wrote here, some more works are done. You can check them on the Kirogi's repository.
I feel that we need some kind of structured way to allow Kirogi’s plugins to display UI elements. Because Kirogi’s UI design is general to all plugins, the way how to display UI elements should be general as well.
And i feel that we need some kind of structured way to allow plugins to have it's own configuration too. Kirogi uses KPlugin XT but dose not allow us to have configurations per-plugin basis.
Anyway, thanks for reading! Please feel free to notice me if you have something to tell me!