This spring, a student group from Augsburg University of Applied Sciencesbuild a drone application based on ObjectBox Database and Sync. This is a guest blog post by Michelle from the sync.drone project group, describing the project from start to finish and sharing the results.
The goal: Showcasing the ObjectBox database and Synchronization solution with drones
The goal of the project was to synchronize the colors and flight patterns between two drones coordinating the colours and flight formation autonomously in flight to showcase the ObjectBox Sync solution. Why? For a deeptech database startup it is often hard to demonstrate and communicate the uses of the technology. So, we, a team of students of the FH Augsburg went on a mission to help showcase. Due to ObjectBox’ speed, more data can be processed faster on each drone, saving resources, specifically battery. This allows drones to fly longer, but that really does not have that much sex appeal for a broader audience. However, adding some colorful lights and developing a special kind of light show… Going beyond the scope of a doable student showcase, the technology could be used to synchronize swarms of drones creating beautiful colored messages and patterns in the night sky. While our outlook was more on an artistic installation, such a showcase should also help transfer the application to other use cases, g.g. self-syncing drones could be used in emergency situations during a large-scale search for missing persons. Of course, there are more use cases in the future: Drones can also be used in large warehouses to facilitate the organization of different parts, and pass on the position of a particular part.
In this article, we will explore the process we used to build our self-synchronizing drones, sharing our software and hardware, so you can try it out yourself.
Hardware: Raspberry Pi, 3D printing, and more
In order to build our drones and turn our vision into reality, we had to consider a number of hardware options. It was important that our drone was compatible and programmable with ObjectBox. The drone had to be localizable and airworthy, so that a safe autonomous flight was possible. All parts had to be compatible so we could easily swap parts if something did not meet our requirements.
We built the drone frame from scratch, using 3D printers. The housing was created in the 3D program Autodesk Inventor and the parts were assembled to a drone frame. We used NeoPixel RGB LED sticks to make the drone glow in color. We chose the following components.
Microcomputer
A Raspberry Pi was the most suitable central computer on our drone. It offered both performance and size. We chose the Raspberry Pi 3 B+, which would later control the processes of our drone independently.
Tracking system
After looking at different tracking systems, we chose the “POZYX” UWB tracking system. This ensured an accurate and user-friendly handling.
Accumulator
We had to make sure that the drone’s battery would last long enough to power a Raspberry Pi, LEDs and a POZYX tag in addition to the flight hardware. First started with a 6 cell LiPo battery with 5000mAh. However, later in the project, we replaced the battery with a lighter and more compact 6-cell LiPo battery with 1800mAh.
Engines
The engines (1750 kV) from the Drone-Racing sector had enough power to make the drone fly. Motors with even lower kV would have given the drone more power, but are much more expensive.
Flight controller
As flight controller we chose the “Omnibus F4 V6” chip, which ran with the open source software “Beta Flight” and was accessible via the so-called Multiwii Serial Protocol (MSP). This allowed us to use the advantages of a proven flight software, and also transfer the flight instructions via USB directly to the flight controller using the MSP.
Electronic Speed Controller (ESC)
For the ESC , which implements the instructions of the flight controller by direct voltage changes at the motors, we chose a 4-in-1 model. With only one connection cable to the flight controller, all four motors can be controlled at the same time. Usually one ESC is required per motor. It was also compatible with our hardware.
Software – Tracking, Flying and Syncing the Drones
Except for a start signal, the drone was supposed to operate without a remote control. Several drones would coordinate themselves at the same time according to the instructions. We decided to develop the code in three separate “cores”, which were merged at the end of the project. These were divided into “tracking”, “flying” and “syncing”. Using the university git lab as a repository, we were able to simplify development and share the code with the group. This allowed structured work on the code. With the help of ObjectBox and Prof. Dr. -Ing. Alexandra Teynor we were able to assemble the following code parts.
Tracking
For collision avoidance it was important to implement tracking, so that the drone knows it’s own position. We solved this by using the position calculated by the POZYX tag, which was then transmitted to the Raspberry Pi in the tracking core. We read the coordinates from the IMU sensors (“inertial measurement unit” = unit of measurement based on multiple sensors ) from the POZYX tag, but not the exact positioning.
The so called “heading”, or yaw of the drone, is read out by a magnetometer. However, this internal “compass” reacts to disruptive factors and can deliver inaccurate results. We solved the correction of the heading via an algorithm using OpenCV. This algorithm uses a small camera module on the drone and special markings on the ground to detect its orientation. This allows the direction vectors of the drones to be calculated more accurately.
Flying
In the flying core, the flight instructions were developed based on the tracking core data, and then implemented by passing this data on to the flight controller. First of all the drones have to be lifted off the ground. For this purpose we used a laptop keyboard control, which forwarded flight instructions to the drone via a web socket.
Flight control
The Raspberry Pi establishes a serial connection to the flight controller via USB. As soon as this connection is established, flight instructions are transmitted in the form of inclination values for roll, pitch, yaw and throttle (thrust). These values may lie between 1000 and 2000. In a neutral position, roll, pitch and yaw are at an average value of 1500.
Using Python, we calculated the required roll, pitch, yaw and throttle values and assembled them using the Multiwii Serial Protocol. This was translated into pure byte code and sent to the flight controller via the USB cable. The flight controller now tries to reach the corresponding values. In order to turn to the right, the left motors are turned slightly up and the right motors slightly down. The ESC received the commands for the desired motor speed from the flight controller. It then applied the required voltage to each motor according to its instructions. The communication between the flight controller and ESC happened either by an analog (PWM) signal or a digital signal (D-Shot).
Keyboard control
The computer runs a Python script that registers keystrokes and converts them into instructions. For example, pressing the right arrow key creates the command “raise-roll” and pressing the left arrow key triggers the command “lower-roll”.
The drone also runs a Python script that opens a web socket to which the PC script connects. Each time a key is pressed on the laptop, a corresponding command string is generated (e.g. “raise-yaw”) and sent to the drone via the web socket. As soon as a string arrives, the relevant value (roll, pitch, yaw, throttle) is increased or decreased.
To prevent the drone from crashing if a connection is lost, the values are flattened algorithmically.
ObjectBox Database and Sync Drone Implementation
In the syncing core, the position data of all drones as well as the LED color, should be exchanged and commands passed on. The RGB color space of the LEDs was mapped to the x-, y- and z-position. In this way, the sync features of the drones could be displayed without them flying. For the implementation we used the ObjectBox database and the ObjectBox Sync Server.
Originally, we had planned to use the ObjectBox Go Binding because it is precompileable and very fast. However, the POZYX system we chose used Python. There was also already a Python implementation available for our flight controller, but none available for Go. Luckily, ObjectBox offered to develop and provide a small Python binding of their database according to our needs. This included all ObjectBox functions that were relevant to us. It was officially released in version 0.1.0 specifically for our project. As a result, the ObjectBox database could be easily integrated into our code.
Realization of syncing
In Python version 0.1.0, ObjectBox incorporated the basic features we needed. For our application the simple CRUD functions and the Sync feature, which synchronizes the data in near real time, were sufficient. The database is compact and the speed and ease of use is optimized for restricted IoT devices, for example the Raspberry Pi used in this project.
The sync server is started by running the init-server.py script on the master drone. At first, an empty database (model) was initialized. The master drone then communicates with the other drones via WLAN network connection and synchronizes the ObjectBox database between the respective devices.
1
2
3
4
5
6
7
8
import objectbox
from models.objectbox_models import Led
# initialize an empty DB before the first server start the server
Three entities (classes) are stored: – the identification and position data of the anchors – the identification and position data of the tags – the color values of the LEDs.
The drone stored it’s position and LED color in the database. The master drone then reads out this information and overwrites it with the values calculated by the master drone (e.g. LED color or target position in the future).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
from models.objectbox_models import Led asLedModel
At the end of our project, we had three drones. Depending on the position of the master drone, all drones could synchronize their LED colors. Unfortunately we were not able to finish the flight due to a defect in the flight controller and a delayed delivery of parts. Finally we decided to publish the code for the drone control on GitHub. Additionally, you can get inspired on our website as well as on our social media platforms.
Furthermore, we would be happy, if the project would be continued by another group of students in the future. With our work we have created a basis for many more ideas. In summary, our project still has a lot of ambitious potential for the future.
Thanks to ObjectBox for this great opportunity – we mastered many problems along the way and learned a lot. Thanks for the constant support.We also thank our professors Prof. Dr. -Ing. Alexandra Teynor, Prof. KP Ludwig John and our coach Sandra Hobelsberger for their professional advice and patience. Finally, we would like to thank HSA_Innolab for their additional financial support and FabLab for their advice and resources.
In collaboration with interactive media students of the University of Applied Sciences in Augsburg.
Today’s 0.9 release is not just a step closer to 1.0, but also an important milestone for us: for the first time, all Swift binding source code is available on GitHub. We’ve also improved performance (again) and added useful features like type converters.
ObjectBox’ lightning-fast database offers a cross-platform C API for language-specific bindings. These bindings provide a thin and nimble wrapper around the C calls and expose ObjectBox functionality in the way that feels most natural to the host language (i.e. Swift).
An open-source binding allows you to make changes to ObjectBox and build it on your own, backport it to older OS or Swift versions, and contribute your changes back to us if you feel so inclined.
Is this the binding I’ve been using all this time?
Although it’s one of our newer language bindings, our Swift binding already has a storied and colorful history. The first Swift binding actually predates our C library and was built directly against the core C++ codebase. As such, it used Objective-C to bridge Swift and C++.
Once we had the C library, we set about eliminating the intermediary and started rewriting the central Objective-C portions as pure Swift on top of the C API. The immediate result when we released ObjectBox for Swift 0.8, was a significant speed-up in write operations due to Swift’s new native UTF-8 strings, and struct support.
But for the open source release, we completed this rewrite, and ObjectBox Swift got even faster:
Not having to bridge to Objective-C meant we could take advantage of Swift’s associated types to resolve class/entity associations instead of a runtime look-up, and eliminate a few duplicated classes necessitated by adding Swift features to Objective-C classes. This in turn allowed removing some unnecessary data copying, which translated directly to increased speed.
While we enjoy a good performance increase as much as the next database developer, we also added new features and fixes, like more query comparison operators for scalar types, and improved behavior when adding properties to an entity.
Property Converters
One major new feature of this release is support for converting simple user-defined types into types the database understands. For example, you can mark any RawRepresentable enum with an annotation to tell ObjectBox how to serialize it. Let’s say we have an enum like
1
2
3
4
5
6
enumOlympicRanking:Int{
caseunset=0
casefirst=100
casesecond=200
casethird=300
}
In your class, you simply add the following annotation:
But of course we also let you work with your own types, or system types. Let’s say you wanted to save a window’s dimensions into your database. You do this using a converter class that implements convert() methods that convert your custom type into one of ObjectBox’s built-in types, and back:
1
2
3
4
5
6
7
8
9
classRectConverter{
staticfunc convert(_box:CGRect)-＞String{
returnNSCoder.string(for:box)
}
staticfunc convert(_boxString:String?)-＞CGRect{
guard let boxString=boxStringelse{return.zero}
returnNSCoder.cgRect(for:boxString)
}
}
And then you tell ObjectBox to use that converter using an annotation:
And that’s just a selection of the changes you’ll find in the new open-source release. It contains the entire binding, but also the fork of Sourcery that does its duties as our code generator, and a performance test app. It is faster, more feature-full, and we’ve also squashed some bugs in the binding.
To take a look and get started, simply go to our ObjectBox Swift Git repository, where, in addition to our example application, you can now also find the binding’s source code. Or pull version 0.9 via CocoaPods.
We can’t wait for you to try it out and let us know what you think. Don’t forget to star us if you like it!
Gitcoin is used by nearly 50,000 developers and delivered more than $6.5mm 💰 to open source developers around the world in 2020 ❤️. The topic of sustainability of Open Source and means of securing funds for independent open source developers has been of increasing concern and discussion in the open source community. As a response, Microsoft launched GitHub Sponsorhips, which provides an alternative, but has seen disappointing results for open source developers by and large so far. However, another new initiative aims to support active and good open source citizens: GitHub Stars ⭐. While this does not pay the rent, it helps get people that provide great software and know-how for free, the attention they deserve 🤗. Unfortunately, the process on what happens with nominations and who chooses the stars ultimately is a bit unclear. I definitely submitted three of my GitHub rockstars, but never heard back and none of them has been chosen so far 🤷♀️ (all have fairly successful repos, a ton of stars and are considerate open-minded people judging from their online communications). Possibly also leading to more GitHub Sponsorships being made. 🤞
In 2018, Vivien had the chance to chat with Kevin Owocki, about his latest project GitCoin, and the intersection of open source and blockchain. A lot of what Kevin said is timeless and has been an even more relevant question for the open source community in 2020.
Vivien: Hi Kevin, thanks for talking with me today. Why don’t you start by telling me about yourself and your current open source project, GitCoin?
Kevin: I’ve been a startup entrepreneur over the past ten years, and all of the businesses that I’ve built on or built have been based off of open source software. One of the things that I’ve learned is that value accrual goes to the application layer, to the data that you’re collecting about marketing, and the services that are built on top of the software. Gitcoin is my current project, and its mission is to grow open source. Our thesis is that Blockchain is a game changer for open source funding. There’s so much money in Blockchain right now because of the 2017 Bull market… billions of dollars chasing too few developers. And that creates an opportunity for developers to monetize their work in open source software. Gitcoin is our core product and it’s basically a double sided market: people who want to augment their team can hire talent on a per-issue basis. So, it’s less commitment than hiring someone for a contract. On the other side, developers get to work on issues in open source, learn new skills, meet new people, and get paid using cryptocurrency. We incentivize developers to work on their open source software. The second product that we just launched is called CodeFund, kind of like a sub brand that we’re working on. Basically, it is ads on documentation sites that are aimed at open source developers. So the idea is that if you have a following for your open source repo, you can create passive income by putting ethical advertisements. These advertisements don’t track your users on your documentation site or on your Github and they sustain your open source with passive income. This is a long way of saying that we think Blockchain is a game changer for open source funding and are trying to build the rails for capital deployment to open source projects.
Vivien: We work in the worldwide market where laws are different, e.g. EU vs US. Do you have support for the contracts?
Kevin: Each project kind of has its own license, and we have a repo setup guide where we ask people to add contributor guidelines, licenses, stuff like that. If you look at the Gitcoin terms of service, it basically says that if you develop for this repo, then you are assigning rights according to their license. But the worldwide nature of all of this stuff is very interesting because enforcing IP agreements, from Germany over to the US, there’s not really a court of law that handles that, so we’re kind of waiting for the legal system to catch up in that respect.
Vivien: You’ve built all your business on open source. What do you recommend to other people looking to build on open source?
Kevin: I think it depends on the nature of your business and whether or not open source can accelerate it. For me, I’ve built a lot of B2C companies, and leveraging open source data stores and open source web servers worked for me, but if I was a risk averse financial institution, then I think it’d be different, right?
We think Blockchain is a game changer for open source funding and are trying to build the rails for capital deployment to open source projects.
Kevin Owocki
Founder,GitCoin
Vivien: Why did you choose to always build on open source? What do you think is best about open source?
Kevin: I think that open source tools with an active community are the ones that are going to have the need for developers, because they have support, and support isn’t monopolized by one company. I think that because of the scale of development today, if you have a problem with an open source repo, you can likely search it and find someone else who’s had that problem in the past. I actually just watched Revolution OS, which is an interesting documentary about the free software movement. Then later the open source movement, and it made a really interesting case. Just focusing on creating great software, and not worrying about the RM and licensing of that software, you can get it in the most hands possible. This includes people who are focused on creating working software over comprehensive documentation or licensing, and therefore that tends to create the best software over time. I think those are all reasons that I’ve been doing it, but it’s very much a cultural thing in startups these days. I think if I’d been born a generation earlier, maybe we’d be singing the praises of Microsoft Visual Studio or something like that, but it’s a generational thing, you know?
If you’re an open source developer… it’s about more than good compensation, it’s about doing work that aligns with your values, and has an impact on the world.
Kevin Owocki
Founder,GitCoin
Vivien: So, you use open source projects as a basis – what is your business model?
Kevin: Well, in my prior businesses, we would build off open source but our software itself was proprietary. We sold it with various degrees of success (laughing). I think for Gitcoin we’re still figuring out the business model, so I’m in awe a little bit, about that, but it’s basically a question about where the value accrues in the network. Our core thesis is that by focusing on being open source, we can make our product as good as possible because we have the most contributors. We think that the value accrues in the brand, and the relationships with the customers. So, while anyone can fork Gitcoin and copy it if they wanted to, then they wouldn’t have our network of developers, they wouldn’t have our mission and our ethos, and they wouldn’t have the relationships with the people who are going to deploy the capital. So, I think it’s very much a work in progress, but that’s a strategy at least, Gitcoin is less than a year old so that’s the strategy in year 0.
Vivien: But you’re already quite big, right? How many users do you have?
Kevin: We’ve got about 7,000. We’ve benefited from being well funded by consensus, but I wouldn’t say we’re super big yet, the open collectives of the world have hundreds of thousands of users and so I think, that to me is big. I think we’re still a small startup.
Vivien: What types of projects do you think you’ll be mainly supporting? Like big company type of open source projects?
Kevin: If you picture a Venn diagram of open source software and Blockchain, we’re in the center of that Venn diagram, and it means that a lot of the people we fund are kind of like Blockchain hipster types, to be honest. I think eventually we would like to go into the broader open source community, and traditionally that’s been monetized with big corporate types, and so I think there’ll be a cultural shift and maybe a little bit of a brand shift as we do that. But that’s very much a year 2 or year 3 thing, there’s plenty of money in Blockchain, so we’re in no hurry to exit that niche at this point.
Vivien: So if I have a small open source project, often I struggle devoting my time to it, especially if it’s more of a side project, could I expect to be getting help in your community, and what would I need to expect to pay?
Kevin: One of the things that we found about open source software developers and their motivation is that it’s about more than good compensation. It’s about doing work that aligns with your values, and has an impact on the world. So, if you’re a repo maintainer that wants to incentivise people to work on your repo, having a mission that aligns with your core contributors, and giving them an ability to impact your project are two axes that you can modify in addition to the compensation axis. When you’re seed stage, you want to be working with people that are intrinsically motivated to work on your project. Balancing those intrinsic and extrinsic motivations is really important. If I were talking to a repo maintainer who wants help on their project, I would help articulate their mission, and identify where people can have an impact. Only then would I start thinking about putting Gitcoin balances on their repo.
“There is this paradox with software, that strategic value doesn’t always mean economic value for the authors(…)”
Kevin Owocki
CEO,Gitcoin
Vivien: There’s a whole ecosystem of great libraries that are used by thousands of big companies, yet struggle to maintain their projects due to restrained resources. How can they get paid? Can they get paid?
Kevin: I’ll hedge my answer a little bit and say that I am at the intersection of Blockchain and open source, and I think that Blockchain changes the dynamics of funding for open source. This is sort of outside of my area of expertise, but I do have ten years of experience in working on software prior to doing Blockchain stuff, and so for that reason I empathize with the contributors of these project. They built something that by all accounts brought lots of value for the world. There is this paradox with software, that strategic value doesn’t always mean economic value for the authors, but my hope is that we can solve that problem moving forward. For right now, I would say these contributors could try to put some CodeFund adds up, because if you can earn a couple hundred to a thousand dollars per month by putting ethical advertising in front of your audience, then I think that at least helps ease some of the pain associated with those support requests and feature requests. Right now I think that we’re sort of in the early stages of the Blockchain revolution, and so I can’t say that we have anything immediately up our sleeve, but I hope that things change and turn around for projects like this.
EdgeX Foundry is a free open-source alternative IoT-platform, which has seen wild success in the last two years. Indeed within 6 months the platform has grown its adoption from 1 million to 5 million instances being used in early 2020. By the end of August 2020, EdgeX Foundry hit more than 7 million container downloads, is supported and used by many of the relevant IoT players, e.g. Dell, ubuntu, hp. The platform plans to release EdgeX 2.0 (called “EdgeX Ireland”) in the spring of 2021 with an extensive set of new features.
Two years ago, when EdgeX was still a rather unknown open source initiative, we spoke to the initiators, Michael Hall, Brett Preston (the Linux foundation) and Jim White (Dell), about their ideas and vision of the future. While the platform has since grown a lot, it still endorses these original ideas and the spirit of openness. Read here how it all started:
Jim White
Dell, EdgeX
Jim is Vice Chair of the Technical Steering Committee of EdgeX. He is also Team Lead of the IoT Platform Development and IoT Solutions Division at Dell.
Vivien: What is EdgeX and where are you at with it?
Michael: EdgeX Foundry is a vendor neutral open source platform containing a collection of micro services that take care of different aspects of what you’re going to need to have an edge computing platform. If you’re making IoT devices, you don’t want to reinvent that layer of the stack. Having that common platform for IoT is something that is going to benefit everybody. The Linux Foundation is a neutral umbrella over EdgeX. Inside the project are all the member companies who are actually funding the development, putting developers and marketing resources in, to make it an actual, usable product for everybody. That’s the model of the project and the actual code itself. The main goal of EdgeX is processing and transporting data between IoT devices and sensors and things in the cloud and on the backend. The focus is on being able to respond locally as much as you can, so that you don’t have the latency of going on the cloud and back. And also, being able to continue working, if you loose that connection.
Jim: EdgeX is a an open source platform containing a collection of micro services that take care of different aspects of what you’re gonna have to do to have an edge computing platform. Any of those are semi-dependent: You can replace anything you need to replace. For the status of the project: We just had a year of fast pace growth and we have rewritten everything in Go, so all of our processes are a lot smaller and more efficient now.
Vivien: How are you currently tackling local on-device data persistence?
Jim: We currently use Mongo DB as the persistence engine although we could support almost any kind of persistence store at the edge as long as it was small enough. We also have used SQLite in the past for a couple of customers. However, Mongo DB is the largest element in our portfolio of services. There are a couple of reasons why we are probably going to offer an alternative to Mongo with our next big release in spring 2019: Footprint, licensing, and lack of support for ARM32.
Michael: As we are a collection of microservices, you can always swap out individual pieces depending on what your needs are.
Vivien: Is EdgeX and its components restricted to certain licenses?
EdgeX builds on Apache 2
Jim: EdgeX is an Apache 2 license open source project, so we prefer Apache 2 level or at least a compatible license, because we want to be very business friendly. We want people to take the application and use it in all sort of settings, including actually embeddeding it in gateways. We also want to be very decoupled at discrete points.
For example, if I’m a company like Dell and I use EdgeX. If some of my customers have an absolute demand that a certain database be at the heart, then I want to be able to choose the database, depending upon the customers, the use cases, and the environment that they find themselves in. EdgeX is all about the flexibility. So, for this example, we offer what we call a reference implementation database. Customers or users could take EdgeX and replace elements with their own technology, which may not be open source even.
Michael: You can take what’s open source and add proprietary file systems or hardware depending on what your specific needs are. EdgeX tries to be that common open source base. It provides all of the functionality in a open source license but that still lets you replace bits as needed with whatever it is that you want to run.
Vivien: Can you give us an example how and where EdgeX is currently used?
Jim: There are over 70 companies now that are part of the EdgeX community and each group is using it differently. There are some that are serving EdgeX as the Red Hat model: they are providing distribution, services and support behind EdgeX. A company like mine, Dell, we’re trying to find a platform that actually goes on our gateway. So we’re going to build a commercial version of EdgeX for our own platform. There will be pieces that we will replace based on better performing mechanism to some of our cloud based products. Then you have other groups out there that are proving particular services for EdgeX, for example edge analytics. There are lots of different service capabilities where we see potential replacements. Then there are companies like Samsung that uses EdgeX in their factory floor to help run their automation. So, they are users, but they also want to make sure EdgeX meets their needs. Our community is made of snowflakes, they are all very special *laughs* – common goals but different use cases for almost everybody that is part of the organization.
Vivien: That sounds really cool. In your opinion, moving the data to the edge, what is the edge, where do you see the data ending up, for example more on the sensor level or gateway level?
Latency concerns, cost of shipping up the data, and the ability to actuate locally are key reasons why you have to have edge software.
Jim White
Vice Chair of the Technical Steering Committee,EdgeX
Jim: We absolutely believe EdgeX is a mechanism for the edge. While you could run pieces of EdgeX on the cloud, we do not believe is what the future holds. There are gonna be certain use cases where that works, but latency concerns, the cost of shipping up the data, and the ability to actuate locally are all key ingredients and reasons why you have to have edge software and edge platforms. Now, these are gonna get smaller. At Dell, we are manufacturing gateways of different sizes, because we know that certain use cases are gonna dictate a larger box and other are going to dictate something like a Raspberry Pi or even smaller. We have companies in our foundry that are looking at running parts of EdgeX in things like PLCs, to help address their realtime needs. So, we absolutely believe that the edge is very much going to be a part of our IoT environments. There are going to be use cases that dictate different levels of compute all the way up from sensors to cloud.
Michael: And all of our member companies see a need for that platform, but that platform is not going to be their product or their service. So everybody wants it to exist, so everybody is gonna work together to make it exist, so that they can build their own value-add on top of that or below their device level. Everyone agrees that this is an important thing, that we have to have a solution there for all the innovation that people see on the horizon.
Markus: So, small device level versus gateway – would you say your current focus is on the gateway?
Levels of Edge Computing
Jim: I would say that it really isn’t that one or the other is more important. You’re gonna have situations, as we know from a Dell perspective, where what we call a brownfield device (e.g. a 1979 modbus engine) needs a gateway, because it doesn’t have the ability to communicate into any kind network otherwise. So there has to be a gateway that provides that first level of compute. There are other things that are evolving in the industry: think of say windmill generators, where there is lots of capability right there at the device level, there is a lot of compute built right into those systems. So things will run at that level, and then you have everything in between. Even something like BLE or Zigbee type of environments where there is wifi and ability to connect directly to a network. Typically, we’re finding organizations are reluctant to allow those kind of things to connect into their major networks without some security, apparatus and analytics to see what’s going on, so as not to create problems in their larger networks. So even there, a gateway may be necessary, not because of hardwiring or physical connections, but because you want some insurances in place at the edge before that data leaks on up to your enterprise.
It’s the worst way to build our product except for all others.
Jim White
Vice Chair of the Technical Steering Committee,EdgeX
Vivien: What’s the worse about open source that you’ve experienced?
Jim: *laughs* Now you are going to make me say some things in front of Brett and Michael as members of the Linux foundation… There is a quote by Winston Churchill that talks about democracy, saying it’s the worst form of government except all others. I kind of feel the same way about open source development. It’s the worst way to build our product except for all others. Because it does take time. It’s a community effort and anything done by a community automatically seeks a ground where it’s going to be the best and brightest product. So you get the best input from everybody, but it takes time. It’s easier for say something like Dell to go marching off and build a software solution that they think is the best. It will get there faster but it’s not necessarily going to get there in a way that the world and communities accept more easily. So anything built by many hands is going to take a little bit more time and a little bit more process. But it ends up getting a lot better results I think in the end.
Michael: Whenever you have a community building something you can’t just come in and say “This is what you’re gonna build” because they don’t have to do what you say. And that’s true even with EdgeX. Everybody who is working on it is working for a company invested in it, but there is no one person who can say this is what you’re all going to do. So it’s not enough to say just what you want done. You have to explain and justify why and get people to buy into that. And that takes more effort, but you have to know that what you’re proposing is the right solution, that it’s going to work. If you can’t explain that, you can’t communicate that to the community then it’s not going to get done. As Jim said, it takes time but at the end product is going to be better.
Jim: In this case with IoT, I will tell you that no one company will be able to provide it all. As Dell, we would love to be the company providing it all… (laughter) We have learnt the hard way that in an IoT landscape there are going to be certain things in the company that you can’t touch and IoT has to touch everything. Maybe it’s the network, hardware or operating systems, particular sensors and protocols. You can help to persuade customers to do some things in your way, but you’re never going to be able to get them to do everything in your way and that’s why IoT takes an ecosystem. Which is why we think the second part of EdgeX is so important; our product is important, but just as vital is the ecosystems. We have a collection of companies all trying to work together to provide for interoperability. That is just as important as the actual end product we develop.
No one company will be able to provide it all.
Jim White
Vice Chair of the Technical Steering Committee,EdgeX
Vendor lock-in is not going to work in IoT.
Michael Hall
Developer Advocate,Linux Foundation
Michael: Vendor lock-in is not going to work in IoT. There is no way any company is gonna be able to provide all the needs of somebody. So having an equal playing field for everybody, having that common ground that anybody can come to and interact with anybody else, is what’s going to allow us to fulfill the promise of IoT in general.
ObjectBox DB is an embedded database solution, smaller than 1MB and 10x faster than any alternative. Objectbox EdgeX combines ObjectBox’ speed and ease of use with EdgeX Foundry™ IoT Edge Platform. EdgeX Foundry users can now compute millions of data points on the edge with minimal latency.
We had the opportunity to interview Uwe Trottmann, creator and principal contributor of the app SeriesGuide with over 1 Million downloads on Google Play.
Uwe Trottmann
Small Business Owner at SeriesGuide
He received his M.Sc. Computer Science at TU Munich in 2013 and is interested in making software usable for everyone. If at all, he is only looking for part time work next to his other endeavors.
Uwe: That’s a very good question. I started in school in 2004 because a friend of mine coded a basic vocabulary training program in Visual Basic. I started to improve that program and later enrolled in a programming class in school, which was very new at the time. Right now it’s common to have computer science classes in school, but back then it was not the standard. I started doing other side projects for fun, but only got serious about coding when I started studying computer science at University in 2008.
Dorian: Do you think going to University helped your projects?
Uwe: Yes, absolutely. There’s a lot of technical and theoretical background that you are not exposed to, if you just program. At University, the coding exercises were very easy for me, because I had a lot of practice beforehand. However, I learned so much about other things like designing systems, Software Engineering, how to manage projects. Also the theoretical background, like data structures, how to do things efficiently. Also things I never would have looked at, like computer architecture, how stuff works on the lower levels, etc. Which is interesting to know, but it doesn’t really help with the stuff I am currently working on.
Dorian: But that knowledge of the lower levels has maybe helped you solve some bugs?
Uwe: It has a little bit. I think the only relevant thing that I still come across now is bit operations. But things like registers, or programming in assembler, no. This is probably more helpful for the C guys, which program at a lower level. I like working at a higher level. So I program in Java, Kotlin, for Android, and Windows back in the day. These all abstract the lower level away and I didn’t have to worry about memory management, which I didn’t really like doing back then. It’s complicated and very easy to get wrong. I don’t know if you have heard about pointers, but they are one of the biggest problems with programming in C. If you get a pointer wrong everything breaks, you have security issues, and so on. If you talk to C developers about pointers, they could go on forever.
Uwe Trottmann at Droidcon Berlin 2018.
Dorian: How did you start up with Open Source? Did you start right away out of University or did you do work for other companies and do Open Source on the side?
Uwe: In the beginning I had my own projects and didn’t know about Open Source. The first thing that I open sourced was SeriesGuide. My work on SeriesGuide started as a hobby because I had recently switched to Android and was missing the series management app I previously used on another platform. I first posted SeriesGuide to Google Code and then the Google Play Store in 2010. I later moved it to GitHub 2011. My work got more serious during my computer science studies at University. Once I started using GitHub, I added more libraries that SeriesGuide uses and I contributed to other projects on there as well. GitHub really accelerated the SeriesGuide development.
SeriesGuide Statistics Screen
Dorian: Did having access to other Open Source projects help you develop SeriesGuide?
Uwe: Of course, it tremendously helped. I guess SeriesGuide is probably 80% other libraries, it’s Open Source so you can go check. Some of the API integration with the TV show database I used back in the day was an Open Source library, so I built on top of that. I then replaced it with my own later. Also if you know Jake Wharton, the Keynote speaker for Droidcon Berlin this year, he was one of the early contributors to SeriesGuide and I used some of his libraries in the beginning like ActionBarSherlock. Then later the networking and logging libraries he was working on. Obviously I used the Android Open Source libraries once they came along. SeriesGuide would not exist without Open Source software.
Dorian: Why did you choose Open Source as the foundation for your paid app?
Uwe: It started as free and Open Source at the beginning on the Google Play Store, because I was just a computer science student and didn’t have the need to make money. It was also rather complicated to charge money, because you have to set up your own company. Around three years after I posted it to the Play Store, due to people suggesting that I charge money, I started developing extra paid features, such as notifications, theming, and then later the syncing component.
Shows on SeriesGuide
Dorian: Is the core of your project still Open Source and will it stay like this forever?
Uwe: The whole app besides the small server component is public domain. And the spec for the server component is open, so you could build your own if you wanted to.
Uwe: Honestly, I’d have to say the community. Back in the day I had a few people who really pushed me to improve the app, like Jake Wharton, Craig, Chris, and other friends. They really helped me get SeriesGuide off the ground. Without them I would have fixed a bug or two, and then would have moved on. Because of the continuous requests and a growing community, I had to keep going and make it better. And without the community paying for the app, I wouldn’t have the means necessary to continue working on it.
Dorian: What do you dislike about Open Source?
Uwe: Honestly, in the beginning I thought open sourcing would be risky because someone could copy my app, slightly modify it and then publish it, taking credit for my hard work. Because of that I have a separate private repository with new features that I hold off publishing for a few days. But if I remember correctly, this only happened once and was not an issue because the developer didn’t continue development. I am not 100% certain it was a copy, but the code looked very similar to mine. Right now, I don’t think this is an issue anymore. If people use my app they expect my updates because I maintain the app. If somebody copies it, they don’t have my work power and knowledge.
Uwe’s contribution to SeriesGuide on GitHub as of July 6th, 2018.
Dorian: How do you manage your time between developing Open Source projects and your work?
Uwe: I work Mondays and Tuesdays on my main job, kind of as a backup. The rest of the week whenever I have time, I work on SeriesGuide and related Open Source projects. Of course it never ends up being three days. If somebody wants to contribute, I welcome pull requests. I also allow people to translate the app into their language. If somebody has a bug to report, the easiest way to do that is on the website. If people want to contribute code, they can go to the GitHub contribute file which lists everything you need to know.
Dorian: Do you have more features in mind right now?
Uwe: There’s a feedback site where people can request changes, and there’s no shortage of suggestions! I also have ideas in mind, but some things are bigger and I don’t want to do them right away. It’s a constant struggle to get things done. I am not out of ideas; it’s more of a time problem right now.
Dorian: You have a very good time structure, which is encouraging. How hard is it to turn an Open Source project into a profitable business? How did the community react that you have built a business with paid features on top of an Open Source project?
Uwe: The overall reaction was positive. Obviously there are some people that aren’t happy with the presence of paid features. I always tell them that the app has no ads in the free version and you can do pretty much everything except for some convenience features. I would say that for most people this is not an issue because the basic functionality of the app is still freely available. One of the early complaints was that I charge too much money. So in the beginning I was charging 1€ as a one time payment for all access, then increased prices to 3€ per year or a 7€ one time payment. I explained this was to support myself and future updates, basically development time, and most people understood that. I clearly mention that inside the app, paying is not only to get some features but also to support me and future updates. So far most people like the idea and buy into it. Obviously, if you look at the share of paid vs free users it’s nowhere near something like 50/50, it’s way less. But I have a core set of users who believe in the app and support it financially. So far this method has gone well. I am also pushing people towards subscriptions now to secure future development.
SeriesGuide X Pass
Dorian: Do you think the complaints came mostly during the shift from free to some paid features?
Uwe: Yes. In the beginning some people were upset, but as I only made convenience features paid, it wasn’t a huge issue. That is also a takeaway for me: don’t have a free app and then suddenly make half of the features paid, because then users will get upset. I was very careful to only make new or some convenience features paid. Or when I made the previously free theming features paid, I made an effort to spruce them up before. But features like notifications and server syncing were new and weren’t available for free before I implemented them.
Dorian: Do you have any tips for developers that are starting with their Open Source projects or are thinking about open sourcing their code?
Uwe: The best thing you can do for your project is to Open Source it, or in short: put it on GitHub. If you don’t put it online, people won’t find it. Another good way to get traction is to contribute to other projects so people know you exist. And then if you ask for help or feedback about their library you are using in your project, people will get to know your project and maybe look at it. Contributing is a good way to get into the community and be noticed. Give and be given, right?
Dorian: Now we have some fun fact questions. First, what do you think about Microsoft’s acquisition of GitHub?
Uwe: I don’t really care, because Microsoft has done some great things for the Open Source community. Azure runs Linux now and they have their own Linux operating system. It’s still good to know that there is the Open Source alternative GitLab that people can switch to if needed. However, it’s sad that things get monopolized into those big companies. In the end, we are maybe going to end up with only Microsoft, Google and Amazon. GitHub sold out, but we’ll have to see what happens.
Dorian: Do you have a favorite book, film, or game?
Uwe: I’m currently reading the Expanse series, which is also on TV. But my favorite series is the Culture series from Iain M. Banks. That blew my mind. For TV, there’s so many options. I generally like science fiction. I recently watched Killjoys and Altered Carbon which were both really interesting. Star Wars Rogue One is my favorite recent movie. If you want to know what I’m watching, follow me on Trakt.tv, a tracking service similar to SeriesGuide, but web-based, that SeriesGuide also integrates with.
Thank you Uwe Trottmann for the interview, and thank you for reading!
If you enjoyed this open source interview, sign up for our newsletter! We are going to be conducting more interviews like this with Open Source Developers.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.Ok
