Multiple Child Tracking System
May05-24
“Design Report”
Client:
Senior Design
Advisor:
Dr. Diane Rover
Team:
Benjamin Flessner CprE
Allan Hammell CprE
Iwin Lee CprE
Hua Shao EE
REPORT DISCLAIMER NOTICE
DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.
15 – December – 2004
Table of Contents
i. List of Tables ii
ii. List of Figures iii
iii. List of Definitions iv
1. Executive Summary 1
2. Introductory Material 4
2.1. Abstract 4
2.2. Acknowledgement 4
2.3. Problem Statement 4
2.4. Solution Approach Statement 4
2.5. Operating Environment 4
2.6. Intended Users and Uses 5
2.7. Assumptions 5
2.8. Limitations 5
2.9. Expected End Product and Documentation Deliverables 6
3. Approach Used 7
3.1. Design Objectives 7
3.2. Functional Requirements 8
3.3. Design Constraints 10
3.4. Technical Approach Considerations 10
3.5. Testing Approach Considerations 12
3.6. Project Continuation/Modification Recommendations 12
4. Detailed Design 13
4.1. Computations and Analysis to be Performed 13
4.2. Assumptions 15
4.3. Limitations 15
4.4. Communication Flow-Charts 15
4.5. List of Inputs 17
4.6. List of Outputs 17
4.7. User Interfaces 17
4.8. Testing Activities 18
5. Resources 19
5.1. Personnel Effort Requirements 19
5.2. Financial Requirements 20
6. Schedules 21
6.1. Project Schedule 21
7. Closure material 23
7.1. Client Information 23
7.2. Faculty Advisor Information 23
7.3. Student Team Information 23
7.4. Closing Summary 24
8. References 24
- List of Tables
Table 51 - Previous Personnel Effort Estimation 19
Table 52 - Revised Personnel Effort Estimation 19
Table 53 - Original Project Cost Estimates 20
Table 54 - Revised Project Cost 20
- List of Figures
Figure 11 - Visual Representation of Tracking System 1
Figure 31 Gotcha Child Safety Device 11
Figure 32 - Crossbow MOTEs - MICA2 and MICA2Dot 11
Figure 41 Base Module Communication Flowchart 15
Figure 42 Caretaker Module Communication Flowchart 16
Figure 43 Child Module Communication Flowchart 16
Figure 44 - MTS300 Sensor Board 18
Figure 61 - Previous Project Schedule – Major Tasks Only 21
Figure 62 - Revised Project Schedule – Major Tasks Only 21
Figure 63 - Previous Project Schedule - Detailed 22
Figure 64 - Revised Project Schedule - Detailed 22
- List of Definitions
Emulate – Virtual representation of a physical interface
MOTE – Small, self-contained, systems or boards containing both a microprocessor and a radio transceiver.
GPS – Global Positioning System
PDA – Personal Data Assistant – Small, handheld computer used to store data and run simple programs.
Simulate – Give the appearance of functionality without hardware interfaces
May05-24
Senior Design Page 1 12/15/2004
1. Executive Summary
Keeping track of children can sometimes be very difficult in today’s fast-paced world. Families with multiple children face an even tougher task especially on outings to parks or shopping malls. Not only must caretakers keep children close to them, they must also be on continual alert to any number of dangers such and that child falling into a back-yard pool or lake at a park. Developing a tracking system for caretakers with multiple children could greatly ease stress and allow them more freedom during excursions with their children.
Figure 11 - Visual Representation of Tracking System
There are currently very few products on the market that help parents keep track of their children. Some use GPS technology to report on a child’s whereabouts over large areas, but are not very useful in keeping children near a parent such as in a back-yard or in a store. One particular product, Gotcha®, does track children near a parent, but it also has some limitations. First, it only tracks children’s location; it doesn’t monitor other conditions that could cause a child to be in danger. Also, it centers the area of “acceptable proximity” around the caretaker. This may be fine for mobile scenarios, but if a caretaker wishes to, say, track children in a back-yard, they could easily set off false alarms by moving near the front of the house.
This project is designed to add functionality to systems like Gotcha®. The first way is in creating a base station. This base station would be separate from the caretaker module and could be placed in a back-yard or center of a campsite. Children would then need to stay within a specified range of the base station, while the parent is free to move around without changing the acceptable proximity area. This project also plans to add sensors to the child modules. A water sensor would detect if a child falls into a swimming pool or lake, and a temperature sensor could detect if a child is too close to a fire or has accidentally been left in a hot car with the windows rolled up.
The goal of this project is to create a working prototype of the multiple child tracking system. Small devices, called MOTEs, will act as modular pieces to the system. Each will be identical, but with different programming to turn them into either a base station, a caretaker module, or a child module. These prototypes would only be operated in a safe, lab-environment, but future projects could create housings and smaller components to be actually worn by children and be weatherproof.
Several options were considered for developing this system. Initally, the idea was to build each module from the ground-up: select a microprocessor and radio transmitter and create the circuits to make the system work together. Unfortunately, the time given for the project would not permit the low-level design of components as well as programming them to function properly. Another plan was writing programs for PDA that could use existing radio technology to track the locations of other PDA’s. This option was discarded for two main reasons. First, the current wireless cards available for PDAs have no way of measuring distances without completely re-writing firmware. External sensors, such as water and temperature would also have to be created from scratch in order to interface with the PDA. Again, the project team felt there was not enough time to complete a fully functional system.
One hopeful method of developing was modifying the existing Gotcha® tracker by adding a base station and water sensors. Early communication with National Scientific Corporation, creators of Gotcha® seemed promising, but as design time approached without further communication, an alternative had to be chosen.
In the end, Crossbow’s MOTEs were selected for use in this project. These MOTEs are very small devices that contain a microprocessor, radio transceiver, and simple sensors. What’s more: they were available in a laboratory at Iowa State University for use throughout the course of the design project. These MOTEs are a new and quickly-growing technology, and working with them gives the team members a special niche in the wireless communications market.
The base module will be the hub of all communication and do a majority of the computations associated with this system. The base will, one by one, “ping” each child module. It will time how much time passes before it receives a “ping response.” The longer a ping response takes the farther away the child module should be from the base module. If a ping response is not received within the set amount of time a second ping, that is different from the first, will be sent and the ping response that the base expects will be different as well. Making the messages unique will avoid any confusion from a ping response from the first ping being confused as the ping response for the second ping. The practice of a second ping reduces the probability of false alarms due to dropped messages.
When a child is in an alarmed state, for any reason, an “alarm” message will be sent to both the child and the caretaker modules. This child will remain in the alarmed state until an “all safe” message is received from the caretaker module.
The child module will have the ability to receive ping messages and send ping responses. It will sound an alarm if it finds itself to be in an alarmed state due to its sensors or if it is told it is in an alarmed state due to an alarm message. If it is due to sensors it will send a “danger” message to the base.
The caretaker module has the ability to receive alarm messages and to send all safe messages. When it receives an alarm message it sounds an alarm. It will have the ability to differentiate which child modules are in an alarmed state.
The system in general is designed to accommodate more than a billion (2^30) unique child identification numbers. Although at this given time each system will only have knowledge of 6 of these child identification numbers, this can drastically reduce the probability of errors due to two systems in a close proximity. The current design only will have danger messages that result from water and extreme heat, but has left many message assignments unassigned for future use to correspond to dangers detected by other sensors.
After the initial programming has been done on the devices, they must undergo testing to ensure their proper functionality. Testing will be done in two phases: basic functionality in a lab environment, and real-world-effects testing. The first phase tests that all functions of the system work. For example: moving a child module out of range of the base station should set off an alarm, and putting to water sensor “leads” into a glass of water should set off the water alarm. Real-world tests include testing to learn what obstructions do to the range and functionality of the system. Of course, with exposed, bare electronics, these tests will be limited. For example: rain’s effects cannot be tested because it would immediately destroy the MOTEs.
Several end-products will be produced from this design project. A minimum of four programmed MOTEs will represent a caretaker module, a base station, and two child modules to demonstrate differentiation between children. A water-detection circuit will also be created to interface with the MOTEs through a standard connector. User’s documentation and a technical/maintenance manual will also be produced.
The project began in September, 2004 and will continue on to completion in May, 2005. The project team hopes to create a fully-working prototype of the multiple child tracking system, gaining experience with the Crossbow MOTE technology and creating the building blocks for a product of great use to caretakers with multiple children to keep track of.
2. Introductory Material
The introductory material will consist of an abstract, problem statement, solution approach statement, operating environment, intended users and uses, assumptions, limitations, and expected end product and other deliverables sections.
2.1. Abstract
Keeping multiple children safe and accounted for can be a daunting task. When someone loses track of a child, even for a little while, anxiety levels rise greatly. This project will develop a device to be worn by a child that will monitor certain conditions and a device that will be used by the child’s caretaker to alert them if the child is possibly in danger due to the certain conditions. These devices could drastically reduce caretaker-stress and improve child-safety.
2.2. Acknowledgement
Technical specifications for Crossbow MOTEs were taken from Datasheets publicly available at http://www.xbow.com.
The project team wishes to thank Iowa State University’s Department of Electrical and Computer Engineering and Professor Daji Qiao for the temporary use of the Wireless Sensor Networks Lab in the development of this project.
2.3. Problem Statement
Current devices to track children are too limited in their functionality. While they may detect a child that has wandered away too far from a parent, they do not alert the parent to other dangers, such as a child falling into water or being left in a hot car.
2.4. Solution Approach Statement
The team will create an expandable system that will be portable enough to travel with a family, yet versatile enough to alert to different dangers to children. A stationary base unit will communicate with multiple child units and warn a caretaker unit if one of the children is out of range or in danger.
2.5. Operating Environment
Although further elaborations of this product will be expected to operate in an indoor or outdoor environment where conditions such as rain, water, snow could be present, the prototype that will be delivered in this elaboration will be used indoors in a laboratory setting. It will operate within a normal range of temperatures that could be described as “room temperature.”
The system will be expected to operate under interference from other systems running in the same frequency range.
2.6. Intended Users and Uses
The intended users will be caretakers who wish to monitor one or more children. The other users would be the children being monitored by the caretaker.
The system will be used to safeguard children from wandering too far away from a caretaker and encountering certain dangers, such as falling into water.
2.7. Assumptions
The following is a list of assumptions for the project.
2.7.1. The system should handle up to six children at one time.
2.7.2. The system can work indoors or outdoors.
2.7.3. The system should be able to handle additional caretaker modules.
2.8. Limitations
The following is a list of limitations for the project.