Hackathons are a popular kind of stimulating entertainment here at Developex. Few days ago we organized a R&D Hackathon where several teams researched interesting topics and put them into practice. This event was planned in a short time and took only 4 hours.
During this hackathon the main task was to explore a certain topic from a practical angle. A team should choose a topic, find the problems that blocks implementation and suggest ways to solve them. With extra time, we made basic prototypes to illustrate ‘how it should work’.
In this series, we’ll introduce you to the most interesting research made during the hackathon.
Indoor navigation
Indoor navigation is a direction that is interesting for a wide range of technologies, from cybersecurity to SCADA systems. The main challenge is how to organize precisely moving or tracking some object inside a building where is no GPS signal.
There are a lot of solutions possible, both cheap and expensive. We wanted to explore the possibility of a more or less precise indoor navigation system without high capital and maintenance costs. The low cost should be achieved by using public (defined as existing almost everywhere in a city) sources of signals: WiFi routers and motion sensors (accelerometer, gyroscope and magnetometer).
It is known that both of these sources are very imprecise. Three WiFi routers may generate about 5 meters of deviation, even in an open room without walls. In a real building it depends on the quality of the wifi-signal, numbers of walls and building materials.
The precision of the motion sensors in a phone is even worse. After one or two minutes of usage they may start to show completely inappropriate values, a phenomenon known as drift.
First approximation
We hoped that the data from WiFi and motion sensors would correct each other. The intention was: If we take the reading from both devices quite often (each 0.5 or 1 second), we could generate a close approximation. Unfortunately this idea was wrong. The resulting 2D-coordinates were too far from the correct values.
We’ve analyzed the failure and understood what was done incorrectly.
- We did not pre-research which mobile phones had the best motion sensors. We got first one (OK, it was top of the line, but…) that was available at that moment.
- We did not pre-research which approach was the best to find (x, y) point based signals broadcasted by WiFi routers. We’d applied a trilateration algorithm. But after the hackathon, we agreed maybe machine learning would be a better approach.
- We did not pre-research the properties of our local WiFi routers; different models have different signal strengths.
Second approximation
During the preparation for the hackathon the idea appeared to make a special motion device with precise sensors. This device must generate much more precise data than low-end sensors in a phone. At first, we were afraid this device would be expensive. And we could start to research some another idea but not ‘cheap indoor navigation‘.
Fortunately we found a really low-cost configuration of spare parts. The device contained an accelerometer, gyroscope and magnetometer and bluetooth-module. It costs less than a T-shirt wholesale. And it should give very good precision during long period and do it, yes, in 3D. It is written “should” because during the hackathon we learned how to calibrate and to treat data from the accelerometer of this device. Therefore, we implemented tracking of rotation with the device in 3D but not moving it in a certain direction.
Summary for Indoor Navigation
In conclusion, we understood four important things:
- A common mobile phone is likely an inappropriate source for continuous motion detection.
- It is possible to build a cheap device with good calibrated sensors that allow us to track moving quite precise.
- WiFi points are a good source of free signals for indoor navigation. But only if a special approach is applied for its interpretation (like machine learning)
- It is possible to make low-cost indoor navigation in 2D and 3D.
More questions than answers are found, but that is the goal of an R&D hackathon. It should create questions, first of all. The team who tried to implement low-cost indoor navigation checked the most obvious cases and tried to integrate non-standard solutions. And some of them are retained as a base for the second iteration: implementation of a workable prototype. When we do it, you’ll be the first to know. Stay tuned.
