From Knoesis wiki
Jump to: navigation, search

LOKILAS:LOst Key Identification, Localization and Alert System


This project aims to solve a practical problem encountered by researchers in some of the Kno.e.sis labs regarding their shared lab keys. The keys in each lab are a shared resource to give the researchers access to shared facilities, such as conference rooms. Unfortunately, people who use the keys too often forget to return the keys in a timely manner and there is currently no system in place to track said keys. This can cause inconvenience and frustration for individuals who later need to use a facility but are unable to find the required key. Currently, the solution to this problem is to attach larger objects to a shared key, such as the key shown in Photo 1, so that the key cannot be forgotten in a pocket. While this solution may work, there is still an inconvenience to carrying the larger “keychain”. Project LOKILAS hopes to create an intuitive system for tracking and recovering the shared keys.

Set of Keys shared by researchers in the Semantic Sensors lab at Kno.e.sis

Project Specification

The proposed system would be required to track the shared keys in a lab, identify anyone who takes one of the keys, and alert the person who took the key to return it after they are done with the key. Various sensors monitor the keys currently at a base station in a lab, identify any person who approaches the base station, and report the status of the rooms tied to each key. The status of all monitored items is then reported by the sensors to a server where the information can be combined and processed. If a certain amount of time has passed without the key being used or returned, an alert will be sent to the person who originally took the key from the base station through either SMS or email. Finally, the status of all keys and rooms may be monitored through a pair of Android applications.
This project is based on the internet of things concept. Keys, people, and rooms are each identified and networked to provide a more intelligent tracking system.

Everyone turns off the lights when they are done using the room.
Only the key that was taken will be used to access the associated room. Meaning that if a different key is used, the system may incorrectly believe that the key is still in use, causing the system to continue waiting instead of sending an alert (assuming the key is still missing).
A key that was taken from the base station does not leave the proximity of the person who took the key before it is returned to the base station.
Each key and person can be identified relatively quickly at the base station so as not to slow the person down.


System Architecture

See Fig. 1 for a visual overview of the system data flow and overall architecture.

Figure 1: LOKILAS System Architecture Overview
  • Room occupancy detection/status module
    • Room occupancy sensor
      • Uses attached sensors to determine whether a room is occupied or not.
      • Room status is then reported to a server at a set interval
    • Java Servlets
      • Acts as interface for room sensors and clients to access the room status database using HTTP.
    • Android Application
      • Simple visualizer for the latest room status information stored in the server’s database
  • Key tracking and alert module
    • Java Servlets
      • Acts as interface for key and person sensors to access the appropriate database using HTTP.
    • Server-side application
      • Performs logic to determine missing keys and alert users by email or SMS if the key is not used and/or not returned within a given time span.
    • Android Application
      • Simple visualizer for the latest key status information reported by the server


  • Client-side
    • Android
  • Server-side
    • PHP
    • Java servlets
    • MySQL
  • Hosting environment
    • Apache
    • Tomcat
  • Sensors
    • Arduino
    • Ethernet shield for arduino
    • Passive infrared sensor (PIR)
    • Light Dependent Resistor (LDR)
    • Color detection sensor

Milestones & Responsibilities

Weekly Group Meeting Times

Weekly Group Meeting Times Monday
3:30pm - 4:30pm
2:00pm - 3:30pm

Weekly Schedule

Week 1(Oct 22-28)

  • Team: Design database schemas for keys, people, and rooms
  • James: Work with Arduino and sensors
    • Refamiliarize with Arduino development
    • Wire LDR (and PIR upon arrival) to Arduino
    • Determine threshold values of LIGHTS_ON, LIGHTS_OFF, LIGHTS_DIM, MOTION, NO_MOTION for sensors through testing
    • Write code to perform abstraction from raw sensor values to Occupied, Presentation, or Not_Occupied states for a room.
    • Learn how to make HTTP request using Arduino Ethernet shield to a simple PHP test script listening on local server
  • Shiwangee: Learn basics of developing for Android and develop database schema for keys, people and room
    • Familiarize with the Android interface and setup the development environment.
    • Create the database schemas for keys, people and room. The database will be created based on the team discussion.
    • Fill out test values in the newly created tables. Test data will be used till we get the actual data from sensors. Ensure that test data contains the boundary condition data for correct testing.

Week 2(Oct 29-Nov 4)

  • James: Develop servlet for room status requests
    • Familiarize self with Tomcat setup and servlet deployment
    • Create servlet to handle data posting from sensor(s) to database and retrieving the current room status
    • Test servlet with actual sensor(posting data) and simple request from test Android app or webpage.
  • Shiwangee: Develop servlet to get key and person data
    • Information will be manually provided to servlet until key and person sensors are ready.
    • Set up Tomcat and create the server profile and configure the application settings.
    • Design a framework to interact with database and fetch the data.
    • Also begin development of server-side application to process input from all sensors to determine missing keys

Week 3(Nov 5-11)

  • James: Develop Android application
    • Retrieve and visualize room status information from server
    • Test and debug entire room status module
  • Shiwangee: Extend server-side application to send alerts for missing keys through either email or SMS.
    • Complete the servlet logic to determine the missing keys.
    • Use Java APIs to send SMS or email to the person concerned . For SMS we may need GSM modem directly connected to the server PC. We will investigate on this further.
    • Unit testing and debugging of Missing key and send Message module.

Week 4(Nov 12-18)

  • Team: Begin system integration
  • James: Continued testing of the room status module
  • Shiwangee: Create Android interface to view status of keys.
    • Design and implement the Android interface to show information regarding the missing key.
    • Continue testing and debugging.

Week 5(Nov 19-25)

  • Team: System integration, testing, and debugging

Week 6(Nov 26-Dec 2)

  • Team: Prepare final report, final demo, and perform last-minute debugging


Server-side modules will be implemented using Java servlet and other Java APIs. A framework will be developed for interaction with the database. Whenever a request is raised about the missing keys, the database will be checked whether the respective room is occupied or not through sensor reading. If the room is not occupied and the key is not on its place, then an alert will be raised for the person who has taken the key and an update will be sent for the person who raised the request. If the room is occupied then it is fine as it is assumed that room is occupied and open. We will keep the time limit of 15 minutes. Alerts will be generated at interval of 15 minutes until either of the conditions of room occupancy or key return has met.Alert will be in form of mail/sms based on user preference. The alerts will be sent using JAVA APIs. See Fig. 2 for the key tracking and alert server-side application logic flow upon a key being taken.

The Arduino code will be implemented using the Arduino programming language, which is a C-style language based upon Wiring. The sensor module will take room readings at a given interval T and report the current status to the server at an interval S where S > T.

The Android applications will be implemented using Android Java. The applications will simply visualize the current status for keys or rooms based on what is returned from the server. See Fig. 3 for the room sensor module logic connecting sensor readings to abstractions of the room occupancy. “MOTION” or “NO_MOTION” will be the primary occupancy indicator while “LIGHT” will be a secondary indicator for what is happening in the room.

Figure 2: Flowchart for server application logic
Figure 3: Graph for room status sensor


For the room occupancy module, the produced results will be evaluated by producing all possible combinations of the left-side items in Fig. 3 and observing if the output produced corresponds to the correct result on the right side of Fig. 3. There are six possible possible combinations as each of the 3 “LIGHT” items can be paired with either of the “MOTION” items. The key tracking and alert module will be evaluated against the following cases:
Case 1:

  1. Say person A has taken key X at time P
  2. Wait ΔT=15 mins (buffer time given to the person for action who has taken key within this time limit)
  3. Check for room occupancy(Y/N): N
  4. Check key X availability(Y/N):N
  5. Send alert to person A
  6. Wait ΔT again
  7. Check for room occupancy(Y/N): Y
  8. Wait ΔT again
  9. Check for room occupancy(Y/N): N
  10. Check key X availability(Y/N):N
  11. Send alert to person A
  12. Wait ΔT again
  13. Check for room occupancy(Y/N): N
  14. Check key X availability(Y/N):Y
  15. Terminate

Case 2:

  1. Say person B has taken key Y at time Q
  2. Wait ΔT=15 mins
  3. Check room occupancy: Yes
  4. Wait ΔT
  5. Check room occupancy: No
  6. Check key Y returned: Yes
  7. Terminate

Case 3:

  1. Say person C has taken key Y at time J
  2. Wait ΔT=15 mins
  3. Check room occupancy: No
  4. Check key Y returned: Yes
  5. Terminate