Outils pour utilisateurs

Outils du site


Panneau latéral

Accueil

Select other language :


Apprentissage

Enseignements

Enseignements Département Informatique SI5 et Master IFI

Enseignements Département Bâtiment Polytech'Nice

Autres Formations française et étrangère

Activités administratives, Ingénierie et Innovation Pédagogiques

Apprentissage Département Informatique SI5/Master 2 ingénierie informatique EUR DS4H


Recherche

Valorisation de la Recherche

Dépôts Logiciels à l’Agence de Protection des Programme (APP)

Valorisation des résultats de recherche et transfert

Diffusion de la Culture scientifique et Technologique

Communications de presse

Séminaire ENSI Tunis

Pédagogie Innovante

Relations industrielles et socio-économique

Organisation de Manifestations

  • Conférence sur les FabLabs, Alexandre Schneider, Professeur Agrégé en Génie Mécanique, Université de Reims Champagne-Ardenne Web
  • Journées UbiMob'14 Site Web

Animation de la Recherche

U-Santé

Privé

Outils

Sources d'Informations

projets:oc:oc_2013_2014:ubiquidouche

Smart Objects and Services

Project Presentation

Name :

Ubiquidouche

Group Composition :

BOURSIER Alexandre

CACCIUTTOLO Olivier

MARIE Aurélien

Scenario :

- Jean enters the shower and opens the water

- When the water flow and temperature become constant shower head detects an early shower and requests to retrieve a target profile. Also a timer is started in order to deduce the average time at the end of shower.

- In the shower, the shower head measures the temperature at regular intervals in order to make an average temperature “Instant”.

- John turns off the water and get out of the shower

- When zero water flow for a specified time, the timer knob stops and starts an event “end of shower” over the network

- A server provides the information received in connection with the services being contacted (agenda, weather service ..).

- A friendly health service analyzes the data collection through a csv file.

Object Shape :

Name of the contact at Reims :

BELGIOINO Maxime

Sketch of the Object from Reims :
Picture of the Object without instruments and electronics :
Picture of the Object with instruments and electronics outside on the same table (put some circles and arrows on the picture to show where you're going to integrate all of these) :

https://drive.google.com/file/d/0B4GQO5e_oFeKdjRvUGJuZnE4Skk/edit?usp=sharing The sensors were not integretated in the object because they had to be outside it so we did not put it in the picture.

Picture of the finished Object (all is integrated):
Demonstration Video :

Hardware specifications :

List :

Specifications and interface of the service on the object

The service on the object is connected through UpNp protocol. When the user take a shower for a certain time the bean sends informations throught UPnP Probe Event. The informations inside this event are :

the duration of the shower,

the average temperature,

the date and time of the beginning of the shower

The water flow sensor use a combination of timers to detect a beginning of the shower and also the end of the shower. The temperature sensors controls the leds comparing its value with a reference that can be changed : under 20 °C the yellow led shines but above it will be the red led that shines.

https://docs.google.com/file/d/0B4GQO5e_oFeKT2g3NFJsbGpqMlk/edit

Specifications of the interface of high added value service

Note : (including a figure on the orchestration between services on objects and information systems)

The high added value service is connected to an UPnP proxy. When the service has received the three informations, it first writes them in a text file. Then the service converts the informations in JSON format. Then it makes a call to a weather service, a humidity service and a calendar service. All informations collected through those services are written in a CSV file.

You can see the data received by the service in C:\ubi\ubi_records.data (open with a text editor like notepad++). The CSV file is also in C:\ubi.

https://docs.google.com/file/d/0B4GQO5e_oFeKWkY2U1laS3dpZ1E/edit

Project Files:

. wcc of the two containers (embedded and on the remote PC) :
Beans added for the embedded container (for the service on the object) ** (DLL and Source code for each of them)
Beans added for the remote PC container (for the high added value service on the PC) ** (DLL and Source code for each of them)
Chesklist to install the embedded service on the object

- Download the bean of the embedded service

- Connect the phidget to your PC and put the bean on the Phidget card

- You can execute it with the 'mono' command trough putty or make a script that launch automatically the mono command

#Informations for automatic launch on the phidget

The automatic instantiation of the container operates through the execution of a script runned at the kernel startup, which is located in “init.d”. This is a copy of a simple skeleton script running during multiuser tasks and not during the start / stop of the current system (ordering a such service execution according to task priorities of a preemptive system). He then execute the 'mono' command for the instantiation of the container and the establishment of a service which can be discovered through the network.

This script has been modified on the fly with FTP, that's why we currently don't have it (he is stored on the card)

Chesklist to install the remote service/application on the PC

- Download ubi.zip https://docs.google.com/file/d/0B4GQO5e_oFeKb3cyOFFqWU55eWM/edit

- Uncompress it and put it at the root of your C hard disk

- Open UbiHLContainer in SharpDevelop

- Plug the phidget

- If the UPnP proxy doesn't show green after a while, either the embedded service hasn't been launcched or the address of the UPnP proxy is bad. You can verify the address with DeviceSPy.

- When the UPnP signal is green, you can blow through the water flow sensor.

- The service will automatically write the desired files.

Results of the relations with Reims (being factual without personal opinion)

In the beginning the relations worked fine. The contact seemed to understand our expectations. at the beginning there was a real exchange on both sides.

However, thereafter, the design has often been conducted unilaterally. When we asked for a picture of our modeled object, only the showerhead itself was shown to us. Then the surprise was to see that he was part of a complete wall bracket. The contact imposed his choices to us, explaining a lack of time on his side. We understand that time is an important factor, but a communication as its design steps were going on would have been welcome.

Finally, the modeling that was sent to us didn't really looked like the object that we received.

We regret that the assembly takes hardly even glued as indicated in the instructions. In addition, it is difficult to keep our object vertically.

Prospects :

Possible extensions of the object

We don't get the average water flow. The values returned by the sensor seem random. For a future implementation, it would be great to get a significative value. Then we would be able to give information about the average consumption of water.

We could also add a accelerometer. Then we would be able to tell if the user take the showerhead in hand or let it on the wall. It might be relevant of his mood.

Possible extension of the service on the Object

If we get a correct water flow value, we could give the average consumption by shower. We could also connect this service to others outside the bathroom to know if someone, or something, interrupt a shower. By this way, the user wouldn't have spend as much time as he would like and might get frustrated.

Possible extension of the high added value Service

Possible extension is a more services called to get more informations. For example, you could call like an electric service to calculate how much cost you a shower. A tenant might be interessed in that information to control his spendings.

Possible GUI for data visualization

There could be a dashboard in the bathroom were informations from the other services would be displayed. The dashboard would get turned on at the end of the shower with the evend send by the embedded service. Also we could give him a graph like produced in the CSV, even if a doctor would be more interesseted than the user himself. From this dashboard, he could consult a historic od the datas and also send it to his doctor.

projets/oc/oc_2013_2014/ubiquidouche.txt · Dernière modification: 2014/02/19 20:58 par etudiant_oc_2013_2014