IELS: Indoor Equipment Localization System: Conclusion (Part 6/6 final) (IoT)

Conclusion

We conclude there is a gap between a few of the mentioned research papers  and the commercial products. Most  researches are missing the practical usage of iBeacons and focus primarily on specific problems. However, all commercial solutions does not offer  free-of-cost solutions. We think there is a place for Open Source standard software for indoor localizing System. We therefore aim to focus on practical usage of iBeacons based on Indoor Localization System and in short term share our  knowledge from  this thesis with  potential contributors. We would like to continue working on this project and improve it.  All this we aim  to release it at some point as an Open Source Indoor Localization System standard software and make it possible to use  the  system as crowdsensing. That means people who  has  smartphones with the proper application and thereby be able to collect the location of the smartphone and as well as trackable objects location information periodically. This  should be send to a centralized backend infrastructure based on  end-user behavior and requirement.

The work from Bulten [1], Radboud University in Holland has been a major inspiration for our  thesis. Bulten focuses on practical usage of the iBeacons and has already released source code based on JavaScript.

We think the combination of iBeacons’ price together with long  life battery and easy-to-deploy makes it a perfect choice to use for indoor localization purpose.

Another aspect for future research would be the improvement of the algorithm’s efficiency, and overall improvement of the system as mentioned in discussion.

Finally, it should be concluded that the  environment surrounding iBeacons and smartphone hardware type and model have  a major impact in the final quality of the results regardless the technique.

Extra stuff

IT University of CopenhagenExperitment in 5th floor in ITU IELS longterm concept   360 panorama from PitLabIELS infographic

Bibliography

[1]  Wouter Bulten.   Human slam simultaneous  localisation and configuration (slac) of indoor wireless sensor networks and their user, 2015.

[2]  Song  Chai,  Renbo An, and Zhengzhong Du.   An indoor positioning algorithm using bluetooth low energy RSSI.

[3]  Yu-Chung Cheng, Yatin Chawathe, Anthony LaMarca, and John  Krumm. Accu- racy characterization for metropolitan-scale wi-fi localization.

[4]  Ramsey Faragher and Robert Harle.  An analysis  of the accuracy of bluetooth low energy for indoor positioning applications. In Proceedings of the 27th Inter- national Technical Meeting of the Satellite Division of the Institute of Navigation (ION GNSS+ 2014), Tampa Florida, September 2014, pp. 2011-210., 2014.

[5]  Atul Gosai and Rushi Raval. Real time location based tracking using wifi signals.

[6]  Xiaofan Jiang, Chieh-Jan Mike Liang, Kaifei Chen, Ben Zhang, Jeff Hsu,  Jie Liu, Bin Cao,  and Feng  Zhao. Design and evaluation of a wireless magnetic-based proximity detection platform for indoor applications.

[7]  Philippe Bonne Jonathan Fürst, Kaifei Chen. Evaluating and improving blue- tooth low energy performance in the wild.

[8]  John  Krumm. Ubiquitous Computing Fundamentals. CRC Press, 2010.

[9]  Anthony LaMarca and Eyal de Lara.  Location systems: An introduction to the technology behind location awareness.  Synthesis Lectures  on Mobile and  Per- vasive  Computing, 3(1):1–122,  2008.

[10]  Jea-Gu   Lee,    Byung-Kwan  Kim,    Sung-Bong  Jang,    Seung-Ho  Yeon,   and Young Woong Ko. Accuracy enhancement of rssi-based distance estimation by applying gaussian filter. Indian Journal of Science and  Technology, 9(20), 2016.

[11]  Zhouchi Li, Yang Yang, and Kaveh  Pahlavan.  Using iBeacon for newborns lo- calization in hospitals. In 2016 10th  International Symposium on Medical In- formation and  Communication Technology (ISMICT).  IEEE, 2016.

[12]  Filip  Mazan and Alena  Kovarova.  A study of devising neural network based indoor localization using beacons: First results. In CISJ Vol19 No1 2015., 2015.

[13]  V. N. Padmanabhan P. Bahl.  Radar: An in-building rf-based user location and tracking system. In INFOCOM  2000. Nineteenth Annual Joint Conference of the IEEE Computer and  Communications Societies. Proceedings. IEEE, vol.  2, pp. 775-784., 2000.

[14]  Jeongyeup Paek, JeongGil Ko, and Hyungsik Shin.  A measurement study of BLE iBeacon and geometric adjustment scheme for indoor location-based mobile applications. Mobile Information Systems, 2016:1–13,  2016.

[15]  Piotr  Sapiezynski,  Arkadiusz Stopczynski,  Radu  Gatej,   and Sune Lehmann. Tracking human mobility using WiFi signals. Tracking Human Mobility Using WiFi Signals, 10(7):e0130824, 2015.

[16]  Takahiro Uchiya Ichi Takumi Shinsuke Kajioka,  Tomoya Mori and Hiroshi Mat- suo.  Experiment of indoor position presumption based on rssi of bluetooth le beacon. In IEEE 3rd Global  Conference on Consumer Electronics (GCCE) 2014, 7-10 Oct. 2014., 2014.

[17]  H. Jiang Z. Chen, Q. Zhu  and Y. C. Soh.  Indoor localization using smartphone sensors and ibeacons.  In IEEE 10th  Conference on Industrial Electronics and Applications (ICIEA), Auckland, 2015, pp. 1723-1728., 2015.

[18]  Faheem Zafari and Ioannis Papapanagiotou. Enhancing iBeacon based micro- location with particle filtering.

[19]  Luo Haiyong Zhu Jianyong, Chen Zili and Li Zhaohui. Rssi based bluetooth low energy indoor positioning.  In IEEE 2014 International Conference for Indoor Positioning and  Indoor Navigation (IPIN), 2014.

IELS: Indoor Equipment Localization System: Discussion (Part 5/6) (IoT)

Discussion

When this project started, the idea was simple. The goal was to localize objects inside a building environment in an easy and affordable way.

This  idea  turned out to  be  a wide  research area, and lead  to  try different approaches as explained in this chapter.

We think adding walking steps, compass and gyros  sensor to predict moving direction would help creating extra  virtual position. This would add extra  position for our calculation process. We did few experiment in this direction but decided to leave this for future development.

In addition, concepts like fingerprinting and dead reckoning will add value to the system, both should be considered for future improvement.

We have  at  some point considered machine learning for clustering prediction. We think this can be an interesting area of research, for its own.

In our experiment the  user  hold the smartphone in his hand, but  how about collecting data while having the  smartphone in a pocket, at leg level or on a table etc. This could be interesting to clarify,  as it is our  ultimate goal to predict objects while having our smartphones in a pocket.

We thought about adding extra  smartphones in a fixed position that collects data permanently to improve stability of results.

Another interesting aspect could be to try the  same approach with  less iBeacons and try it with directional iBeacons to cover  specific regions. We have  tried to work with eight iBeacons, but we observed that our  software fails to return results.  An- other approach is to  try with  only  four  iBeacons at  each corner of the  room and predict region position estimation instead of x and y position.  We have  at the end chosen to focus on our existing setup with 14 iBeacons and decided to leave this for further research.

Power consumption is important to bring up,  this means a lot for end-users. We do not want to let our  app drain battery from  a user’s smartphone.  Therefore, it is ideally to collect data periodically. For instance, we collect data once only  when a user or the smartphone is stable and not in a movement. We recollect data again when a user or the smartphone change position status. First of all that would reduce noise, improve accuracy and improve battery operation time.

We thought in the long term, that if our app should cover  big buildings, we could easily combining iBeacon data and Wi-Fi data to cover  most of the building without necessarily deploying iBeacon all over the building.

It is true that our  algorithm is tested, works  and deliver the  results we present here in this  report, but  we would like to mention that, it has a place for further improvement. We will mention some of the improvements, that we observed with our algorithm. While we developed the algorithm we did not think of efficiency and running time. This might be possible to improve. The sorting process of iBeacons strongest signal does not guarantee that the strongest signal is the  nearest iBeacon. This  has  therefore reduced the overall accuracy results.  This is left for future improvement.

An interesting test would be with the use of real evaluation with real end-users in a real environment out of the IT-University. Especially the input from  the end-users and the business owners would be a valuable information to have.

It is our  ultimate goal to use  the  smartphone as a crowdsensing device, but nevertheless, this  will rise a new  question about privacy issues. For example: will end-users accept using their smartphones to collect his/her position in which we would be able to use it for localizing trackable objects? Is there a mechanism to use crowdsensing for prediction object location without keeping the data from  a smartphone? These questions need to be studied and clarified.

IELS: Indoor Equipment Localization System: Implementation (Part 3/6) (IoT)

Implementation

3.1    Software architecture

The software architecture is based on three main components, Mobile Client, Data Server  and Admin Server  as shown in figure  3.1.

  1. Mobile Client is an Android application. Its main purpose is to collect iBeacon data such as RSSI-values and send it over to the data Server.
  2. Data Server is a Restful API (Application Programming Interface) that takes care  of the  data collected by Mobile Client application.  Data Server  is also responsible for business logic and calculation algorithm. Data Server  have  a UI, to show RSSI results of experiments.
  3. Admin Server is a Web Application with Restful  API offer an administrator UI help to manage the iBeacons and smartphones information.

The  idea  of separating Data Server  and Admin Server  relies  on  future thinking. Hence Data Server  purpose was  only  experimental and data analysis. We thought at some point the  Data Server  will end its job and the  logic of the algorithm will be implemented directly in the smartphones. That  way the  smartphone will take care of all logic and returns its x and y position directly to Admin Server.

ImplementationFigure 3.1: System Architecture. We show how  Mobile Client connect once at startup of the application to Admin Server to get a list of all allowed devices and iBeacons. When the Mobile Client is done with collecting of iBeacon data, it posts our  data to Data Server. When we start Data Server it connects to Admin Server to get a list of all allowed devices and iBeacon.

3.1.1    Mobile Client

The  main purpose of Mobile Client Android application  3.2 is to  collect iBeacon RSSI data.  When the  application starts up,  Wi-Fi,  Bluetooth and Location service turn on,  because it is required, otherwise it will alert the  user  3.3.  This  is required to update initial iBeacons (iBeacon fixed position, name of device etc.),  data from Admin Server, sending and receiving data over  Wi-Fi, receiving iBeacon data using Bluetooth. When a user  enters experiment name and start collecting process, it will check for six conditions before collecting iBeacon data as described here and shown in process flow 3.5:

  1. Data-structure: the application will connect to the Admin Server  to build a data structure of activated iBeacons with initial information such as fixed  X and Y position of iBeacons, names of iBeacon, name of trackable object iBeacon  and smartphones name if registered in system.
  2. Registered: it checks if a smartphone device is registered and is allowed by the Admin Server.
  3. Bluetooth: it checks if Bluetooth is receiving data from  iBeacons as expected.
  4. Connected: it checks for Restful  API connectivity.
  5. Collecting: smartphone starts collecting real-time data over 60 second.
  6. Send Data: when 60 seconds is over, it posts the collected data to Data Server.

Android Client
Figure 3.2: Preparing page.

Android Client ErrorFigure 3.3: Alert page

Figure 3.4: Mobile Client Android application. When the application is ready to collect  data for each experiment, the  Start-button appears automatically to the user. When the collecting time is over  it will automatically post the data and give a pipsound at the end. In case  one  of the communication service like Wi-Fi, Bluetooth or Location Server  is down, the user  gets alert.

Android app flowFigure 3.5: Mobile Client application process, shows how the application react while starting up until the user is ended with the experiment.

3.1.2    Data Server

Data Server is a Restful API. It receives iBeacons data from Mobile Client Application and store it on  real-time database from  RethinkDb 3.8 (an  Open Source real-time database). Data Server  stands for business logic and calculation algorithm. In addition, it offers  a UI 3.6 to show graph of RSSI-results 3.7 for analysis purpose. The server works  on a local machine in PitLAB.

data server uiFigure 3.6:  Data Server  UI. We built this  system to deliver the tools  we needed to make our  experiment process smoother. It delivered data to Excel or showed RSSI- values of given experiment

RSSI samplesFigure 3.7: RSSI samples. This is example of Data Server  UI that shows RSSI-values of given experiment

realtime rethink databaseFigure 3.8: Real-time Rethink Database administration UI. In our  development we used Rethink Database, it has  own  API that is compatible with programming language such as Java, C#, PHP and many other programming language. This  means it deliverers us a simple ReQL (RethinkDB Query Language) which we can  use  on different platforms

3.1.3    Admin Server

Admin  Server  is a cloud based Web  Application  which delivers an  administrator UI 3.9 to manage all devices and iBeacons allowed to interact with  the  system. In addition, it offers  all initial information about iBeacons, trackable object and Mobile Client.

administrator uiFigure 3.9: Administrator UI. This is Admin Server  UI which helped us adding new iBeacons or smartphones to our experiment.

3.2    Development challenges

In previous chapter under different smartphones challenge section 2.2.2.1, it is described how we had challenges with developing a Mobile Client.

We developed our  Mobile Client on  Google Nexus 5X smartphone with  single iBeacon and it collected iBeacon data as expected.  When we tested the same application on  the smartphone we  got  from  PitLAB (Motorola Moto E3) the we  got different results. First,  we thought our  software had issues and we tried to re-write and improved our code, but we ended up understanding that it was a hardware issue rather than software.

Throughout the project, we had minor network issues in PitLAB. Unfortunately, we were  not  able  to start our  server with the given  IP address. Luckily, the management of PitLAB offered us access to an internal Wi-Fi system that was reliable and stable.

3.3    Conclusion of this chapter

In this chapter it has  been explained how  our  software infrastructure was  implemented. At an early stage of development process of this project, the main idea  was simple: how to collect iBeacon data and process it? This idea  turned soon to require us to develop three main software solution: a Mobile Client, a Data Server and an Admin Server. All of them intercommunicating with each other. We have  learned that developing software for iBeacon for one smartphone does not necessarily means it works  for all smartphones.

How to Create virtual COM port pairs in Windows for development (IoT)

Just imagine you are developing embedded device or IoT device solution where you need to interact your software with a hardware device over Com port.

Normally you need to have your real device turn on and connect it to your development PC before you can interact with it. The challenge is that you might developing your software and the embedded prototype is not ready yet, you are waiting for it, you need to testing it locally before connecting to a real device or just to emulate the data communication before developing embedded prototype. Then your only way is to create a virtual Com port.

In this article I am going to use Virtual Serial Port Driver 9.0 from Eltima’s software.

I will demonstrate how to use Virtual Serial Port Driver 9.0 using two different examples:

  1. Chat example based on C#, using Microsoft System.IO.Ports example.
  2. Using C# to emulate embedded device that sending sensor data using and receive the data.

Before we dig into examples, let download Virtual Serial Port 9.0 standard edition from https://www.eltima.com/products/vspdxp.

Install the software and start it.

Click on Add Pair

And Ya, That’s it, now you have 2 com virtual ports COM1 and COM2.

I found Virtual Serial Port Driver 9.0 one of the easiest and most stable virtual serial port software on market. It allows me to develop and test my code before spending hours on a real device testing.

Example 1

I have visited Microsoft SerialPort Class  (Sytem.IO.Ports) page and found a chat example. I have created visual studio solution that contains all example of this article on my git ComPort. Clone it and fire up your Visual Studio with the solution twice (I do used VS2017) and yes, I mean start Visual Studio two times because we need to have 2 chats to connect to each other.

Make sure your Chat project is set as Start-up project on both VS.

Visual Studio Chat

Start the program (ctrl + F5) on your first VS and your console will start asking you questions, just press ENTER (leave empty) until you reach the name, just give any name, I call my first chatter Joe as you can see in the image below.

Virtual Serial Port Driver 9

Start your second console program, this time you need to tell the program that you are using COM2 as shown in the image, and tap ENTER until the name and just give it any name, I call my second chatter Doe as you can see in the image below.

Virtual Serial Port Driver 9

Now Joe and Doe can chat between each other.

Virtual Serial Port Driver 9Virtual Serial Port Driver 9

Just imagine if this virtual communication was made with a real device that can receive messages from your system or the other way around, as we gone demonstrate on the next example.

Example 2

In this example, I am going to use one port to sending some random sensor data, and I will fetch the data on the other port.

This example is based on real scenario that I have used previous in one of my research and development projects. I was developing a hand gesture solution and my only prototype was not available, So I designed a software that emulate the data and send it as it was the hand gesture, but over my virtual com port.

Now in stead of have Chat as start-up project, set your first Visual Studio start-up project to Emulator and the second one to DataReceiver.

Visual Studio 2017

Now start-up your Emulator program (ctrl + F5) nothing should happen.

On your second Visual Studio start DataReceiver program and you should see that Emulator program is sending x, y, z data and it being collected by DataReceiver program.

Virtual Serial Port Driver 9

You can also see the amount of data being sent and recevied by ports.

Virtual Serial Port Driver 9

Now you should be able to parse your received data and make your programming logic with out having a real device.

Links:

IELS: Indoor Equipment Localization System: System Design (Part 2/6) (IoT)

System Design

In this chapter, we will explain the system design behind Indoor Equipment Localization System (IELS).

Before we go into the details of the system, the main goals of this project will be elaborated. The following questions are chosen in order to create a direction for the project:

  • Q: What is our goal?
    A: To localize object in room.
  • Q: What do we need in order to localize object?
    A: Some reference positions.
  • Q: How to get reference positions?
    A: Some localization techniques like Trilateration.
  • Q: What does Trilateration need?
    A: At least 2-3 Distances.
  • Q: How do we achieve distance?
    A: One way is to convert RSSI values to distance.
  • Q: How do we get the best values?
    A: by sorting strongest RSSI values.

These questions guided us to solve small problems that might be in a chain of a bigger problem. It helped as well to make some useful choices in our algorithm development.

In next section it is explained how our algorithm works and then take the elements that is involved in its development.

2.1. The Logic of the chosen Algorithm

The algorithm pseudo 1 is used for calculating the location of a smartphone that we use to calculate our trackable object location. Each step that has correlated processes and dependable methods will be explained later in this chapter.

In the infrastructure of the system, we use 14 iBeacons with fixed position and one iBeacon as trackable object as described in our evaluation experimental setup section. We use one mobile smartphone to collect our iBeacon data.

While we implemented our algorithm, we made regularly small tests, experiments and trail and fail, until we reached our solution. Conceptually one of the research papers gave us interesting knowledge about our Algorithm by Jea-Gu Lee who is mentioned in our Related Work-section. The main difference is that they use Double Gaussian Filter in their approach. In addition, some inspiration came from a previous work of Wouter Bulten.

In our approach, we collected all reachable iBeacons RSSI values over time and sort RSSI values in a descending order for each second. Then we take the three strongest RSSI values and convert those to the distance. Finally, by using trilateration mathematical equation we predict the estimate position of x- and y-coordinate of the mobile smartphone.

When we predict positions, we use the positions to calculate the position of our trackable object. A simplify example illustrate how our algorithm works to predict the estimated position of a trackable object in a room(see figure 2.1). When we collect more than one reference point like ’User A’ with a smartphone, we get estimate position A and estimate distance to trackable object (X1, Y1, d1). At some point, another user, ’User B’, with another smartphone get estimate position B and estimate distance to trackable object (X2, Y2, d2). This is the minimum information we need in order to calculate and predict the estimated position of a trackable object (X object, Y object). Our algorithm is used to predict an estimated position of a smartphone location over time and we use that information to calculate the estimate position of a trackable object.

Object localizationFigure 2.1: How to estimate a position of a trackable object from User A and User B.

In the previous section we explained the concept of our algorithm. In the following description we present the pseudo 1 code of the used algorithm.

Init Map Device Data Structure
Collect iBeacon RSSI
initTimeSeries {keep RSSI last value until updated}
kalman {Kalman filter RSSI for each iBeacon}
results {Moving Average of each kalman results}
bestRSSI {Sort results select best 3 RSSI each second}
(Note: Sort RSSI value descending order)

For each rssi set of $bestRSSI$ compute $DISTANCE(RSSI)$

If {at least 3 distance available}
    Return {$positionXY$($x_1$, $y_1$, $d_1$...$x_n$, $y_n$, $d_n$)} Else
    Return {no results}
EndIf

Procedure{distance}{$RSSI$}
    Compute RSSI to Distance
    Return $distance$
EndProcedure

Procedure{positionXY}{$x_1$, $y_1$, $d_1$...$x_n$, $y_n$, $d_n$}
    Compute using Trilateration
    Return $x_{new}$, $y_{new}$
EndProcedure

Initially, we initialize the data structure that contains all initial information aboutour fix iBeacon position, trackable object and mobile smartphone. The system then collects RSSI-values from all iBeacons (fix iBeacons and track-able object iBeacons). Our initTimeSeries will keep last RSSI-value until a new value is received. This isto guaranty that all iBeacons have values we can use for calculation.Afterwards, RSSI-values unfortunately includes noise (we will explain noise prob-lem later in this chapter), but with the use of a Kalman filter, it is possible to take theraw values and try to decrease the noise from the values and thereby predict newvalues. We take values from the Kalman filter and run it through moving averagefilter to smooth the RSSI-values.Finally, we sort RSSI-values and take the three strongest values for each second.

Now for each of these strong RSSI-values we use distance method to convert RSSI to distance. If there is at least three distances then we calculate location x and y.

2.2. Proximity distance estimation

As we mention in chapter 1, localization proximity is about having distance estimation between two objects, for instance smartphone receive iBeacon (RSSI-values)signal in dB (Decibel). This said, higher dB-values means stronger signal, which means shorter distanceto the sender-device. We allow us to transform this relation of dB-value to estimatedistance between sender- and receiver-device. There are a variety of methods forthis. In this thesis we mention three methods in section. There are various reason why distance estimation cannot be 100% accurate, suchas different types of obstacles as explained in paek paper page 7, section 4.7. The following section will introduce some distance estimation in more details.

2.2.1. Indoor Distance Estimation using RSSI signals

The nature of iBeacon RSSI-signals are unfortunately rather inaccurate, unstableand contains noise. Many factors play a role in fluctuation of RSSI-values; for in-stance, obstacles like: human movement, human body, type of wall, type of materi-als and other external noise factors etc.

In addition, each smartphone model and type has different BLE receiver, thatbehave differently from phone to phone.

Therefore, it is important to have a revision of measured RSSI-values for each en-vironment and each smartphone before using them as mentioned by Lee. Fromthis we can build a data model for each environment and smartphone type whichwe will describe in this section 2.2.2.1.

Regarding materials type that influence RSSI-signal, a paper by paek mentionthis problem in page 7, section 4.7. They solve this by building a data model for it.

2.2.2. RSSI measurement

As describe earlier in our algorithm logic, we need to estimate distance to calculatethe estimated position. In our case distance comes from RSSI-signal strength. Wewant to measure and understand the relation between RSSI and distance. This said,it is important to validate this and put that in a model so we can use it in our algo-rithm.

For this experiment, we use Estimote iBeacon (in the yellow circle) as a sendersource and LG Nexus 5X smartphone (below the half yellow circle) as a receiver.

We mark the floor with read/white lines indicating real distances from 0 to 30 meteras shown in figure 2.2. This measurement take place in front of PitLAB, 5th floor atIT-University of Copenhagen.

We collect RSSI-values over 60 seconds as shown 2.3 and calculate the averagevalue of morning, noon and night. The reason we choose morning, noon and nightis because in previous tests we made, we can see different behaviour and results forRSSI-values in those parts of the day.

Room RSSI calibrationFigure 2.2: RSSI-value over distance measurement, in front of PitLAB

Room RSSI measuresFigure 2.3: RSSI-values of morning, noon and night. All real distances are in metersand all RSSI-values in dB

Finally, the data is plotted in a graph 2.3, and the relation between distance andRSSI-values becomes clear. The results of the graph clearly shows a logarithmic cor-relation between signal-value over different distances in meter.

It is important to mention that RSSI-values can easily be affected by environment,signal-sources from other devices like Wi-Fi page 7 and obstacles page 8, hu-man body, walls etc. Even thus we have the smartphone and the iBeacon place ina fixed position. The importance of measurement gives us an approximate estima-tion of that particular environment and smartphone we use. Furthermore, the erroraverage increases as the distance increases as demonstrated in graph.

Graph RSSI measuresFigure 2.4: RSSI-value logarithmic correlation to distance. X: real distance in meter,Y: measured RSSI-value

2.2.2.1 Different smartphones challenge

From our tests and observation, we found that different smartphones have differentreading of RSSI-signal strength value and are not equal with latency. Latency in thiscontext is how many RSSI samples are received per second.

In addition, we observed also that smartphones behave differently in morningand evening time. For instance, the same smartphone with the same software cancollect up 3-4 samples per second in the evening hours and only one in the morn-ing or noon. The reason for this can be many, but one might be noise generatedfrom other sources such as Wi-Fi-usage in open hours. This said, it is unclear whatcaused this behaviour. Interesting enough while we worked with these challenges,a recently published paper from Fürst mentioned some of these challenges. Wehave added a minor supportive arm to some of the experiments in this paper asshown in figure 2.5. The measurement shows different results from different smart-phones as shown in the chart.

SmartphonesFigure 2.5: Smartphones comparison, collecting RSSI-values from same source. Ex-periments from the following paper

Graph RSSI distance boxplotFigure 2.6: RSSI variation between different smartphone models from paper

2.2.3. RSSI distance calculation

We built a data model for our RSSI-value over distance in meter, but have can wecalculate RSSI-values to distance? There are many ways to calculate the estimateddistance between iBeacon sender- and phone-receiver using the RSSI-values.

In our design we experiment with three different methods, and make a compari-son chart 2.7 between the results.

For the following methods the iBeacon txPower (txPower stays for BroadcastingPower or Transmission Power of iBeacon) was set to -12dB and advertising rate is setto 967ms:

1- Generic log distance. . . is a generic method that is known to be used inmeasuring distance based on RSSI-values. The method results depending oniBeacon transmission power and a free space factor value which is normally between 2 and 4, in this experiment we used -12dB txPower which is the de-fault value by Estimote and the free space factor was set lower than 2 hence toreduce error scale:generic log distance

txPower = transmiton power of iBeacon

RSSI = value of signal strength

Free Space Factor = a value between 2 and 4

2- Estimote. . . is mentioned in two research papers”An Analysis of the Accuracyof Bluetooth Low Energy for Indoor Positioning Application”and”A Mea-surement Study of BLE iBeacon and Geometric Adjustment Scheme for IndoorLocation-Based Mobile Applications”.The same method is used and supported by Estimote beacons. It issimilar to previous method but the factor is set to a fixed value two. The mathformula for this method is:Estimote

rssi1= RSSI is measured in 1 meter, in our case it was -68dB
The final result is multiplied by 1000 to get results in Millimeter.

3- AltBeacon. . . is based on AltBeacon library and is used in a paper”An IndoorPositioning Algorithm Using Bluetooth Low Energy RSSI” with followingmath formula:

Altbeacon

The numbers 0.89976, 7.7095 and 0.111 are constant values set by the devel-oper of this method with out further explanation.The final result is divided by 1000 to get results in millimeter.

NOTE: All mentioned methods in our RSSI distance calculation section returnresults in millimeter unit.

We test all above mentioned methods in Excel and Java, the result of all methodsare presented in graph 2.7 shows conversion of RSSI to meter for each distance.

The results clearly shows from figure 2.7 and error figure 2.8 that Method 1 has least errors, and Method 3 has most errors in our LG Nexus 5x smartphone.

It is clear that RSSI do not increase linearly with distance, the error margin in-creases as the distance increases. That said, all this can change from place to place,depending on the noise and distortion on that particular environment, but the log-arithmic correlation would still hold on all environment.

Graph RSSI tometerFigure 2.7: RSSI over distance in meter comparison graph for different conversionmethods, X: Real distance in meter, Y: Measure distance in meter. The iBeacon tx-Power was set to -12dB with advertising rate is set to 967ms11

Graph RSSI errorFigure 2.8: RSSI over distance in meter comparison graph for error level of differentconversion methods, X: Real distance in meter, Y: error level in meter. The iBeacontxPower was set to -12dB with advertising rate is set to 967ms

2.3. Time Series Processing

’Time series’ refers to a sequence of observations following each other in time, where adjacent observations are correlated. The main reason for using time series processing in our project is because we observed form early experiments that our raw RSSI-values contain noise over time. We have analyzed raw RSSI-values, as shown in oneexample in graph 2.9.

It is therefore obvious to work with time series processing methods. As men-tioned earlier, for various reasons, there will always be “noise” and “distortion” inwhen receiving a iBeacon RSSI-signal, even if the receiver is not moving. This wouldrequire a way of cleaning and processing strategies for time-series data.

The book Ubiquitous Computing Fundamentals shows various methods forhelping smoothing RSSI-values by filtering out the noise and distortion from differ-ent fluctuations. Time series models can be simulated, estimated from data, andused to produce forecasts of future behaviour.

In this project, we know that we have something to do with time series process-ing but was not sure which one and how to use. We gathered some basic knowledgefrom different resources (like previous works, Ubiquitous Computing and online re-search). Then we did a lot of trial and error, all ended up with using two popular filtering techniques: The Mean filter (Moving Average) and the Kalman filter.

2.3.1 Moving Average

Moving Average (MA) filter is a trend-following (trend in this context means a pat-tern of gradual change in a condition, output, or process, or an average or generaltendency of a series of data points to move in a certain direction over time2) be-cause it is based on past RSSI-values in this case. There are different types of movingaverage, the most common used Moving Average for this purpose is Simple Mov-ing Average (SMA), which is the simple average of a security spread across a definednumber of time periods. The most common applications of Moving Average are toidentify the trend direction and to determine signal level.

In our design, we implement a moving average and demonstrate the differencebetween our RSSI-input (black trend) and Average (green trend) output in figure 2.9.

The moving average takesnnumbers of RSSI-values, defined as window size. The method returns the average of RSSI-value of the given window size.

Our moving average implementation is based on following formula inspired fromJohn Krumm book Ubiquitous Computing Fundamentals kalman We have set our n value (window size) to be 10, we can see clearly this methodreduce some of the noise from the original input. We have tried different windowsizes, if window the size become five we get more noise in output and if we increaseit to 20-25, this will cost calculation delay of processing. It was decided to work withnumber ten to reach a balance value for this purpose.

Graph RSSI filterFigure 2.9: RSSI filter comparison, X: Time in Second, Y: RSSI value in dB

2.3.2 Kalman

Kalman filters will not be described in details, since there is a lot of papers and on-line resources describing Kalman filter. Roughly, we use Kalman filters to reduce thelarge spikes of RSSI-values as shown in graph 2.9, while trying to retain distance in-formation. A (regular) Kalman Filter is used to filter incoming signal strength mea-surement. The true RSSI-value (without noise) is defined as the state we want toestimate. Our Kalman filter implementation is based on existing pseudo-code of aprevious master thesis done by Mr. Wouter Bulten.

A Kalman filter returns RSSI-values as a Integers and we can see from the figure 2.9 that a Kalman filter reduces some of the noise from the original RSSI input.

2.3.3. Combining methods

From both observation we can see both methods reduce an amount of the noise.In this project we wanted to try to combine moving averages and Kalman filter toreduce the noise from RSSI-values as shown in figure 2.9. What we did is passing thelast measured result of the Kalman filter to the moving average of ten window size.This has reduced the noise drastically.

At an early stage we put the values into a spread sheet and made some primitivecalculation. Then we implemented a simple version of Moving Average that helped a bit to remove some of the noise, but not all of it. Later in the development processafter trying with different other methods, we tried to implement an already existingpseudo-code of a Kalman filter inspired from the master thesis by Mr. Wouter Bul-ten. The method did indeed remove some of the noise as well. We thought: ifboth filters remove some noise, it could perhaps be an option to combine the fil-ters – and the quality of the results increased significantly. One of the reasons our graph has a straight line is because we use Integer values which cleans up some ofthe noises as well.Nevertheless, this comes with a cost: Mostly, it takes up to 10 seconds before thesystem is able to calculate values.

2.4. Localization algorithms

There is different ways and methods to use for localizing – all depending on the out-come and the requirement of the project. As mention in chapter 1 there are sixmethods for localization and we have already defined the methods.

So far we have used proximity relation to RSSI over distance estimation. Now wewill use Trilateration in our algorithm hence we have a lot of distance andxandypositions. Hyperbolic lateration is more related to time of flight (TOF) techniquewhich is used in GPS-localization and Triangulation is typically used for high an-tenna tower. Fingerprinting and Dead reckoning might be relevant to our projectbut is left for the discussion-chapter.

Trilateration 2.10 is a mathematical equation that computesxandyposition ofa smartphone in our case, by calculating at least three distances to fixed positions ofxandy. Trilateration is able to calculate the position by using two distances insteadof three, but that will increase the error level which leads to reduction of accuracy.

TrilaterationFigure 2.10: Illustrate how trilateration works

In our Algorithm, we use a Java-library called Lemmingapex trilateration. Wewanted to be sure that this library works correct. We injected different tests withthree positions and three distances and we got an expected results.

In addition, we have also chosen to implement a lightweight and static (static inthis context means sensitive for estimate distances) trilateration method for com-parison purpose, and we implemented a basic trilateration formula from The Uni-versity of Georgia3. The university provide a detailed explanation and sample excelfile with math formula. We have used the same test data from previous method andwe got close to identical results. Hence Lemmingapex has been used by some de-velopers and has better features then our basic implementation. It might take morethan three reference points and are more dynamic (dynamic in this context meansthe method is suited for handling estimated distances), we have therefore chosen tocontinue using the Lemmingapex-library in our implementation.

2.5. Conclusion of this chapter

In this chapter we presented different methods: distance estimation based on RSSI-values, moving average, Kalman filter and trilateration. All of them to calculate smartphone positions. The progress of this process relies heavily on previous work and achievements from other papers, inspiration from Ubiquitous Computing Fundamentals by Krumm, reverse engineering thinking and most importantly: trail and error. We conclude here that RSSI-values have logarithmic relation to distance as well as errors margin rise as the distance increases – and how RSSI is able to change values from surrounding environment and external factors. Finally, different smartphones type and models gives different results.

MyThings 2 Android App (IoT)

MyThings App

This app is to store a list of own things, location and bar code scanner of items. The list will be saved on the device locally and it can be synchronized over Rest Api both ways in cloud.

Introduction

Based on my previous app MyThings App v.1 I have further developed on it and built MyThings app version 2.

It is basically containing the minimum of following requirement plus some extra fancy creative and technical features.

1. The minimum requirement is:

  • Local database using SQLlite.
  • Create/Delete/View things from database.
  • Rest Api Synchronization
  • Ability of scanning bar-codes for new created things.
  • Search for thing based on scanning bar-code data in database.

2. Smart fancy features

  • Force update database by swiping on My Things fragment.
  • When screen get rotated the fields and searching result will keep remembered.
  • Icon added to the tab layout
  • When press overview button on phone hardware button it changes the tabs with logo and name of MyThings App.
  • Refreshing list view on fragment transparently without using intent (This was problem I have had in my previous assignment, it is fixed now)

3. Futuristic features

  • Building own Restful API to MyThings to sync both ways, it is build half way right now and because of time running out, it is put to side.
  • Adding Camera/Images of things to the list view.

Backend structure

MyThings App v.2 has the similar structure as previously, but it has got improvement on naming and variable conventions, Class are well structured, and in addition it has got google zxing barcode reading class library.

In my opinion the best documentation for coding is to make self-explaining code and structure. That makes it easier for team to understand. This is the case also in MyThings App.

When app get fired, the main activity launcher calls ThingsMainActivity class. Which is the skeleton of the app.

onCreate method must call super class implementation of this method which is part of life cycle, so in the beginning of onCreate I call CreateDummyThings.dummyCreate(this) method in class, it creates 3 dummy book in our local database. Off course we are able to create or delete more if we want so.

1.1.    Local database

Our database structure under Database folder contains 3 class inspired directly from the Android Programming 2nd Edition book that we use in our course. I could have also used some example from Android Source site or Internet in general, but I found the examples are nice and well presented. Under Entity I have a Thing class that has the definitions of fields.

I have also a ThingLab class inspired from the book as well. It is the bind logic between database calls and the controller.

1.2.   CREATING, DELETE AND VIEW THINGS

Our ThingLab class contains the required method required to get, add and delete things from database.

Our Adapter ThingListAdapter showing things in list view by calling getThings method as instance of ThingLab

public List<Thing> getThings() {
   List<Thing> Things = new ArrayList<>();
   ThingsCursorWrapper cursor = queryThings(null, null);
   cursor.moveToFirst();
   while (!cursor.isAfterLast()) {
       Things.add(cursor.getThing());
       cursor.moveToNext();
   }
   cursor.close();
   return Things;
}

The method simply iterates our database and add all things table rows in our ArrayList elements, and return it as List that we can use to view it on our list view.

In case we want to search by barcode to find specific thing we simply create new method similar to getThings call it getThingsBarcode (String input) and the method works in the same way, the only difference is we add query inside the method like:

ThingsCursorWrapper cursor = queryThings(
    MyThingsTable.Cols.BARCODE + " = ?",
    new String[]{input}
);

And we will get a list of things that has the same barcode.

This is to demonstrate the concept, else it is possible to search everything and get single results or list (multiple) of results.

Deleting things require us to specify which element to delete, so our code snippet will look like this, it is similar to search query but here we ask for deleting the finding results. The method delete single results, as is right now.

public Thing deleteThing(UUID id) {
    ThingsCursorWrapper cursor = queryThings(
    MyThingsTable.Cols.UUID + " = ?",
    new String[]{id.toString()}
);
 
try {
        if (cursor.getCount() == 0) {
        return null;
    }
 
    mDatabase.delete(MyThingsTable.NAME, MyThingsTable.Cols.UUID + " = ?", new String[]{id.toString()});
 
    cursor.moveToFirst();

    return cursor.getThing();
    } finally {
        cursor.close();
    }
}

Finally creating new things at the other hand requires us to pass data like what and where information as minimum and barcode is optional. So for example our dummy thing creating method called doCreate that pass the mentioned data to our addThing method and it will create those data in our table.

doCreate method under CreateDummyThing class under Util folder

doCreate(Activity activity, String what, String where, String barcode) {
    mThing = new Thing(what, where, barcode);
    ThingLab.get(activity).addThing(mThing);
}

addThing method under ThingLab class

addThing(Thing c) {
    ContentValues values = getContentValues(c);
    mDatabase.insert(MyThingsTable.NAME, null, values);
}

 

You can download source code: https://github.com/maythamfahmi/mythings-app

GuideBelt Project (IoT)

GuideBelt

We see every day new technologies coming out to market but a few of those technologies are focused for people with special needs.

We have just finalized a research project called GuideBelt. It is simply a Bluetooth-based indoor navigation system for the visually impaired.bluetooth based indoor navigation system for the visually impaired

The GuideBelt, which is the product of this research, is such a solution that takes advantage of cheap Bluetooth beacons attached to places/objects of interest within an indoor space.

The implementation of the GuideBelt that has been the focus of this work is an early prototype, which uses phones to simulate the Bluetooth receivers (coupled with a vibration module). This was to allow us to focus on development of the algorithm rather than electronics. Therefore, the direction of this research is towards the implementation of the system with the actual technology necessary meaning with assembled electronic components (including Bluetooth modules and vibrators).

We have also wrote a research paper of our experiment that contains important details of the project.

We have made a little image site to present some images of the development:

https://dev.itbackyard.dk/guidebelt

We have also produced a video of the experiment:

Research and Development

  • Abdulrashid Mohammed
  • Maytham Fahmi
  • Tanase Comboeanu

Feedback for development
Thomas Pederson, Shahram Jalaliniya, Alexandre Alapetite

Technical support
Sebastian Büttrich

SPECIAL THANKS
Birgit Christensen and all participants

Augmented Reality for doctors (IoT)

Hospital Journal

A project that enables doctors to see patience hospital journal virtually through augment reality, at the same time it is possible to navigate thought the journal with hand gesture.

Code only accessible for group members: https://bitbucket.org/maytham/hospital-journal

Read paper PDF: Hospital journal

 

Context Awareness Project (IoT)

Context awareness

In this paper we describe the concept, development and reflection for Pervasive Computing course (Spring 2015) at IT University of Copenhagen
where we built a context-aware mobile phone utilizing an iBeacon infrastructure.

Code available for group members

PDF download: ITU Contextphone platform