Decision of using LiteDB on a Raspberry Pi with ARM CPU in our IoT project.
Autonomous cleaning robot meets LiteDB
Today I would like to tell you about our current IoT project and show you how LiteDB helps us to guarantee the data persistence and availability.
IoT applications distributed over the globe with high availability and reliability requirements, such as for example required by industrial robots, represent a particular challenge in terms of local data management. Further considerations need to be taken into account, in particular, when such robots need not only to provide information to an end customer app but also operate and know the status of operation, even in the event of temporary unavailability of the cloud.
In our case for the build-in hardware for the application of an autonomous industrial cleaning robot we used a Raspberry Pi with Linux, on which our control application is running.
On the cloud software infrastructure side, we already used the ASP.NET Core 3.1 framework from Microsoft. Since this is cross-platform capable, we decided to use it on the robots as well. We can easily compile the code for the Raspberry Pi and develop it not only on Windows but also on macOs and Linux.
Furthermore, in order to satisfy the data persistence requirements, we decided to use the LiteDB project: an embedded NoSQL database that fits our needs.
- It runs embedded, so we do not need to install and maintain a database application on the Raspberry Pi.
- It runs on the ARM architecture with the ASP.NET Core 3.1 framework.
- NoSQL to store the unstructured data.
However, during the evaluation of the technology solution, it is also important to assess the risks of the project:
- First time use, building up expertise.
- Coding dependency.
- Database grooming in operations.
We have weighed up the risks and taken countermeasures. The development of expertise was carried out in our team and the training materials were stored in our wiki for knowledge sharing and re-use. This makes it easier for new team members to familiarize themselves with the system and quickly contribute to the project.
Concerning the coding dependency, we decided to use the repository pattern. Thus, the database system is abstracted in the application. The services access the repository via simple CRUD (Create, Read, Update, Delete) operations over an interface. For the concrete implementation of the database we worked with generics, so we only need one concrete implementation. Another advantage of the repository pattern is that it is easy to write unit tests 😊. A nice and easy unit test can be seen in this reference application from Microsoft.
Since storage is a scarce resource on the Raspberry Pi, we use the database for caching and send the data to our cloud API running on Microsoft Azure. There we have unlimited storage space and a backup. Correctly transferred data can then be deleted from the database. This is done with a hosted service that runs in the background.
To illustrate this a little more graphically, I have laid out the mentioned abstraction layers:
By solving these risks, we were able to implement the project successfully. I hope you like this blog entry and you can adapt the topic for your own purposes. There will be more entries about our IoT project from me. We are happy to advise you on the above-mentioned technologies.
About the Author
Charles Chojnowski is Co-Founder and Software Engineer at Earlybyte.
Earlybyte is an IT consultancy firm specialized in developing new digital solutions for companies around the world from digitalization to IoT solutions, close to the client and its business embracing agility.