Vision

WIN (github.com/AmI-2015/WIN)

Deliverable 1

Vision

How many times did you go to the toilet and once there you found out it was out of service? How long did you wait to enter because of an endless queue and you did not know that a little further on there was a nearly empty toilet?

Our goal is to help you so that this will not happen again!

With WIN every student inside the university will be able to:

• check in real time whether the toilet you are going to is in service or not;
• know the current or average waiting time in queue for the toilet and how many people are there;
• know if there are other toilets nearby where there are no people waiting in queue, so you can choose the best one for you.

A visible indicator, like a light, will inform you about the toilet status and a mobile-friendly interface will inform you about what is going on in the toilets.

Finally, the cleaning staff can let students know when a specific restroom is not available, so that they will be able to work more smoothly.

AmI Main Steps

AmI Step	Description
Sensing	Detection of students entering the toilet (and availability of toilets: out of order/closed).
Reasoning	Understand how many students are waiting for using the toilet and estimation of queue time.
Acting	Web-based graphical user interface, light indicator and information monitor outside the toilet.
Interacting	Web-based graphical user interface and implicit interaction between students and the toilet.

AmI Features

AmI Feature	Description
Sensitive	The system can sense the number of occupants of an environment.
Responsive	According to user needs, the system can provide information about how many people are inside each restroom, which is the less crowded, when a toilet is out of service or closed because of cleaning.
Adaptive	The system is able to adapt to the context (number of people, closed restrooms).
Transparent	User will not have any problem with WIN, since it does not require anything from the end user.
Ubiquitous	Thanks to a web server, users can have access to information everywhere from any device provided with Internet connectivity (e.g. laptop, smartphone).
Intelligent	The system can estimate the waiting time for using toilets and provide users information about the less crowded and closest restroom.

Close Doc

System Requirements

Deliverable 2

Purpose and Scope

Our goal is to offer students a way to know which is the nearest and less crowded restroom.

In order to do that we aim to know how many people are inside each restroom. In this way we are able to give students significant statistics.

Actors

The users of the system are all people inside university, mainly students.

Glossary

User

a student

Restroom

a public lavatory with sinks and toilets located in universities

Toilet

a WC inside a Restroom.

Opened/Closed

States if the whole restroom is available to users or not

Point of interest

A specific location inside Politecnico (e.g. classrooms, bars) well known by users.

Functional Requirements

Area 1: Queue

1. The user must be able to know where is the less crowded and closest restroom. (1)*
2. The user must be able to know how many people are in the restroom. (1)*
3. The user must be able to know how much time, in average, he has to wait for using the toilet. (2)*

Area 2: Service

1. The user must be able to know whether the restroom is opened or closed. (2)*

Area 3: User Interface

1. The user must select where he wants to find a restroom from a list of points of interest. (1)*
2. The user must choose a sex to filter available restrooms. (1)*
3. Each restroom must provide information to users about its status. (2)*
4. Each restroom should provide information to users about the closest restrooms. (3)*

Area 4: Cleaning staff interaction

1. Each restroom switch is used to change restroom status (opened/closed). (2)*
2. The switch must provide visual feedback to the cleaning staff about restroom status. (3)*

Area 5: Sensors

1. Each restroom entrance is equipped with a bi-directional people counter sensor which counts how many people enter or exit. (1)*
2. In each restroom there is a switch usable only by the cleaning staff. (2)*

(*) The number in parentheses means the priority level of each requirement. The priority range goes from 1 (max priority) to 5 (min priority).

Non-Functional Requirements

1. The web-based graphical user interface must be accessible from any device provided with Internet connectivity (e.g. laptop, smartphone).
2. The web interface will be compatible with browsers IE9+, Firefox 30+, Safari 6+, Chrome 34+, Opera 20+.
3. The web interface will be responsive, and will adapt to screen resolutions from 480x320 to 1920x1080.
4. The system is available in English language
5. The system should work, in reduced conditions, even if the local system of a restroom breaks.
6. Data computed by the system must be stored persistently.
7. The system guarantees user privacy.
8. The system should be user-friendly.

Close Doc

System Architecture

Deliverable 3

1. System Architecture

1.1 HW Architecture

Computational nodes:

• Central server (data storage, web UI provider, intelligence):
  • Anywhere in the web, always-on system.
• Local gateway (Raspberry Pi) for integrating sensor data
• one for each restroom

Devices:

• Video camera above the main entrance of each restroom to analyse people’s flow thanks to a dedicated software.

User interface devices:

• Monitors (which give to the user useful information about the status of restrooms):
  • one monitor outside each restroom.
• Color-changing lighting system (which give to the user useful information about the status of restrooms):
  • one lighting system outside each restroom.
• Switch that allows the cleaning staff to set the availability of a specific restroom:
  • one inside each restroom.

1.2 SW Architecture

• Sensor data collection software (on local gateway):
  • Processes and sends data to central server (FR 5.1, FR 5.2).
• Software for counting how many people are in the restroom (on central server) (FR 5.1)
• Web Application (on central server):
  • Provides the user information about restrooms. (FR 1.1)
  • User can find nearby restrooms by choosing a point of interest. (FR 1.2)
  • Analytics and Statistics. (FR 1.3)
• Data Storage (on central server):
  • Store data for each restroom. (NFR 6)
• Intelligent Core (on central server):
  • Analyses data and provides information to users (FR Area 1).
• Graphical server for the monitor (runned by OS on local gateway). (FR 3.3, FR 3.4)

1.3 Network Architecture

• Local gateway (Raspberry Pi) in each restroom, connected via LAN to the Internet.
• Central server: world-accessible public IP address.
• Video camera connected to the Internet.
• Switch connected to the local gateway via wires.
• Monitors connected to local gateway.

2. Selected components

2.1 Hardware components

2.1.1 Off-the-Shelf

• Raspberry Pi board
• Video camera
• Monitor (size from 15’ to 24’)
• Color-changing lighting system (two Leds)
• Switch for cleaning staff

2.2 Software components

• Linux OS running on central server (Ubuntu).
• Linux OS running on Raspberry Pi (Raspbian).
• Web server (Flask)
• DB server (MySQL)
• Video recognition/Computer vision for video camera

Close Doc

Presentation Slide

Close Doc

Presentation Video

Close Doc