Case Study Archives

IoT, Edge Computing, and Digitalization in Healthcare

by Anastasia | Nov 22, 2024 | Case Study, Edge Computing, Insights, IoT | 0 comments

The healthcare industry is experiencing an unprecedented surge in data generation, responsible for approximately 30% of the world’s total data volume. This vast and fast-growing amount of health data is the primary force behind the digital transformation of healthcare. Only through the adoption of advanced technologies can healthcare providers manage, analyze, and secure this information. While COVID-19 accelerated this shift, contributing to the explosion of health data, the ongoing demand for real-time patient insights, personalized treatment, and improved operational efficiency continues to drive the sector toward digitalization and AI. Simultaneously, growing data privacy concerns, increasing costs, and heavier regulatory requirements are challenging the use of cloud computing to manage this data. A megashift to Edge Computing and Edge AI is addressing these challenges, enabling a faster, safer, and more reliable digital healthcare infrastructure.

The digital healthcare market 2024 and beyond, a high-speed revolution

Prior to COVID, growth in digital health adoption stalled. However, digitalization in the healthcare industry has sky-rocketed since the start of the pandemic. Reflecting this market turnaround, followed by the rise of advanced digital tools like AI, recent years have been record-breaking for investments in healthcare companies. A trend that will continue in the next years, as analysts predict rapid growth across digital healthcare market sectors:

Drivers of growth and change in digital healthcare

Digital Healthcare Growth Driver 1: Growing Medical IoT Device Adoption

There will be a projected 40 billion IoT devices by 2030. IoMT devices already accounted for 30% of the entire IoT device market in 2020. Internet of Medical Things (IoMT) are hardware devices designed to process, collect, and/or transmit health–related data via a network. According to Gartner, 79% of healthcare providers are already using IoT in their processes, i.e. remote health monitoring via wearables, ingestible sensors, disinfection robots, or closed-loop insulin delivery systems. IoMT devices increase safety and efficiency in healthcare, and future technical applications, like smart ambulances or augmented reality glasses that assist during surgery, are limitless.

IoMT devices accounted for 30% of the IoT device market

Digital Healthcare Growth Driver 2: The Explosion of Health Data

Growing IoMT adoption is subsequently driving a rapid increase in the amount of collected health data. According to the RBC study, the healthcare industry is now responsible for approximately 30% of the world’s total data volume. By 2025, healthcare data is expected to continue growing at a 36% CAGR, outpacing data volumes from sectors like manufacturing, financial services, and media. Big health data sets are being used to revolutionize healthcare, bringing new insights into fields like oncology, and improving patient experience, care, and diagnosis. According to the Journal of Big Data: “taken together, big data will facilitate healthcare by introducing prediction of epidemics (in relation to population health), providing early warnings of disease conditions, and helping in the discovery of novel biomarkers and intelligent therapeutic intervention strategies for an improved quality of life.” In fact, the healthcare analytics market is projected to reach $129.7 billion by 2028, growing at a 23.5% CAGR. This growth is driven by the need for real-time data processing, personalized medicine, and predictive analytics to manage chronic conditions and optimize hospital operations.

Healthcare data occupies ~30% of the world’s total data volume

Digital Healthcare Growth Driver 3: Artificial Intelligence

The increase in healthcare data opens up new opportunities and challenges to apply advanced technologies like big data analytics and artificial intelligence (AI) to improve healthcare delivery, patient outcomes, and operational efficiency. For instance, AI is being used to analyze medical imaging data, identify patterns in electronic health records, and predict patient outcomes, contributing to improved patient care. By 2026, AI is projected to save the global healthcare industry over $150 billion annually, by answering “20 percent of unmet clinical demand.”

Generative AI, which includes Large Language Models (LLMs) such as GPT-4, is playing a crucial role in this transformation. According to the survey from McKinsey, 70% of surveyed healthcare organizations are either currently testing or actively using generative AI tools for both clinical and administrative applications. This is unsurprising, as LLM Chatbots can reduce waiting times by 80% in healthcare facilities. In diagnostics, LLMs are being applied to interpret electronic health records and assist with predictive analytics, leading to a reduction in hospital readmissions by up to 22%. Additionally, LLMs have helped improve medication adherence rates by 60%, demonstrating their impact on patient care quality.

70% of healthcare organizations plan or use AI

Digital Healthcare Growth Driver 4: Artificial Intelligence

With the rise of IoMT and the boost in healthcare data, Edge Computing is becoming a key driver of healthcare digitalization. The majority of IoMT devices (55.3 %) currently operate on-premise rather than in the cloud, ensuring faster, more secure real-time data processing. This shift to Edge Computing enhances data privacy and reduces latency, which is critical in life-critical medical applications. Additionally, the development of Small Language Models (SLMs) for on-device AI (Edge AI) allows healthcare providers to deploy AI-powered solutions directly on medical devices. This helps with tasks like remote monitoring and diagnostics without the need for cloud connectivity, which is particularly beneficial in environments with limited internet access.

As IoMT continues to evolve, Edge Computing will play an essential role in supporting healthcare’s increasing demand for real-time data processing. By 2025, it is projected that 75% of the healthcare data will be generated at the Edge, further driving the adoption of these technologies across the industry.

75% of the healthcare data will be generated at the Edge in 2025

Digital Healthcare Growth Driver 5: Underlying Social Megatrends

The global population is growing; global life expectancy is rising. Accordingly, by 2030 the world needs more energy, more food, and more water. Explosive population growth in some areas versus declines in others contributes to shifts in economic power, resource allocation, societal habits, and norms. Many Western populations are aging rapidly. E.g. in America, the number of people 65+ is expected to nearly double to 72.1 million by 2034. Because the population is shrinking at the same time, elder care is a growing challenge and researchers are looking to robots to solve it.

Health megatrends focus not only on the prevention of disease, but also on the perception of wellness, and new forms of living and working. Over this decade more resources will be spent on health and longevity, leading to artificially and technologically enhanced human capabilities. More lifestyle-related disorders and diseases are expected to emerge in the future.

A focus on health and longevity will
lead to artificial & tech-enhanced
human capabilities

The Challenges of Healthtech

Along with more data, more devices, and more opportunities also comes more responsibility and more costs for healthcare providers.

Data Volume and Availability With the growing number of digital healthcare and medical devices, a dazzling volume of health data is created and collected across many different channels. It will be vital for the healthcare industry to reliably synchronize and combine data across devices and channels. Due to the sheer volume, reliable collection and analysis of this data is a major challenge. After it’s been processed, data needs to be available on demand, i.e. in emergency situations that require reliable, fast, available data.

Reliability, Privacy, and Data Security are extremely important in health technology; 70% of healthcare consumers are concerned about data privacy. Data use is often governed by increasingly strict national regulations, i.e. HIPAA (USA) and/or GDPR (Europe). With the number of cyber-attacks in the healthcare industry on the rise, healthcare professionals must be even more diligent about the storage and processing of data. In addition, healthtech must be extremely well vetted; failures can cost lives – typical “banana products”, which ripen with the customers, are a no-go.

IT Costs Medical devices contribute a large portion to healthcare budgets. However as data volumes grow, data costs will also become a relevant cost point. Sending all health data to the cloud to be stored and processed is not only slow and insecure, it is also extremely costly. To curb mobile network and cloud costs, much health data can be stored and processed at the edge, on local devices, with only necessary data being synced to a cloud or central server. By building resilient data architecture now, healthcare providers (e.g. hospitals, clinics, research centers) can avoid future costs and headaches.

Edge Computing is Integral to Data-driven Healthcare Ecosystems

With big data volumes, industries like healthcare need to seek out resilient information architectures to accommodate growing numbers of data and devices. To build resilient and secure digital infrastructure, healthcare providers will need to utilize both cloud computing and edge computing models, exploiting the strengths of both systems.

Cloud & Edge: What’s the Difference?

Cloud Computing information is sent to a centralized data center, to be stored, processed and sent back to the edge. This causes latency and a higher risk of data breaches. Centralized data is useful for large-scale data analysis and the distribution of data between i.e. hospitals and doctors’ offices.

Edge Computing Data is stored and processed on or near the device it was created on. Edge Computing works without an internet connection, and thus is reliable and robust in any scenario. It is ideal for time-sensitive data (real-time), and improved data privacy and security.

Edge Computing contributes to resilient and secure healthcare data systems

Transforming Healthcare with Edge Computing

Use Case: Secure and Up to Date Digital Record Keeping in Doctors Offices

For private doctors’ offices, embracing digitalization comes with different hurdles than larger healthcare providers. Often, offices do not keep a dedicated IT professional on staff, and must find digital solutions that serve their needs, while allowing them to comply with ever-increasing data regulations. As an industry used to legislative challenges, GPs know that sensitive patient data must be handled with care.

Solution providers serving private doctors’ offices are using edge databases to help keep patient data secure. An edge database allows private GPs to collect and store digital data locally. In newer practice setups, doctors use tablets, like iPads, throughout their practice to collect and track patient data, take notes and improve flexibility. This patient data should not be sent or stored in a central cloud server as this increases the risk of data breaches and opens up regulatory challenges. In a cloud-centered setup, the doctor also always needs to rely on a constant internet connection being available, making this also a matter of data availability

Accordingly, the patient data is stored locally, on the iPads, accessible only by the doctor treating the patient. Some of the data is synchronized to a local, in-office computer at the front desk for billing and administration. Other data is only synchronized for backup purposes and encrypted. Such a setup also allows synchronizing data between iPads, enabling doctors to share data in an instant.

Use Case: Connected Ambulances – Real-Time Edge Data from Home to Hospital

Between an incidence location and the hospital, a lot can happen. What if everything that happened in the ambulance was reliably and securely tracked and shared with the hospital, seamlessly? There are already trials using 5G technology to stream real-time data to hospitals, allowing ambulance medics to access patient data while in transit. Looking to the future, Edge Computing will enable digital healthcare applications to function in real-time and reliably anywhere and anytime, e.g. a moving ambulance, in the tunnel, or a remote area, enabling ambulance teams and doctors to give the best treatment instantly / on-site, while using available bandwidth and networks when available to seamlessly synchronize the relevant information to the relevant healthcare units, e.g. the next hospital. This will decrease friction, enhance operational processes, and improve time to treatment.

Digital Healthcare: Key Take-Aways

Digital healthcare is a fast-growing industry; more data and devices alongside new tech are empowering rapid advances. Finding ways to utilize growing healthcare data, while ensuring data privacy, security and availability are key challenges ahead for healthcare providers. The healthcare industry must find the right mix of technologies to manage this data, utilizing cloud for global data exchange and big data analytics, while embracing Edge Computing for it’s speed, security, and resilience.

Underutilized data plays a major role in health-tech innovation, data is the lifeline of future healthcare offerings; however, there is still much work to be done to improve the collection, management, and analysis of this data.

It’s all about data availability. Either in emergency situations, or simply to provide a smooth patient experience, data needs to be fast, reliable, and available: when you need it where you need it.

Edge computing alongside other developing technologies like 5G or Artificial Intelligence will empower a new and powerful digital healthcare ecosystem.

ObjectBox provides edge data software, to empower scalable and resilient digital innovation on the edge in healthcare, automotive, and manufacturing. ObjectBox’ edge database and data synchronization solution is 10x faster than any alternative, and empowers applications
that respond in real-time (low-latency), work offline without a connection to the cloud, reduce energy needs, keep data secure, and lower mobile network and cloud costs.

Get in touch to learn more about ObjectBox' Edge Technology

Sources

How EV Charging Benefits from Edge Computing

by Alyssa | Jan 28, 2020 | Case Study, Edge Computing, Insights, IoT

Edge computing allows data to be stored and used on local devices. Integrating Edge Computing directly within electric vehicle charging infrastructure improves station usability and also allows for real-time energy management.

Car charging and electric vehicles

The era of electric vehicles (EV) is coming: Already one in every 250¹ cars on the road is electric. While it is uncertain when electric vehicles will overtake traditional combustion engine vehicles, electric is clearly the future. Car charging infrastructure is critical for electric vehicle expansion – and one of the largest bottlenecks to EV adoption. Range anxiety is still one of the primary concerns for potential EV customers,² and charging station proliferation is still far behind traditional gas stations.

State of the electric vehicle charging Market

The electric vehicle charging infrastructure market is still very divided, with many players vying for this large-growth sector – some predictions forecast over 40% CAGR for the car charging infrastructure market in the coming years.³ Car manufacturers, gas & oil, OEMs, and utilities companies (e.g. Tesla, VW, BMW, Shell, GE, Engie, Siemens, ABB) are actively taking part in the development of the market, recognizing the need to support future EV customers and the huge growth potential. Startups in the space like EcoG, Wirelane, flexEcharge and Elli offer solutions that focus on accessibility, efficiency and improving end user experiences.

Why Car Charging Stations need Offline Capability (Edge Computing)

First, let’s look at the challenges a vehicle charging provider needs to solve from a basic data perspective: Customers interfacing with charging stations require an account linked with basic information and payment methods. In order to charge a car, the user needs to be verified by the charging station, and is often required to have a pre-booked charging slot. Typically, a user would create a new account via a website or mobile phone beforehand, but not on the spot at the car charging station. Also booking slots are handled via a mobile app or website. However, the car charging station needs this information to allow a car to be charged.

This is only the most basic necessity. In the future, charging stations will provide more services to users, e.g. identifying users preference like cost over speed of charging, or choosing to charge with green energy.

Depending on where the car charging station sits, it can be offline more or less often, e.g. in France there are quite many electric car charging stations in the country site, where the connection is typically flaky – and might not be available for days. On the other hand, there are stations that reside within a parking house or hotel and use a fixed land line for connectivity. In the latter case, your uptime can be very consistent, but typically you cannot guarantee the car charging station will be connected.

If the charging station tries to access this data only when it needs it, because a car is trying to charge, it may or may not have an internet connection at the time and thus the likelihood of failure is rather high. Accordingly, any new information should be pushed to the car charging stations when a connection is available and stored on the station. The hardware of a car charging station is capable enough to hold a lightweight database and persist data as is needed and useful.

Choosing a data persistence layer (database) over a simple caching ensures not only that no data is lost, but can also allow more processing to happen on the station and allows for autonomous reactions. In combination with edge synchronization, which enables persistence layers to synchronize between car charging stations (that share a data space), fast data persistence allows for efficient load balancing as well as easily updating the configurations of all car charging stations.

Smart Energy Load Management – the need for fast response on the Edge

Managing energy is one of the greatest challenges for EV infrastructure providers. The difficulty here is less about overall energy consumption increasing – rather managing, predicting and preparing for high-demand peaks. Imagine everyone needs charging during a large public event, or at charging stations during holiday travel times – peak demands like these need to be anticipated and planned for. The future with electric cars needs to balance demand with a combination of smart chargers, efficient energy grid management, Vehicle-to-Grid (V2G) solutions, and perhaps even on-site batteries at larger charging stations to improve time-to-charge and optimize for electricity prices.

Edge computing will play an important role in providing real-time, accurate energy load control, necessary for maintaining grid stability, particularly in emergency situations.⁴ At charging stations where many EVs plug in, smart edge nodes can balance charge schedules in real-time, optimizing based on EV owner requirements without overloading local transformers.⁵ On a larger scale, smart energy meters can use real-time edge computing to shift energy quickly to high-demand locations, cutting energy from low-priority appliances, limiting charge speeds, or pulling excess energy from V2G networks.

Thinking about energy management, the conversation fluidly moves from EV charging infrastructure to thinking about smart mobility, utilities, and smart city infrastructure on a larger scale. Car charging systems will be complex, interconnected and will progress in alignment with other ongoing digitization efforts to create data drive infrastructure across cities and the world. Edge computing, and base technologies like ObjectBox that enable working on the edge, are important enablers to ensure that real-time computing can happen anywhere and digitization is affordable, scalable, and sustainable.

Start Building with ObjectBox

—-

¹ https://qz.com/1620614/electric-car-forecasts-are-all-over-the-map/
² https://airqualitynews.com/2019/08/27/range-anxiety-still-biggest-ev-turn-off-survey-finds/
³ https://www.mordorintelligence.com/industry-reports/electric-vehicles-charging-stations-market
⁴ https://www.geirina.net/paper/IoT%20and%20Edge%20Computing%20Based%20Direct%20Load%20Control%20for%20Fast%20Adaptive%20Frequency%20Regulation.pdf
⁵ https://projects.iq.harvard.edu/files/energyconsortium/files/rwp18-026_lee_1.pdf

MoodSpace Mobile App Use Case

by Alyssa | Jan 20, 2020 | Android, Case Study, Insights, ObjectBox

Ian Alexander

Co-founder, MoodSpace

We speak with Ian Alexander, founder and lead developer at MoodSpace, a beautiful app making mental health exercises accessible to everyone. MoodSpace was released in 2019, and has over 150k+ downloads. The COVID-crises highlights the importance of digital support for wellbeing and saw MoodSpace surge. After trying several databases, Ian settled on ObjectBox because of its high performance and ease of use.

Alyssa: Hi Ian, thank you so much for joining me and for using ObjectBox. Let’s start with the basics about MoodSpace and your role there.

Ian: Hi, Alyssa, thanks for having me. I’m the software developer, founder, and runner of the company – a jack of all trades. MoodSpace is an app that teaches concepts from mental health. There is a massive problem with accessibility to mental health. In the UK, for example, you have something like 1 in 4 people that have some sort of mental health problem, but only 1 in 113 go through therapy and complete it. So our essential goal is to take concepts from therapy and bring them closer to people, teaching them techniques that they can do on an ongoing basis. There’s no end date like in therapy, no waiting list, and it’s a lot easier to use it in places where you wouldn’t necessarily have access to a therapist. In the western world it is much easier to access therapy, still difficult in some ways, but much of the world doesn’t have that benefit. So that’s the goal we’re trying to reach. We started last year, we released the MoodSpace MVP in September, and now we’re going through the next stage of trying to raise our next round of funding – it’s quite exciting.

A: That’s great, congratulations! Can you tell me a bit more about your team?

I: We’re based in the UK, and in terms of the technical side, it’s just me. We also have various other roles: designer, copywriter, and another co-founder who handles much of the business side. But in terms of technical, it is just me for now. Hopefully after we get funding, we’ll be able to expand the technical team..

A: What’s your background, what did you do before MoodSpace?

I: Actually, I was originally a chemical engineer – I worked in oil & gas for a couple of years, but then I taught myself to develop and for the last 5-6 years, I’ve worked across a lot of startups, for example the dating app Once, when they were just starting up, also ITV, and then started on MoodSpace last year. Moodspace has actually existed for quite some time, it started as a hobby project of mine about 5 years ago.

A: There are other mental health apps out there, what makes MoodSpace special?

I: If you look at apps in the space, they’re generally fairly small and limited – they’ll have maybe 4 or 5 exercises. Versus the realm of therapy, which has literally thousands of exercises. Any app that exists at the moment takes just a fraction of a percent of therapy and tries to teach it. Our USP is that we are a very technically minded team, and with new technologies which have come out along with our internal processes, we can make a much bigger app, building something far bigger than what currently exists, much cheaper and far faster. Our USP is strangely, less about the app, and more about our process and the technology that we use to make the app. The tech we will be using is Kotlin Multiplatform, which is a cross platform framework which lets us maintain a single codebase which enables us to build fully native apps with full access to native APIs.

A: It sounds like the app is quite comprehensive – who is your target audience?

I: At the moment, we haven’t hit the product-market-fit stage. We’re still figuring out who the typical user is. We find that the unique art style of our app has helped our growth so far, we often find a lot of people sharing screenshots of the app on social media. So we seem to have hit a niche, but we’re still figuring out what that niche is!

A: Do you have any direct interaction with your users?

I: Mid-last year, I put a survey in the app, so after using it for a certain time users get the survey. There are some questions like who you are, why you are using it, and they gave us way more knowledge about who is using it and what they use it for, which was very helpful. Apart from that though, it is very difficult to know.

A: Yes, it can be very challenging, we’re familiar with that struggle at ObjectBox as well. Switching gears a bit – I’d love to hear a bit more about how and why you ObjectBox.

I: As I mentioned, MoodSpace is about 5 years old, so it’s gone through several databases. One of them was really time consuming to make – it wasn’t ORM based, so you had to write a lot of stuff yourself. Then the next was an ORM called Sugar, but it stopped being developed – it was a side project by someone, so maybe I shouldn’t have used it in the first place (laughs).

I: So then we switched to ObjectBox, and actually the reason we switched was essentially to skip asynchronous code – I’ve always been a frontend developer and what I’ve come across is that asynchronous code makes things very complex, and it means app development takes much longer. Because we had a lot of time constraints and we wanted to develop as much as quickly as possible, I actually wanted to completely skip asynchronous code – which I wouldn’t recommend – but essentially ObjectBox let us do that because it’s very fast. You’d have to have a ton of data in the app, before it would visibly slow it down – and I did a lot of testing around that and it would have needed several years of data before noticeably slowing down the app. So, that was our original reason, perhaps a bit of a strange reason. And we’ve since changed the app so it’s asynchronous, so it won’t slow down any longer, no matter how much data you add in the app. Overall, I like ObjectBox a lot – it’s just simple, very easy to use.

A: What features in your app use the database?

I: Actually everything is in the app, as we don’t have a backend. So we need it to store all the data in the app.

A: Okay, sure. Keeping everything in the app is also practical from a data privacy standpoint. How did you actually find ObjectBox?

I: It was someone I used to work with at Once – they used greenDAO and mentioned that ObjectBox (by the same people) was coming out. I looked into it a little bit and wanted to use it for a while, but it wasn’t I started developing MoodSpace again that I had a chance to.

ObjectBox is very fast, it would have needed several years of data before noticeably slowing down the app. Overall, I like ObjectBox a lot – it’s just simple, very easy to use.

A: Are there any other developer tools that you’re excited about and would want to share with the community?

I: Yes, Kotlin Multiplatform. Having been an Android developer, having used Kotlin for quite some time and having tried cross-platform tools before, I think Kotlin Multiplatform will change the way you make cross platform apps, because it lets you share so much of the code base without sacrificing the native experience. It has the potential of leading to massive cost savings in app development. Maybe in the next year or two I can see it having a huge impact on frontend development across mobile, web, and desktop.

A: What are your big picture goals for MoodSpace? Upcoming milestones? Does ObjectBox help with those at all?

I: Actually, it potentially will, with regards to ObjectBox Sync, which is part of my plan for that app. The app right now is only available on Android, and providing we get our next round of funding, we are going to be adding iOS – where we’ll need some sort of backend. We want to avoid, again, spending much money, and one of ObjectBox Sync, Realm Cloud or Firestore can help us do that – obviously as ObjectBox Sync is nearly ready, we’d want to use that. The main point around that is cost saving because it solves a lot of problems that otherwise we would have to solve ourselves – things like offline access and syncing with an API, that would otherwise be very time intensive.

A: Ian, thank you for your time and sharing more about MoodSpace and working with ObjectBox. We wish you the best of luck with your fundraising round!

Start Building with ObjectBox

Sync.Drone: a drone in-flight synchronization project

by Alyssa | Nov 20, 2019 | Case Study, Insights, IoT, Open Source

This spring, a student group from Augsburg University of Applied Sciences build 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.

import objectbox

from models.objectbox_models import Led

# initialize an empty DB before the first server start the server

model = objectbox.Model()

model.entity(Led, last_property_id=objectbox.model.IdUid(4, 3004))

model.last_entity_id = objectbox.model.IdUid(3, 3)

model = objectbox.Builder().model(model).directory("led-server-db").build()

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).

from models.objectbox_models import Led as LedModel

class Led:

def __init__(self, database, tag_id):

self.red = 0

self.green = 0

self.blue = 0

self.tag_id = tag_id

self.db_id = database.led.put(LedModel())

self.led_object = database.led.get(self.db_id)

def saveColorToDatabase(self, database):

self.led_object.setColor(self.red, self.green, self.blue)

database.led.put(self.led_object)

self.led_object.printColor()

Click here for the complete code it’s open source!

Thank you!

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.

Sync Your Project Today!

Car Tolling – A case for Edge Computing

by Vivien | Sep 11, 2019 | Case Study, Insights, IoT

Governments often face tight budgets on infrastructure development; car tolling is increasingly seen as the answer for raising funds¹, making it more and more prevalent. From 2008 to 2018 the total length of tolled roads in Europe increased by 23%² and tolling revenue in Europe increased by 37%³ to €31.3 bn. per year; similarly, from 2010 to 2015 the United States experienced a 63% increase in transponders and 52% more tolling revenue, resulting in $13.8 bn. in 2015⁴. On top, despite car sharing efforts, car ownership and traffic is still increasing in many countries, e.g. Germany⁵ ⁶, France⁷ and India⁸. Increasing amounts of traffic, devices, and data points bring current tolling solutions to their limits. Taking data to the edge in new and existing tolling solutions by adding a data persistence layer and synchronizing parts of the data can make tolling more efficient and reliable.

Setting the stage: a typical car tolling situation

A national infrastructure company has deployed several hundred car tolling stations all over the country. These stations automatically recognize passing cars by detecting licence plates, using visual recognition or wirelessly, e.g. by receiving data from an RFID transponder in the car. In order to ensure that only eligible cars are passing through the tolling station and violators are fined, it is necessary for the tolling station software to look up the gathered vehicle information – among millions of entries – as fast as possible. If the data look-up is not fast enough, or the data on the roadsides/tolling stations isn’t up to date and in sync with the central data, the tolling station loses money.

“The importance of mobile apps is increasing for Kapsch TrafficCom so that we see ObjectBox’ edge computing database solution as an interesting future base technology for all types of mobility apps.”

Peter Ummenhofer

Executive VP Solution Management, Kapsch TrafficCom

Why edge computing and fast lookups are key to today’s car tolling systems

In general, modern nationwide tolling infrastructure consists of three systems: tolling stations operated by the respective agencies, central open road, also called mobile tolling⁹, and central transaction clearing houses. Within this infrastructure, all data related to violators and other operational information needs to be synchronized between these three systems in a consistent way, with as little delay as possible. If this is not the case, together with other problems, car tolling system operators are faced with high monetary losses every day.

Challenges of today’s car tolling systems

Today’s car tolling systems are based on the fundamental idea that cars do not need to stop to be checked or charged. Thus, as the cars move quickly through the scanning area, the main challenge relates to the amount of data that needs to be searched within a very short time frame. To be successful, the license plate needs to be read and looked up in a database in near real-time.

Near-realtime requirements

From a development perspective, this challenge is rooted in:

accessing data from a remote location (speed of communication, speed of network)
keeping data in synchronization with car tolling stations that are closer to the drivers and/or roadside units
database speed on remote servers
database speed on roadside units (car tolling edge devices)
limitations of existing hardware as some systems are quite old, and rolling out new hardware is expensive

Strict uptime quarantees

Furthermore, it is possible that stations shut down from time to time, due to the weather, power outages, vandalism or simply technical failures. However, tolling providers generally need to provide strict uptime guarantees and thus service level agreements often include penalty fees in case of excessive downtime. Such events cost the providers substantial amounts of money – and data loss, i.e. undetected violators, even more so.

Privacy and legal regulations

Adding to this, privacy and legal requirements differ from country to country and increase the complexity of the systems and timings. For example, in Austria the pictures and derived license plate information may only be used for checking, but in case no violation was detected, they need to be removed in an unrecoverable manner.¹⁰ On the other hand, the data of potential violators may be stored for the sole purpose of toll collection or prosecution, but only for a maximum of three years.

Edge Computing

Edge computing (local data storage and data sync) can help solve these challenges. Deploying local persistence on every type of tolling station, i.e. open and static stations, as well as on the central server allows to meet the near-realtime requirements, heighten uptimes (offline, flaky networks), and last not least meet privacy regulations. From a technical point of view, a solution that supports all platforms and operating systems, is the most efficient approach to ensure edge persistence and data harmony across devices.

Edge database and Sync are the center piece for efficient car tolling solutions

There are a couple of edge databases out there, but out-of-the-box data synchronization solutions are very rare. A fast edge database that reliably persists the needed data and supports fast lookups is essential. Data synchronization guarantees that the vehicle data in the internal stations’ memory is always up-to-date with the central server, so the station will make a decision based on the most accurate data every time. Additionally, the other systems involved in the tolling infrastructure consistently receive the most recent information with no further effort required.

Deploying such an edge persistence and data sync solution mitigates the losses of station shutdowns and Internet connection issues are not a problem anymore. The stations’ operating company also no longer looses violator’s information due to technical reasons.

Summary – Car tolling is moving to the edge

As this case study shows, the use of edge computing is a perfect fit for modern infrastructure. In the context of car tolling, speed, reliable data storage and synchronization are indispensable, resulting in ObjectBox being an effective solution for today’s and future technological advancements.

If you are interested in learning more, feel free to get in touch with us! We appreciate any kind of feedback.

Discover more IoT Use Cases

billiger.de Mobile App Case Study

by Vivien | Aug 14, 2019 | Android, Case Study, Insights, Mobile Database

Arne Jans

Software Developer, solute

Vivien: Hi Arne, great to talk with you today. Let’s get started by learning more about you and billiger.de.

Arne: Hi Vivien. I’ve been doing software development for more than 10 years, and API design for the last 5 years. I am currently responsible for mobile development for billiger.de, the most widely used and award-winning price comparison portal in Germany. We’re especially proud of our data security, which was just recently awarded too.

The company behind billiger.de is solute GmbH, which is based in Karlsruhe. They also have a few other brands: shopping.de, an online shopping platform for men and women, and friends communication, an online marketing agency. At billiger.de we’re about 150 employees.

Some of our stats:

300,000+

active daily users on billiger.de

500,000+

app downloads

70 Million

prices in the database

22,500 Shops

comparing 1M products

So clearly, the database and its performance on the server side is very important. Companies update their prices all the time, and on top there are all kinds of vouchers that can be applied. All of these are changing frequently – and you never know who updates their prices when. So, you can see the challenges – from a technical standpoint but also for consumers. It is hard to get the best price.

V: Tell me more about the billiger.de app – why did you decide to go for a native app?

A: Well, to be honest there was an existing native app when I came into the company. But aside from that, it’s essential for UX. We also need some offline capability for features like the notepad function or when users are in the store without an Internet connection and scan barcodes. Once they are online again, the query goes to the cloud – and the user gets his result.

V: So are most of your users on the app? Or rather web?

A: We definitely still have more web users, but user numbers are shifting to mobile more and more. Also, our web users are often one time users only. Our loyalty rate is much higher with app users, so we are trying to increase app installs. We’re seeing that – even on the web – the majority of users are coming from mobile devices. Therefore, we relaunched the website a couple of years ago to be responsive and mobile optimized. So we are focusing more and more on mobile, on both the website and through the app.

V: Why did you need to implement a local database? How is it implemented in your solution?

A: We need data persistence mainly for certain features. We’re still using SQLite, but it’s too much boilerplate code and too little fun. We have been using an ORM on top of SQLite until recently, but it didn’t work well in combination with Proguard on some Android versions anymore. So it resulted in lost data. We’re currently using ObjectBox in the billiger.de Pro version and in a fun new project called PricePretzel, which gives users the best price actively and tracks savings. In these projects, ObjectBox has proven its worth, so we want to migrate the billiger.de app too.

V: Yes, SQLite with an ORM can get very messy. So, why did you choose ObjectBox as the alternative?

A: I looked at several SQLite alternatives and ObjectBox looked interesting. The main decision factors were: ease of integration, stability, and performance. But ease of use and integration were really the most important factors. Stability and enough performance were rather basic necessities. We found ObjectBox really easy to use – we did the migration and everything and because ObjectBox handles that automatically, it was really simple.

We found ObjectBox really easy to use – we did the migration and everything and because ObjectBox handles that automatically, it was really simple.

ObjectBox database mobile app case study

V: So did performance matter to you at all?

A: For our needs, performance was secondary. Obviously the performance needs to be good enough, but we do not have super high requirements regarding performance.

V: Do you do any sort of synchronization?

A: Synchronization obviously is a super interesting feature and we are keeping an eye on it once it is publicly released. From the setup we have, we would need to do it with a connector to our existing database. Currently the web data and app data are separated and we are working on integrating them. So, this needs synchronization.

V: Which other tools do you use in your solution/are you excited about?

A: Retrofit from Square, a networking library, we recommend it to everyone and it works super well with ObjectBox. Both libraries work well together with our business objects. Retrofit fetches the fresh data from our servers and deserializes it into our business objects, which are then persisted with ObjectBox without any additional boilerplate code.

V: billiger.de has over 500.000 downloads and about 4 stars on average – how many daily users does the billiger.de app have? Do you have peak times?

A: Obviously holidays like Christmas and Easter are busier. During the day, early evenings get the most traffic – about 1000-2000 daily active users in the billiger.de app, 200 in our Pro-app, and iOS is similar. As I shared before, we get about 300k daily users on the website.

V: Thanks for sharing, and for talking with me today. Any last words?

A: Thank you for having me! I am looking forward to do more with ObjectBox and am very excited about what comes next!

Discover more IoT Use Cases

« Older Entries