Using Tagus-SensorNet for Surveillance

Project Details:

Goal: The Tagus-SensorNet Platform runs multiple applications for differentiated purposes. These apps peacefully co-exist within the network thanks to the use of shared libraries, both in the sensor nodes and on the central computer.

This project aims to develop another application, preferably extending the functionality of the already existing environmental interaction application, so that surveillance routines can be carried out. Surveillance functions such as detecting the presence of people or even counting their number are among the features we are seeking to add to the existing app's functionality. The project will use sensor boards equipped with PIR detectors as sensing devices.

Assigned to: Ricardo Pinto

Project Website: Tagus-SensorNet Surveillance

Goals

Develop a driver for the PIR sensor.
Extend the functionality of the existing environmental application to support surveillance routines.

Planning

Learn Nesc and TinyOS architecture. (13th May - 20th May) - done
Understand environmental application source code. (20th May - 30th June) - done
Read PIR and MDA300 datasheet (1st July - 3rd July) - done
Project the circuit that connects the PIR and the MDA300. (4th July - 5th July) - done
Implement PIR driver with MDA300 board. (6th July - 9th July) - done
Driver debugging and testing. (10th July) - done
Plan the new application architecture to support surveillance routines. (11th July - 15th July) - done
Implement the new architecture. (20th August - 5th September) - done
Integration tests. (6th September - 8th September) - done

How a PIR sensor works

Pyroelectric Infrared sensor (PIR sensor) is an electronic device that measures infrared (IR) radiating from objects in its field of view. The pyroelectric sensor is made of a crystalline material that generates a surface electric charge when exposed to heat in the form of infrared radiation. When the amount of radiation striking the crystal changes, the amount of charge also changes and can then be measured with a sensitive FET device built into the sensor. For example: a person entering a monitored area is detected when the infrared energy emitted from the intruder's body is focused by a Fresnel lens or a mirror segment and overlaps a section on the chip that had previously been looking at some much cooler part of the protected area.

Architecture

Hardware

Since the provided PIR sensor is a digital sensor (binary output), it means that either the output is high (3V), triggered by a heat source entering the sensor's detection range, or the output is low (0V), meaning that no heat source is detected.

The circuit was projected having the information above in mind. Both Vcc and Gnd of the MDA100 and the PIR sensor were connected, and the Output of the PIR sensor was connected to a digital port of the MDA100 (Int0).

PIR driver

An interruption-based driver was developed to access the sensor in TinyOS:

Note: Triangles are interfaces. Triangles pointing out from a component are interfaces it uses, while triangles inside a component are interfaces it provides. A solid box is a module, while a dashed box is a configuration.

HplPirC - selects the appropriate hardware resources. PirP - executes driver logic. PirC - driver logic.

A generic component PirReadC was also implemented to provide the Read interface, although it was used only for testing purposes.

How to use: - Wire the PirC to your application. - To enable or disable the notification of values: Notify.enable() or Notify.disable() respectively. - Implement the function: Notify.notify(bool val) and process the information.

Environmental Interaction

Environmental Interaction changes

The Environmental Interaction application was already developed and it was coded based on sample and read sensors. This project's objective was to change the application and adapt it to support interruption driven sensors, in particular a PIR sensor. The configuration messages sent from the original application contain the following structure:

typedef struct UnicastConfigMsg {

    uint8_t numSensorReadings;                                        // Number of sensor readings to configure.
    SensorReadingConfiguration SensorReadings[0];    // List of sensor reading configurations.
    ...

}

typedef struct SensorReadingConfiguration {

    uint8_t sensorType;    // Identifies which sensor to read.
    uint32_t samplePeriod; // Specifies the sampling period for this reading.
    uint8_t outputTag;     // Identifies which tag to associate the data with.

}

Using the same message structure has some advantages over changing it and adding more complexity:

transmission efficiency: the transmitted data is the same.
power saving: less time transmitting means more power left.
retro compatibility with older versions: if the configuration message changed, motes with previous version of the application wouldn't be able to process the new configuration message, which means that they their functionality couldn't be reconfigured.

Therefore the original message structure was maintained, and to distinguish the sample-based sensors from the interruption-based ones, the variable samplePeriod was used. If the variable is set to 0, then it indicates that the sensor is interrupt-driven, if it's bigger than 0, then it's a sample and read sensor with the sample period set in the samplePeriod variable.

The PirC was wired in the Environmental Interaction application and the java interface was changed to support the Pir sensor.

Tests

The test methodology was incremental.

After developing the PIR driver, the correct functioning of the sensor was tested using the mote's leds. If the led was on it would indicate that a heat source was detected, if it was off, no detection was made.

Mote with red led on.

Mote with red led off.

The time that takes the Pir sensor to switch from a positive detection to a no-detection was also measured, and is approximately 10 seconds:

Then the integration with the Environmental Interaction was done using the PirReadC interface, that is similar to the interface of the other sensors already present and tested in the application.

Java interface with PIR value = 1.

Java interface with PIR value = 0.

Later the Notify interface of the PirC component was tested and used to process the output of the Pir sensor as events.

Video

http://www.youtube.com/watch?v=kSS__Y7-00I

Resources

Developer

Ricardo Pinto (ricardo.pinto AT tagus.ist.utl.pt)

Print
Homepage Research Projects People Photos & Media Education Resources Links Contact Login	Using Tagus-SensorNet for Surveillance Project Details: Goal: The Tagus-SensorNet Platform runs multiple applications for differentiated purposes. These apps peacefully co-exist within the network thanks to the use of shared libraries, both in the sensor nodes and on the central computer. This project aims to develop another application, preferably extending the functionality of the already existing environmental interaction application, so that surveillance routines can be carried out. Surveillance functions such as detecting the presence of people or even counting their number are among the features we are seeking to add to the existing app's functionality. The project will use sensor boards equipped with PIR detectors as sensing devices. Assigned to: Ricardo Pinto Project Website: Tagus-SensorNet Surveillance Goals Develop a driver for the PIR sensor. Extend the functionality of the existing environmental application to support surveillance routines. Planning Learn Nesc and TinyOS architecture. (13th May - 20th May) - done Understand environmental application source code. (20th May - 30th June) - done Read PIR and MDA300 datasheet (1st July - 3rd July) - done Project the circuit that connects the PIR and the MDA300. (4th July - 5th July) - done Implement PIR driver with MDA300 board. (6th July - 9th July) - done Driver debugging and testing. (10th July) - done Plan the new application architecture to support surveillance routines. (11th July - 15th July) - done Implement the new architecture. (20th August - 5th September) - done Integration tests. (6th September - 8th September) - done How a PIR sensor works Pyroelectric Infrared sensor (PIR sensor) is an electronic device that measures infrared (IR) radiating from objects in its field of view. The pyroelectric sensor is made of a crystalline material that generates a surface electric charge when exposed to heat in the form of infrared radiation. When the amount of radiation striking the crystal changes, the amount of charge also changes and can then be measured with a sensitive FET device built into the sensor. For example: a person entering a monitored area is detected when the infrared energy emitted from the intruder's body is focused by a Fresnel lens or a mirror segment and overlaps a section on the chip that had previously been looking at some much cooler part of the protected area. Architecture Hardware Since the provided PIR sensor is a digital sensor (binary output), it means that either the output is high (3V), triggered by a heat source entering the sensor's detection range, or the output is low (0V), meaning that no heat source is detected. The circuit was projected having the information above in mind. Both Vcc and Gnd of the MDA100 and the PIR sensor were connected, and the Output of the PIR sensor was connected to a digital port of the MDA100 (Int0). PIR driver An interruption-based driver was developed to access the sensor in TinyOS: Note: Triangles are interfaces. Triangles pointing out from a component are interfaces it uses, while triangles inside a component are interfaces it provides. A solid box is a module, while a dashed box is a configuration. HplPirC - selects the appropriate hardware resources. PirP - executes driver logic. PirC - driver logic. A generic component PirReadC was also implemented to provide the Read interface, although it was used only for testing purposes. How to use: - Wire the PirC to your application. - To enable or disable the notification of values: Notify.enable() or Notify.disable() respectively. - Implement the function: Notify.notify(bool val) and process the information. Environmental Interaction Environmental Interaction changes The Environmental Interaction application was already developed and it was coded based on sample and read sensors. This project's objective was to change the application and adapt it to support interruption driven sensors, in particular a PIR sensor. The configuration messages sent from the original application contain the following structure: typedef struct UnicastConfigMsg { uint8_t numSensorReadings; // Number of sensor readings to configure. SensorReadingConfiguration SensorReadings[0]; // List of sensor reading configurations. ... } typedef struct SensorReadingConfiguration { uint8_t sensorType; // Identifies which sensor to read. uint32_t samplePeriod; // Specifies the sampling period for this reading. uint8_t outputTag; // Identifies which tag to associate the data with. } Using the same message structure has some advantages over changing it and adding more complexity: transmission efficiency: the transmitted data is the same. power saving: less time transmitting means more power left. retro compatibility with older versions: if the configuration message changed, motes with previous version of the application wouldn't be able to process the new configuration message, which means that they their functionality couldn't be reconfigured. Therefore the original message structure was maintained, and to distinguish the sample-based sensors from the interruption-based ones, the variable samplePeriod was used. If the variable is set to 0, then it indicates that the sensor is interrupt-driven, if it's bigger than 0, then it's a sample and read sensor with the sample period set in the samplePeriod variable. The PirC was wired in the Environmental Interaction application and the java interface was changed to support the Pir sensor. Tests The test methodology was incremental. After developing the PIR driver, the correct functioning of the sensor was tested using the mote's leds. If the led was on it would indicate that a heat source was detected, if it was off, no detection was made. Mote with red led on. Mote with red led off. The time that takes the Pir sensor to switch from a positive detection to a no-detection was also measured, and is approximately 10 seconds: Then the integration with the Environmental Interaction was done using the PirReadC interface, that is similar to the interface of the other sensors already present and tested in the application. Java interface with PIR value = 1. Java interface with PIR value = 0. Later the Notify interface of the PirC component was tested and used to process the output of the Pir sensor as events. Video http://www.youtube.com/watch?v=kSS__Y7-00I Resources TinyOS Micaz MDA100 MDA100 Datasheet Report Developer Ricardo Pinto (ricardo.pinto AT tagus.ist.utl.pt) Print
© 2024, LEMe & IT. All rights reserved.