 Thank you so much for coming. My name is Ike. As you said, I'm very excited today to show you something I've been working on for a few months. It's a brand new KDE application. It's called Kirogi. And don't worry, by the end of the talk, you will also know what the name means. I'll start things off though by quoting the one sentence description of the application that is, you know, in the .desktop file and shows up in your menu, which is that Kirogi is a ground control application for drones. And I want to tell you what each of the constituents in that sentence mean. So first of all, drones. These are the drones that the application currently supports. Some of them are here on the desk. This is standard consumer grade hardware. This is the chicken head thing, which is always fun to demo. You can buy these relatively easily in retail stores. You can buy them online. They're not that expensive. One kind of important takeaway here is that these are by different manufacturers. So the application is limited to supporting one brand of drones. It can support hopefully in the future, all of them. Now, what is the ground control? This is a schematic drawing of a drone software system, which has two principle components, thanks to XKCD for that artwork. On the drone itself, the software running there is known as the pilot. That's because it controls the vehicle. It controls its control surfaces. It makes the motor spin up at varying speeds. And the operator on the ground is using the ground control to send commands to the pilot. These can be very simple and direct commands, like fly left, fly right, fly up, fly down. They can also be more complicated. They can be more high level. For example, fly relative five meters or fly to a particular GPS coordinate, depending on the capabilities of the pilot and the hardware. Now, a little bit about drone piloting, like any sort of aircraft, a drone, a multi-copter, as it's called, can roll around these three axes. Different from a fixed wing aircraft, multi-copter can change direction without turning, which is pretty cool. Direction is changed by tilting the vehicle in a particular direction, so you don't need to turn it around if you want to fly backwards necessarily, which means the camera in front can look at the point of interest regardless of the vehicle orientation. And also different from a fixed wing aircraft, it can directly move up and down. Now, it's already time to demo the application and show you what it's looked like. Don't worry, I'm not going to attempt to fly drones in this room. This would risk giving a whole new meaning to crashing the demo. So I'm not going to do that. All right, it does come up nice. So this is the welcome screen. All of this is a little bit programmer art and might need some help from the VDG to make this prettier. But on this screen, you end up selecting your brand of drone, either using this button here at the bottom or over here. You can change that selection later on. It will also remember it for you. If the app quits while you're flying, it will try to get you back to where you left off as fast as possible. In this case, I'm going to connect to Paradrones, which you will now discover and connect to and show you a little bit about it. It's the flight checklist where you can check if your vehicle is ready to fly and then jump into flight controls. Now you can see yourself. In the back, you have... Oh, it's pretty decent. In the back, you have the video feed from the drone. As you can see, there's a virtual horizon which shows some of these axis rotations. Over here, in the upper left corner, you have airspeed, altitude, distance to the ground control. On the right, you have your flight time, which is really important, especially in connection with the battery status of the vehicle. You want to keep track of that. You want to know how long you've been flying and how that is having an impact on your battery life, so you know how much time you have roughly left. And the signal strength of the vehicle. Now, at the bottom right, you can have some amount of control over if you want to record a video or still picture and make a shot. In the future, there will be many more controls of that kind. These things are kind of flying cameras, so the screen will end up being kind of camera up with D-pads. Speaking of those D-pads, on the left, this is multi-touch. Unfortunately, I can't touch the projector screen, but I will show you the app running on a mobile phone very shortly, and then we can attach those. On the left, vertical, up-down, turning the vehicle on the horizontal axis. Over there, vehicle tilt, which makes it fly in a particular direction. Now, I want to open the sidebar where a lot of other stuff is not necessarily buried, but can be found. There you can find various vehicle actions. One fun thing to do is flip the vehicle. These are currently disabled. I haven't implemented that on this particular drone model, but you can flip in any sort of direction. Geofence, which allows you to confine the vehicle to a particular area and maximum altitude and distance from the ground control so it doesn't run away from you. And various performance settings. Over here on the lower left, there are some presets that you can use to sort of switch all of these settings faster. If you're trying to record a stable video, you probably don't want the vehicle to act very sort of twitchy, which is what the film preset is for, which is very low values, but these things are pretty fast. This can go like 50 kmh, so you can wrap that up and can have a lot more fun with it and sort of fly a bit more athletically, if you wish. I will move one of those. You can see it shows the current value as a line there, and only when you release, it will tell the vehicle to assume that and then sync up. All right, yeah. This is not the only screen of the application. Let me open the menu. I can find my pointer here, yeah. The next important page is the navigation map. This is quite bare bones right now, and this is a bit fake data. I don't have a GPS fix in here, but this is our current location, and let's just pretend the drone is flying out there right now. This allows you to see where you are, where the vehicle is. It allows you to fly the vehicle also to a spot on the map by just tapping. Again, this is very bare bones right now. However, this part of the application will probably see most of the expansion in the future, allowing mission planning, setting bait points, allowing the application to fly a free program path. That's where the autonomous comes in, right? And finally, we also have an about screen where you can see my collaborators, and I will tell you more about them shortly. Now let's switch back to this video feed. And in Syria, I could use a camera man right now, but that's right to do this myself. And go into my phone here. Let's see. All right. Ah, well, it works pretty okay. Maybe I can position this a bit stably here and do it from over here. Unsharp, good enough. Let's jump into that other drone that is on the table there. Yeah, yeah. These things that you saw, even if they're not flying, you can see there's this multi-touch. It jumps to your initial touch position, so it sort of adjusts to your hand size, whatever that may be, and then you just move around. I just disable the takeoff button at the top for demo mode. It's a bit scary to carry these around, especially with like a Samsung curved display, and then you accidentally take off, so I need to implement something nicer there, like slide to fly or something like that. So this is really a mobile-first application, because of course, if you're out and about with your drone, you probably don't want to carry a heavy sink pad around, although you will see I also did this at some point, because since I can't fly it in the room here, I recorded a little video of some significant development milestones, which I'm going to show you. All right, so I started hacking in February of this year and the first thing I tried to do was get the video feed from the vehicle and now it's video-ception already, so that's pretty fun. And then about 10 days later, I had enough of the protocol implemented to get some telemetry from the vehicle. So this is not the drone flying, this is me picking the drone up, but you can see the virtual horizon is doing things, was getting UDP packets from the vehicle and decoding them and all of that stuff, and so I could talk to my drone for the first time. And then I did the first flight. Now, you have to know that the city I live in in South Korea is a no-fly zone, so it's not really allowed to go fly there, so I did it at night at like 3 a.m. Also because only by 3 a.m. I actually had it working and went to sort of my backyard and sat on the ground with a sink pad. The flickering is due to the way I did the video capture, no worries. And you can see I had the bug there, I reversed the axis on the D-pad, so I'm pulling it back, but it's flying forward, but you know, I was happy, it worked. After like lots of ninja bug fixing. And then two weeks later, to be honest, by far the most painful part of development was making it work on Android. I'll tell you a little bit more about why later. But yeah, this is on my phone, connecting. That's cool. And this is me flying. Now, the other thing you need to know is that I spent most of my time hacking, so I'm a terrible pilot, and this is very precarious, and I did fly into my TV, I did fly into my wallpaper, there's like cuff marks there. But yeah, it's a bit scary, don't do this at home. Why did it work? So again, I was very happy. And finally, I did some field testing, I went to a satellite city of Seoul where that is outside the no fly zone and had some fun for the first time. And after I do a turnabout, you can see one of those flip actions I showed you earlier, you know, in action, which is always fun to look at. I have a still picture from this, where it looked like a selfie from the drone, which is fun. It's one of the use cases for these. It's to take really cool selfies. Woo, all the drones are fun. And this is slightly overwhelming, it was very windy, you can see it sort of shaking the wind, but it's pretty good at holding position actually. All right. Now why did I make this? Most of you in this room are probably familiar with one of the founding stories of the whole open source movement, which is Richard Stallman being very angry at a printer driver he couldn't get Swiss code to to make that printer work with his system. It turns out this app has a almost similar sort of origin story. I bought this drone in February when I was visiting my parents-in-law down in Busan, the coastal city, which is also outside of the Seoul no fly zone. So you can buy lots of drones there in electronic stores. And so I bought this drone, and none the wiser I of course tried to fly it for the first time in my mother-in-law's living room. So it was hanging there, making a lot of wind and noise, and I couldn't land it, because the application, the official application that came with the drone immediately crashed. Now, and I reopened it again, immediately crashed. Now why is that? It turns out that manufacturer had since then released a newer drone, made a new major version of the application, uploaded it separately to the Play Store, stopped updating the old app, new version of Android came out, things broke, it crashes. So I was like, this probably should be open sourced. This is a bit crappy, and wrote my own. So I think it's a sort of classic free software use case. Most of the proprietary apps are either single vendor or even single drone. This app works with multiple models, so multiple different app vendors. And those proprietary vendors, they often sort of abandon their old apps when they bring out a new drone. So this can give new life to your drone and allow you to use the same software across sort of your fleet of vehicles. And I think it can in the end just serve users better to have an open source app like this. I also personally wanted to learn how to make a KDE mobile app. I had never done that. I wanted to know what's the status of that. It works, so I'm pretty happy with the outcome. And drones are just found. These are like flying computers, the little ARM devices. You can ADB shell into them and you can hack around there, it's pretty cool. So let me give you a little bit of overview over the application. It's of course written in C++ and QML and it heavily relies on Kirigami for the UI which makes it work really well across the desktop and mobile. It's almost sort of a pure KDE app to the extent that still means something because very intentionally we pushed a lot of things upstream into Qt and so on over the years. But the only dependencies it has that aren't part of either Qt or frameworks are Gstreamer which I use for video and shout out to those guys. They were incredibly helpful on the IRC channel and it's the only thing I found that works very well across Android and desktop with hardware acceleration, so really great stuff there. And I use a third-party library for dynamic DNS which is used for vehicle discovery on a network called Qt ZeroConf. We have a framework for that called KDE and NSSD but unfortunately it doesn't work on Android yet. This could be something of interest to Falker, I guess. I think it's not that hard to change. Hopefully we can get that done and then it will basically be pure Qt and frameworks. And since it's a recently written app, I tried to use no deprecated APIs or try to give a spin to some new Qt features like input handlers. I'll not go into these boxes in too much detail but the main takeaways from the software architecture is that the application UI uses a shared backend library. This has public APIs and C++ and QML so you can write your own application using this library and you don't have to write all the code of talking to vehicles again. The library in turn loads support for vehicles of a particular type or manufacturer from plugins. Plug-in interface is also public so you can develop your own standalone plugin and get it in there. All right, now an interesting thing specific to KDE mobile apps on Android. One of the things that I hear a lot is, well, this must be like grossly inefficient and bloated compared to a native app because you need to bundle Qt in there. You need to bundle frameworks in there. Isn't it going to be a huge download? But it turns out that as far as I can tell, we're actually pretty competitive. These are download sizes for two of the most popular proprietary apps. These drones are made by Parrot. They have their own app which is very well done but a little bit bigger than Kirogi and DJI is the market leader for consumer drones and their app is really pretty hefty. Now, those apps currently do have more features than Kirogi does but a lot of that comes down to code more than assets and I think as Kirogi picks up speed and gains some of those features will stay pretty competitive on the download size from there. Now, you've seen it all along on my T-shirt I think so I live in South Korea and in South Korea it's not a thing until it has a cute mascot so I knew I wanted to have one. I'll tell you about the mascot. So, bald geese are actually some of the most competent birds there are when it comes to flying. They are the second fastest animal on the planet. However, the mascot for Kirogi is by the farm goose that however flies even better thanks to superior KDE technology. So, it's early adopter right there, one of our best users and of course Kirogi is the Korean word for wild geese. I lived there, I wanted to have a new K name I still like K names and that works. So, a really cool thing about this mascot is that it was actually done in Krita. So, we have the KDE forums, the KDE forums for Krita have an artist wanted section. I had an idea for this character and I made the post there looking for artists. I got immediately within like the next 24 hours about half a dozen really great submissions. I had a really hard time picking who I wanted to work with from like accent portfolios. I ended up working together with a French second year art student, Lily Tully. And I tremendously enjoyed working with her. She was incredibly professional and talented and within weeks we went from the initial idea through some sketches which I can show you to the final result. She did a whole number of poses at every turn. She sort of let me pick my favorite and she endured all my lengthy communication about the licensing requirements to be able to redistribute her artwork and she was really interested in sort of giving back to the Krita community and helping me with that. So, yeah, it was really amazing. She did some additional sketches for head poses that Raphael Brandmeier from the VDG did the application icon based on. And yeah, so that's really great. I'm amazed by the scope of the KDE community that I think takes dog footing to like a whole new level that we have a painting app that you can use to make artwork for KDE products is just great. So how did the project go so far? What went really well? So the community is super amazing. Believe it or not, I've been a KDE developer since 2005 but this is the first project that I ever started from scratch. I've worked on apps before. I've maintained apps before, but I didn't start them. So it was fun to have a whole new experience. What is it like in KDE to start a whole new app? And I got so much support. Both people putting in effort, putting in real work but also just cheering me on, sharing the enthusiasm for what I was doing and it was really easy to stay motivated even as I was struggling with some of the tech there. So it was really great. The tooling is comprehensive. Those points kind of work hand in hand. We have a really great Android SDK Docker image that you can use to sort of dev on Android apps locally and that is then also used by our CI system to make builds. And Elish did a lot of that and helped me a lot, nightly session. So it was really fun. So thank you for that. And you know, as I said, we have these great content creation apps. I also edited that home video earlier using KDE Live. Just the scope is just amazing. The conclusion of trying to learn to make KDE mobile apps is that I'm pretty happy with it. It worked out really well. However, Android is still a bit frustrating. And most of that is down to the platform. I think making my first Android app, I guess that's to be expected but it was a really steep learning curve. There's lots of gotchas. At some point I had a lip hierarchy but it turns out that on Android, the main binary gets turned into lip name of your executable. So I had a naming conflict there and got no good errors about that. So, you know, lots of gotchas like that. I think documenting those or, you know, automating some of those away could help there, you know, make our community more performant at putting more of our apps on Android. Also, maybe some helpers like using our SVG icons as is instead of turning them into Android's proprietary XML format. And I really hate logcat. I still don't know how to, like, filter through the deep loop messages effectively. But overall, it was okay. As you saw, it took me about two weeks to figure it all out. I would really love if more frameworks modules get Android ports. I really look forward to focus talk on that later. KD and SD, as I mentioned, is on top of my wish list. Now, last but not least, future plans. I have not made a stable release of the application yet. It's already working quite well but I want to sort of polish it up a bit more and then slap attack on that and figure out how to get it on the Play Store under KD's account. And as I mentioned earlier, the navigation map will see a lot of new features, mission planning, waypoints, survey tools, that kind of thing. And I'm very curious if I can switch from cute location, cute positioning there to marble because marble does have a lot of useful tools to put stuff on top of the map. It even has an Android port. It even has a Qt Quick 2 API but it's currently disabled in the build system. I guess they're not really happy with supporting that yet. I'm hoping to find someone from the marble team at the conference later this week to talk about that and figure out how we maybe can help each other. Lots of stuff to do on the media side. This has a camera gimbal which, you know, there's video stabilization but can also be manually controlled. So I want to have something in the UI for that. You need to be able to download the media you record from the device. In the case of these drones, there's actually an FTP server running on them so KIO can do that. I just need to slap a UI on it. And a gallery to browse the stuff you've recorded as well as the ability to record streams locally. Now, there are these consumer grade drones which use proprietary protocols, two of which have implemented so far but there's also great insidious open source community around do-it-yourself drones and they've developed some open source protocols which I'm of course like really keen to support in this project. The most well-known is Mavelink. There's also the multi-v serial protocol from the Arduino community. I hope to have plugins for those relatively soon. Tomas, if he's in the room, has been hacking away on the Mavelink plugin already. I look forward to talking to you about it. FPV, first person video. One of the most popular ways to fly drones is with video goggles strapped to your head. I want to learn more about that and figure out how to make UI modes optimized to that. Maybe the preceding speaker can help me with that. Yeah. If you want to find out more about the application or if you want to download a nightly build, the website currently has Android builds, 64-bit and 32-bit, and it has a flat pack for desktop Linux. You can grab those, check them out. And if you have any other questions, find me. If you want to look at those drones, walk over to the table after the talk. Yeah, thank you. That's it.