Google Summer of Code (GSoC) organizations are already available for the students.
This year, one of the KDE projects is a Ground Control Station called Kirogi.
You can check more about the open ideas here: https://community.kde.org/GSoC/2020/Ideas#Kirogi
I mean, cool, but I almost feel like why not work with QGC or Mission Planner instead of rolling yet another GCS?
Hi @Saijin_Naib, good question.
From the README:
Created from scratch in February 2019, Kirogi benefits from a lot of prior art. It aims to provide the following unique combination of features:
End-user focus. As a KDE application, Kirogi aims to be a polished experience that is fun and easy to use for novices and experts alike, with special emphasis on a premium direct control experience.
Multi-vendor. Kirogi aims to have wide out-of-the-box support for many vehicles by different manufacturers. Users should be able to use different vehicles without needing to switch ground control software.
Highly portable. Kirogi aims to support many different mobile and desktop platforms. Users should be able to switch platforms without needing to switch ground control software.
Freedom. Kirogi will always be freely-licensed. Users should have control over and be able to extend and modify their ground control on their own.
Open governance. Created and maintained by the KDE community, an organization with more than two decades of experience in hosting free software projects.
There is also some differences were:
Well that’s really disingenuous (trying to be polite…). None of those bullet points make it different. Mission Planner, QGC, and other GCS applications out there today check all of those boxes. I’m not suggesting you shouldn’t make a new GCS, or that what we have today is the end-all be-all. But to claim those points are what make your system unique and better is just flat out false.
You can make a cool new thing without lying about it.
Technically, that isn’t wrong… MP is mostly windows only and support only mavlink protocol. And QGC mostly only px4 mavlink…
It would have been fun to have it in rust instead of C++
There is also the point where Kirogi is “community owned”, anyone can merge code and take on the project if the main maintainer leaves. There is more points, but I believe that what was told is enough.
Well, it’s not only you!
I’m working to improve rust-mavlink, and probably soon we’re going to have support to multiple mavlink flavors. If you can, help would be much appreciate!
I have done a bunch of tests and small projects using it, and I’m in love.
About the graphic interface…
http://areweguiyet.com/
Maybe the Qt binds can be stable enough to be an official alternative, we could use the QML code in development and move the C++ code to Rust without big issues 
None of the above addresses my initial confusion about why you didn’t team up with MP/QGC.
I’m honestly not sold. This is just YAGCS (Yet Another Ground Control Station) to me. I look forward to being convinced otherwise, but you don’t seem to have made any efforts to team up with the community and the already established software to pool resources/efforts, so I’m honestly a bit baffled.
The stated objectives for GSOC are those bullet points for mavlink enabled vehicles. Which is basically MP & QGC already. Claiming that list of bullet points is what makes this thing different than MP and QGC is completely dishonest.
Again, not criticizing making a new GCS at all. Just the misinformation, whether unintentional or not.
I think I can try to answer here without being biased. If you look at the commit history of me and Patrick you will see that we are very active in the QGroundControl communities, by number of commits, saying that we did not approach qgc first is misleading, it’s because we work on qgroundcontrol we would like to use Kirogi as testbed for a summer of code.
Trying to counter some pointed made:
mission planner: it’s c# based, will only work with Windows, maybe Linux and Mac with mono but the effort to make a working binary is too huge, also it would be impossible to run on Android / iOS without a total rewrite. because of this I’ll only focus on qgc.
qgroundcontrol: it’s based on the same technology as Kirogi, so we have a match here, but it’s not just about technology.
QGroundControl is slow to evolve - some patches I delivered where merged two years later. This is mostly to the current maintainers sometimes lacking time for it, which is understandable.
Kirogi has no concept of “owner/maintainer”, the (Kde) community Owns it so if the creator stops doing reviews, any other member of the community can review/merge.
Qgroundcontrol is a single binary with interdependencies: the amount of code right now is huge, and there is no clear separation of libraries and app, the code is quite tangled and that creates a huge learning curve for anyone trying to contribute to it, as it’s not possible to study the source code for “video” without opening the settings, vehicle, camera, app, etc. everything is linked.
Kirogi on the other hand is based in clear separations and clear plugins, making the code easier to isolate, and test.
Qgroundcontrol suffers from the “not invented here” syndrome: it recreates tons of already existing libraries because the developers did not want to use pre existing ones as they tougth this would simplify packaging - being fair they use gstreamer, qt and mavlink.
Kirogi uses libraries to not recreate code, this gives us a slimmer code size for the same goal, and it also improves the development time. This approach makes packaging harder, but after that’s sorted the rest is easier. Also the developers that already know how to use a library we use will get started faster, without relying on reading code, and those libraries have something qgc truly lacks:
Code documentation:
Qgc has little to no documentation, it’s really hard to get some aspects of it (for instance the fact system)
All of the libraries used in Kirogi have around 90% of code documented.
Qgroundcontrol is tied to a specific firmware and adding a new one is hard as it was not tougth on having backends as first class citizens, rewriting the core would be needed to accept multiple backends.
Kirogi started with backends, so it’s a no brainer.
“QGC has ties with the industry while kde has not.”
Utterly untrue. KDE has developers in intel, blue robotics, Mercedes Benz, bmw, mbition, sap, kdab, collabora. Developers that actively send code to qgroundcontrol (if you look kde is good né of the 3rd contributors to qgc).
On that regard:
Qgc uses qmake as main build system;
Kirogi uses cmake; industry standard for c++; since it’s inception.
We didn’t proposed Kirogi without examining the current status of drone stations, we are contributing with them for years (my 1st contribution to qgc was 4 to 5 years ago).
I’m really looking forward to seeing this!
@Tomaz_Canabrava now that’s more like it! Sounds like a great project that certainly goes where other GCS applications do not.
Tomaz,
Thanks for the detailed explanation.
You’ve addressed mostly all of my concerns.
I look forward to testing Kirogi.
Update on this project :
