surveillance robot - ua home robot project design ... abstract (nathaniel) this project attempts to...

Surveillance Robot Project Design Report

Design Team 09

Andrew Biddinger

Nathaniel Fargo

Megel Troupe

Roger Zhang

Faculty Advisor: Igor Tsukerman

Senior Design Coordinator: Gregory A. Lewis

Date 11.15.2012

i

Table of Contents

Problem Statement .............................................................................................................. 1

Abstract (Nathaniel) ............................................................................................................ 1

Need (Roger) ................................................................................................................... 1

Objective (Nathaniel) ...................................................................................................... 1

Background (Megel) ....................................................................................................... 2

Patent Search (Megel) ..................................................................................................... 3

IEEE Explorer Article Search (Megel) ........................................................................... 3

Other Sources (Megel) .................................................................................................... 3

Marketing Requirements (Andrew) ................................................................................ 4

Objective Tree (Nathaniel) .............................................................................................. 6

Design Requirements Specification (Nathaniel, Megel, Andrew, Roger) .......................... 7

Accepted Technical Design ................................................................................................ 9

Hardware: ........................................................................................................................ 9

Software: ....................................................................................................................... 21

Movement Algorithm (Andrew) ................................................................................... 26

Motor Movement and Corrections (Andrew) ................................................................ 29

Software Pseudo Code (Andrew, Nate) ........................................................................ 30

Configurable User Parameters (Andrew) ...................................................................... 33

Software Testing (Andrew) ............................................................................................... 33

Sensor Data Collection Testing (Andrew) .................................................................... 33

Locomotive Testing (Andrew) ...................................................................................... 34

Warning Testing (Andrew) ........................................................................................... 34

Approximate Robot layout design .................................................................................... 35

ii

Engineering Calculations .................................................................................................. 35

18650 Lithium Battery Pack (12V Li Ion Batteries): ....................................................... 49

Parts List ........................................................................................................................... 52

FOSCAM WI-FI Camera: ............................................................................................. 53

Electret Microphone ...................................................................................................... 54

Explorer 16 Demo Board .............................................................................................. 57

MQ7 Carbon Monoxide & Flammable Gas Sensor ...................................................... 59

Parallax 3-Axis 250 / 500 / 2000° / s Gyroscope Module ............................................. 63

PING))) Ultrasonic Sensor ............................................................................................ 66

PIR Sensor: .................................................................................................................... 69

Wi-Fi Radio Transceiver ............................................................................................... 72

UV TRON Flame Sensor .............................................................................................. 75

Electronics Power Supply and E-Stop: ......................................................................... 78

Project Schedules .............................................................................................................. 80

Fall Gantt Chart ............................................................................................................. 80

Spring Gantt Chart ........................................................................................................ 84

Design Team Information ................................................................................................. 85

Conclusion and Recommendations ................................................................................... 87

References ......................................................................................................................... 88

iii

List of Figures

Figure 1: Objective Tree 6

Figure 2: Hardware Block Diagram Level 0 9



Figure 5: Electronics Schematic 1 18

Figure 6: Electronics Schematic 2 19

Figure 7: Microcontroller Pin Diagram 20

Figure 8: Software Block Diagram Level 0 21



Figure 11: State Machine State Diagram 26

Figure 12: Robot Placed 28

Figure 13: Invisible Grid Initialized 28

Figure 14: Mechanical Layout 35

Figure 15: 24V Motor 39

Figure 16: Encoder Pins 39

Figure 17: Encoder Pin Descriptions 39

Figure 18: Wheel Dynamics 41

Figure 19: Mixed Mode 44

Figure 20: Exponential Response 44

Figure 21: 4x Sensitivity 45

Figure 22: Pulse Width Modulated Signal 46

Figure 23: Motor System Closed Loop Configuration 47

Figure 24: Schematic of motor drive train 48

iv

Figure 25: 18650 Lithium Battery Pack 49

Figure 26: FOSCAM Camera 53

Figure 27: Electret Microphone 54

Figure 28: Amplitude Response of Microphone 54

Figure 29: Microphone Example Circuit 55

Figure 30: Explorer 16 Board 57

Figure 32: Explorer 16 Pin Diagram 58

Figure 32: Carbon Monoxide Sensor 59

Figure 33: Carbon Monoxide Sensor Parameters 60

Figure 34: CO sensor pin Diagram 60

Figure 35: CO monoxide sensor output waveform 61

Figure 36: Gyroscope 63

Figure 37: Gyroscope Pin Diagram 64

Figure 38: Gyroscope Pin Description 65

Figure 39: Ping Sensor 66

Figure 40: Ping Sensor Pin Diagram and Output Waveform 68

Figure 41: PIR Sensor 69

Figure 42: PIR Sensor Pin Descriptions 69

Figure 43:PIR Sensor Pins 70

Figure 44: WI-FI Transceiver 72

Figure 45: Transceiver Pin Diagram 73

Figure 47: UV TRON Flame Sensor 75

Figure 47: UV Tron Pin Diagram and Suggested Setup 76

Figure 48: On Off Switch 78

Figure 49: 5V Relay 79

v

Figure 50: Fall Gantt Chart 83

vi

List of Tables

Table 1: Design Requirement Specification ....................................................................... 7

Table 2: Hardware Level 0 Functional Requirements Table .............................................. 9

Table 3: Power Block Functional Requirements Table .................................................... 10

Table 4: Sensor Functional Requirments Table ................................................................ 11

Table 5: Processor Functional Requirements Table ......................................................... 11

Table 6: Motor Functional Requirements Table ............................................................... 11

Table 7: Transceiver Functional Requirements Table ...................................................... 12

Table 8: Electronics Power Source Functional Requirements Table ................................ 14

Table 9: Motor Power Source Functional Requirements Table ........................................ 14

Table 10: Controller Functional Requirements Table ...................................................... 14

Table 11: Sensors Functional Requirements Table .......................................................... 15

Table 12: Transceivers Functional Requirements Table .................................................. 15

Table 13: Motors Functional Requirements Table ........................................................... 15

Table 14: Motor Drivers Functional Requirements Table ................................................ 16

Table 15: Software Level 0 Functional Requirements Table ........................................... 21

Table 16: Sensor I/O Software Functional Requirements Table ...................................... 22

Table 17: Locomotive Software Functional Requirements Table .................................... 23

Table 18: Warning Module Software Functional Requirements Table ............................ 23

Table 19: State Machine Software Functional Requirements Table ................................ 23

Table 20: Sensor I/O: Interrupt Service Routines ............................................................. 24

Table 21: Finite State Machine ......................................................................................... 24

Table 22: Locomotive: Move Function ............................................................................ 25

Table 23: Warning: SendEmail Function ......................................................................... 25

vii

Table 24: Warning: SendText Function ............................................................................ 25

Table 25: Configurable User Parameters .......................................................................... 33

Table 26: Driver motor input specifications ..................................................................... 37

Table 27: Driver Motor Output Calculated Values ........................................................... 38

Table 28: Motor Characteristics ........................................................................................ 38

Table 29: Worst Case Electronics Power Calculations ..................................................... 51

Table 30: Parts List ........................................................................................................... 52

1

Problem Statement

Abstract (Nathaniel)

This project attempts to address the need for a self-contained home security system.

Currently, home security systems require many costly components and a complicated

installation process. Two basic types of systems are currently available. The first is a

wired system. One drawback is that installation of a wired system can take a lot of time

and money. Another drawback is that it is a permanent part of the home. If the owner

moves, the security system must stay. The second type of system is a wireless one. The

components for this are also costly. Wireless systems are more mobile, but they require

batteries which must be changed every so often. The purpose of the proposed system will

be to eliminate the drawbacks of both wired and wireless systems. The proposed system

will consist of a single unit, which will monitor the home for various hazardous

conditions and provide video feedback via a web interface.

Need (Roger)

A burglary is committed every 10 seconds in the United States. This adds up to nearly 13

million homes that are burglarized each year, with an average loss of $1,300 worth of

property. According to the National Fire Protection Association, property crime makes up

approximately three-quarters of all crime in the United States. Based on 2009 FBI

Uniform Crime Reports, of all cities with populations between 250,000 and 499,999,

Cleveland is ranked number 2 in burglary rates, with 21.5 burglaries per 1000 people. In

addition, installations of home security systems require a professional to setup. This can

make setting up a security system a hassle for many people. Based on this, there is an

unquestionable need for an affordable standalone residential home surveillance system

that can be easily installed.

Objective (Nathaniel)

The objective of this project is to design a prototype home surveillance system that will

require minimal installation, while offering more comprehensive monitoring of the

average home. It will be more complete and user friendly than most of the surveillance

systems presently on the market. Home monitoring will be realized by a standalone

2

robotic unit. This robot will provide monitoring for no less than 8 hours, and interact

with its user by transmitting real-time video footage and text data.

Background (Megel)

Over the last five years, the number of homes with home security systems has jumped by

nearly 40%. Today, roughly one in six homeowners have invested in electronic

protection. However, a high percentage of these homeowners are dissatisfied, or require

more from their service providers. High cost and poor customer service are the more

frequent reasons many consumers give as their reason for their dissatisfaction. These

reasons are also ironically the same reasons potential customers give for not getting a

home security system. A hard wired surveillance system typically cost between $90 to

$130 for each entry point (doorway or window) and $110 to $130 for each motion sensor.

That can total thousands of dollars, depending on the size of the home. In addition, there

is also the monitoring cost, which can be just as expensive; typically about $20 to $50 a

month. The wireless systems are even more expensive.

In addition to cost there are also other limitations with the current available systems.

Wireless systems depend on batteries, which mean frequent battery checks and,

especially with larger systems, frequent battery changes. These systems don't have the

same range as wired systems. In a large home or apartment, the signal strength may not

be strong enough to reach every area, leaving portions of the home unmonitored. Also,

bad weather can interfere with the signal of these systems. Certain appliances in the home

that operate on radio frequency can also cause interference. Wireless systems are also

prone to remote hacking. Hard wired systems on the other hand, are best installed when

the home is being built to avoid major structural modifications later. For these systems

professional installation is necessary in most cases and may be expensive. If the family

wants to relocate, the wired systems are hard to remove and reinstall.

The basic theory behind the proposed concept is to build a standalone device that will be

a viable alternative to the conventional home security system. Such a system should be

easy to use, reliable, and affordable. The system will operate by using sensors to collect

3

data, which will be sent to a microcontroller which will a control a robot’s behavior. The

supporting research conducted is expressed in detail below.

Similarities of this system to the existing security systems lie in that both use sensor

technology to detect intrusions inside the home. Existing security systems however, use a

variety of sensors to detect the presence of an intruder. Some of the most commonly used

sensor systems include inertia sensors triggered by mechanical instability (opening of

door, window etc…) , magnetic field sensors (detect change in magnetic field between

two wires as a result of a body moving into the magnetic field’s vicinity), and passive

infrared sensors. The most commonly used type of sensor is the passive infrared sensor.

This system will most likely employ infrared sensors to detect distance and position.

Patent Search (Megel)

Patent No.7436143: Miniature Surveillance Robot [4] is very relevant to this project as it

shares a lot of the same concepts that we are hoping to implement. Among them is the

concept of a logic controller operating a drive motor to move a robot. This project also

includes inputs from various sensors such as proximity, sound, and chemical sensors to

make decisions as to where the robot moves to. These are consistent with the patent

claims #12 and #13. The surveillance robot should also be able to communicate

wirelessly with a network to store the camera footage captured, which is also consistent

with various claims of the patent.

IEEE Explorer Article Search (Megel)

Publication Number: US 2010/085946 [3] shows how to be able to program a robot or

override a robot. The idea is to be able to interact with the robot remotely. In this design

we are going to develop an interface to interact with the robot by programming it or

controlling it with certain functions. This will help the user to set up the robot easily and

efficiently. For part of the marketing requirements a GUI is the best way to setup a robot

easily. The idea of the GUI is to keep things simple with the design so the user can have

some control. If the costumer or user wants to expand the robot capabilities they can

update the interface for the robot’s plug-ins and add-ons.

Other Sources (Megel)

4

Currently there are basically two different types of home security systems. One of them is

a wired home security system and the other is a wireless home security system. The wired

home security system operates on an electric circuit in which all the sensors and cameras

are hard wired to the controlled unit. Once the alarm is turned on, the circuit will be

turned on. In case there are any types of interference, like the wires being cut or the

sensor is being triggered, then the alarm will be turned off.

As for the wireless system, it pretty much operates similar to the wired system, with the

exception of its sensors been linked to the control unit wirelessly. There are advantages

and disadvantages to each existing system as will be discussed below.

Presently, the wired system’s biggest limitation is its cost. Not everyone can afford this

because wired systems are quite expensive and they also require professional installation.

Because of this, only wealthy families can afford the installation of these wired security

systems. Also, wired systems are not very flexible because they require professional

installation. The wires need to run from the control panel to all the sensors and should be

placed in an aesthetically pleasing manner and should not be easily noticed. This can be

difficult if the building was not prewired to accommodate a home security system.

One of the notable disadvantages of the wireless systems is that they require the periodic

replacement of batteries. Additionally, they can be vulnerable to electromagnetic

interference in some particular locations. As for their security cameras, the wireless

systems fall short, since the cameras run on batteries. The batteries usually not last for an

entire day and would need to be charged or replaced often.

Marketing Requirements (Andrew)

1. The robot should be relatively inexpensive.

2. The robot should be able to navigate across various types of floors seen in modern

homes.

3. The robot should be intuitive and easy to use for the average homeowner.

4. The robot should include safety mechanisms.

5. The robot should require minimum amount of setup for basic use.

6. The robot should move autonomously.

5

7. The robot should be configurable by the user.

8. The robot should be able to sense multiple hazards such as motion, sound, and

some common hazardous gas.

9. The robot should be capable of backing up data.

10. The robot should be expandable for increased coverage and security.

11. The robot should be capable of transmitting real-time data over some medium.

6

Objective Tree (Nathaniel)

Figure 1: Objective Tree

7

Design Requirements Specification (Nathaniel, Megel, Andrew, Roger)

Table 1: Design Requirement Specification

Marketing Requirement

Engineering Specification Justification

1, 2, 3 The dimensions should not exceed 50cm × 50 cm ×100 cm.

The size of the robot should be small so that costs are low, it can navigate through normal household spaces, and it is easy for the user to operate.

1, 2, 3 The mass should not exceed 10 kg.

The weight of the robot should not be large so that costs are low, it can be driven without using a lot of power, and it is easy for the user to operate.

2, 4, 6 The movement speed should be 0.3 m/s ± 10%.

The speed should be reasonably rated for safe, autonomous movement over various surfaces.

6, 9, 10 A fully charged battery should completely deplete in no less than 8 hours.

The battery life should be sufficient that the robot can operate autonomously for a reasonable amount of time. It should also be able to back up and transmit data within this time as well as have capacity for more sensors (future expansion).

8, 11 Must be able to react to a notification of a hazard in under 10 seconds.

In order for the robot to transfer data in “real” time, it must be able to react to a hazard quickly.

8 Must be able to detect carbon monoxide levels as low as 45 ppm.

Carbon Monoxide levels between 1 and 70 ppm are usually not harmful. Levels over 70 ppm can cause noticeable symptoms of carbon monoxide poisoning. Levels over 150 ppm can be lethal.

8

8 Must be able to detect the presence of a candle fire approximately 3 meters away.

The robot should be able to determine if there is a fire or not, and alert the user.

8 Must be able to detect breaking glass.

The robot should be able to determine if there has been a break-in and alert the user.

5, 7, 9 Must be able to send data to a secure location

The user should be able to view the live video footage from the camera provided they have an internet connection.

1,3,5,7 Must be able to start up with less than 1 hour of setup.

The system should be mobile and easily placed into a new setting, and not require a long setup time.

Marketing Requirements

1. The robot should be relatively inexpensive. 2. The robot should be able to navigate across various types of floors seen in

modern homes. 3. The robot should be intuitive and easy to use for the average homeowner. 4. The robot should include safety mechanisms. 5. The robot should require minimum amount of setup for basic use. 6. The robot should move autonomously. 7. The robot should be configurable by the user. 8. The robot should be able to sense multiple hazards such as motion, sound, and

some common hazardous gas. 9. The robot should be capable of backing up data. 10. The robot should be expandable for increased coverage and security. 11. The robot should be capable of transmitting real-time data over some medium.

9

Accepted Technical Design

Hardware:

Theory of Operation (Level 0): As seen from the level 0 hardware block diagram, the

purpose of the security robot hardware is to process sensor data to alarm the user as well

as control the motor. The robot will receive input from a variety of sensors to determine

security threats, receive feedback from the user, and receive power from the power

source. After processing the inputs, the robot will alarm the user and move the motor in

various ways.

Figure 2: Hardware Block Diagram Level 0

Table 2: Hardware Level 0 Functional Requirements Table

Module Surveillance Robot Hardware

Designer Andrew Biddinger, Nathaniel Fargo, Megel Troupe, Roger Zhang

Input Sensor Input, Power, User Feedback

Output Communication with the user, motor movement

Description Receives power, sensor input, and user feedback to drive the robot motor and transmission.

10

Theory of Operation (Level 1): As shown in Figure 3 below, the purpose of the security

robot hardware is to process sensor data to alarm the user as well as control the motor.

The robot will receive input from a variety of sensors to determine security threats,

receive feedback from the user, and receive power from the power source. After

processing the inputs, the robot will alarm the user and move.


Table 3: Power Block Functional Requirements Table

Module Power Source

Designer Roger Zhang

Inputs Power Charger

Outputs Power to various components

Description The power source will supply power to the various hardware components.

11

Table 4: Sensor Functional Requirments Table

Module Sensors


Inputs Stimulus from the environment, Power

Outputs Sensor Data

Description Sensors on the robot will be stimulated by environmental signals and pass data to the processing unit.

Table 5: Processor Functional Requirements Table

Module Processor


Inputs Sensor Data, Power, Received Data

Outputs Transmitter Payload, Motor Drive

Description The processing unit will process sensor data and feedback from the user. The unit will be supplied power from the power supply. After processing data, it passes payload to the transmitter and drives the motor.

Table 6: Motor Functional Requirements Table

Module Motor


Inputs Motor Drive, Power

Outputs Motor Movement

Description The motor will be driven by the processing unit and will receive power from the power supply. It will move mechanically depending on how it is driven.

12

Table 7: Transceiver Functional Requirements Table

Module Transceiver


Inputs Feedback from user, power

Outputs Transmission to user

Description The transmitter sends signals to the user. The receiver will receive feedback from the user.

Theory of Operation (Level 2): Four 24V DC gear motors will be utilized for

locomotion. The motor driver will be a commercially assembled part that provides the

ability to control the motor's speed using PWM. It will receive the PWM signal from the

MCU and then output the driver current to the motor. Each driver will be configured to

drive two motors out of the four. In this manner, we will be able to turn the robot on a

time and navigate through the environment with precision. This is important when

implementing a mapping algorithm that requires accurate movement. Fuses are

implemented to provide over current protection to keep the motors safe. Each of the

motors will be fitted with a 71:1 gear reduction ratio. The theoretical rating for these

motors will be 91 RPM at no load, a rated torque of 3.1 kgf-cm, and a rated current of

less than 250mA.

Safety concerns on the robot will be addressed with the use of a mechanical ESTOP. A

mechanical push button will be utilized in tripping the circuit breakers connected to the

output of the power sources. Thus, once the E-Stop is pushed, power to all electronic

components and motors will be cut off, and the robot will suspend motion.

The sensors that will be used on the Surveillance Robot are a Carbon Monoxide sensor, a

UV sensor, an audio sensor, a gyroscope, and proximity sensors. Using information from

13

the gyroscope and the proximity sensors, the robot's position can be determined. Using

information from the CO, UV, and audio sensors, alarm conditions can be detected. Data

from the sensors is amplified to the MCU's operating voltage and is processed in the

MCU for alarming the user via transceivers and for locomotion. The MCU will

communicate with transceivers using SPI protocol.

The robot will be powered by the combination of a 24V battery and a 5V battery. The

batteries are chargeable and will be charged by a 24V charger and a 5V charger. A power

plug can be plugged into the standard 125V, 60Hz and the voltage will be conditioned by

both the battery chargers so that the batteries can be charged.


14

Table 8: Electronics Power Source Functional Requirements Table

Module 3.7V Battery Designer Roger Zhang Inputs Power from Charger Outputs 3.7 volts DC Description Electronics on the robot such as the sensors, transceivers, and MCU will

be powered by the 3.7V Batteries

Table 9: Motor Power Source Functional Requirements Table

Module Motor Power Supply Designer Roger Zhang Inputs Power from Charger Outputs Power to motor (24VDC) Description The motor will receive power from the motor power source.

Table 10: Controller Functional Requirements Table

Module Explorer 16 Board Designer Roger Zhang Inputs Sensor Data (UV, Audio, proximity, gyroscope etc…), 11.1V power,

transceiver serial data, Encoder Input Outputs PWM signal to the motor driver, serial data to transceivers Description The controller processes sensor data and drives the motor. It also

communicates with the transceivers and processes received data.

15

Table 11: Sensors Functional Requirements Table

Module Sensors Designer Roger Zhang Inputs Stimulus from environment (UV, Audio, proximity, gyroscope), power Outputs Sensor Data (UV, Audio, proximity, gyroscope) Description The sensors convert stimuli from the environment into electrical signals

Table 12: Transceivers Functional Requirements Table

Module Transceiver Designer Roger Zhang Inputs SPI Interface With PIC24 Outputs Transmission to nearby router Description The transmitter sends signals to the router.

Table 13: Motors Functional Requirements Table

Module Motors Designer Roger Zhang Inputs Motor drive Outputs Motor movement, feedback to PIC Description The motor will be driven by the motor driver to control the speed and

will send feedback to the PIC.

16

Table 14: Motor Drivers Functional Requirements Table

Module Motor Driver Designer Roger Zhang Inputs PWM from MCU, Motor power Outputs Motor drive Description The motor drive receives PWM from the MCU and receives power from

the motor power source. It will supply (speed) motor drive to the motor.

17

Closed Loop Locomotion System:

The locomotion system is responsible for the physical movement of the vehicle. As of the

end of the fall semester, the mechanical design is an extraction of a previous robot frame

from previous years. Locomotion decisions will be based on processed data from the

sensors. The data is processed in the PIC24 microcontroller and then sent to the

Sabertooth motor driver (TE-091-212). In this manner, the microcontroller will control

the Sabertooth motor drives which will power the individual wheels via speed control.

Speed control of the individual wheels will then control the physical movement of the

security robot.

Feedback from several sensors is used to make the movement of the robot more accurate.

Ping sensors on the front, back, and sides of the robot will ascertain the physical location

of the robot in the environment. In addition, the gyroscope will be used to detect angular

rate. The combination of sensors, encoders, ping sensors, gyroscope, motors, the driver,

and the microcontroller makes the robot locomotion system a closed loop system.

Hardware Design:

(See electronics schematics for ping sensor and gyroscope configuration)

18

Figure 5: Electronics Schematic 1

19

Figure 6: Electronics Schematic 2

20

Figure 7: Microcontroller Pin Diagram

21

Software:

Theory of Operation (Level 0): As seen from the level 0 software block diagram, the

purpose of the surveillance robot software is to process the sensor data and decide if

warnings should be sent to the user about the environment. It also sends control signals

back to the hardware to help drive the robot to its next location. After it has done this

processing and sent the control signals, it will wait a set amount of time before repeating

the process again.

Figure 8: Software Block Diagram Level 0

Table 15: Software Level 0 Functional Requirements Table

Module Surveillance Robot Software

Designer Andrew Biddinger, Nathaniel Fargo, Megel Troupe, Roger Zhang

Input Sensor Input

Output Warnings to user, motor control to robot

Description

Receives inputs from the various sensors (some for monitoring, others for movement), and propagates warnings to the user about the environment as well as sends the necessary motor controls to the hardware to reach the next desired location.

22

Theory of Operation (Level 1): The basic idea behind this layer of software is that the

sensor data is read from the Sensor I/O module and used in a finite state machine. It will

send control signals to the Locomotive and Warning modules depending on what state it

is in. The locomotive module will then take these control signals and determine exactly

how far to move the robot. The warning module will also warn the user when a threat is

in the proximity of the robot and log this information.

Sensor I/O Locomotive

Warnings

Sensor Data Power Signals to Robot

Warnings to UserState Machine


Table 16: Sensor I/O Software Functional Requirements Table

Module Sensor I/O Software Designer Andrew Biddinger Inputs Sensor Data Outputs Digital sensor data Description This module reads in the data from the sensors and stores them in global

variables through the use of interrupt service routines.

23

Table 17: Locomotive Software Functional Requirements Table

Module Locomotive Software Designer Andrew Biddinger Inputs Control Data Output Signals to power the motor Description This module takes in control data from the sensors and sends signals to

the motor drive control system to move the robot.

Table 18: Warning Module Software Functional Requirements Table

Module Warning Module Software Designer Andrew Biddinger Inputs Control Data Output Warnings to user Description This module is called from the state machine if a warning is present. It

then sends warnings to the user and logs the event.

Table 19: State Machine Software Functional Requirements Table

Module State Machine Software Designer Andrew Biddinger Inputs Controls from Sensor I/O Output Controls to Locomotive Software

Controls to warning module Description This module processes the data from the Sensor I/O module and

determines the state of the system. From this state, it either sleeps before processing the data once more, or calls the Warning or Locomotive modules.

Theory of Operation (Level 2): At this level, the software modules were broken down

into their individual main functions. Each of these functions will interact based on when

it is time for the robot to move or send a warning to the user.

24


Table 20: Sensor I/O: Interrupt Service Routines

Module Sensor I/O: Interrupt Service Routines Designer Andrew Biddinger Inputs Inputs from various sensors Output The status of each of the sensors Description These functions read the values from the sensors and store them as

global variables.

Table 21: Finite State Machine

Module Finite State Machine Designer Andrew Biddinger Inputs Sensors values from Sensor I/O module Output The next state of the software Description A state is determined and the Move function is either called or the

Warning function is called. If neither is appropriate (the robot is moved to neither state) then a sleep occurs and the values are checked from the sensors later.

25

Table 22: Locomotive: Move Function

Module Locomotive: Move Function Designer Andrew Biddinger Inputs Direction and distance to move (from the finite state machine) Output Signals are sent to the motor to move the robot a prescribed distance and

direction. Description This function will move the robot as far as needed and in the direction

stated by the state machine.

Table 23: Warning: SendEmail Function

Module Warning: SendEmail Function Designer Andrew Biddinger Inputs Email to send to from configuration Output Warning via HTTP. Description This function will send an HTTP message via an Ethernet module to the

user at the configured email with the appropriate warning information.

Table 24: Warning: SendText Function

Module Warning: SendText Function Designer Andrew Biddinger Inputs Cell phone # to send to from configuration Output Text message Description This function will send a text message to the user at a configurable cell

phone # with the appropriate warning information.

26

State Machine State Diagram (Andrew)

The following state diagram describes the different states that the system can be in. The

system starts off in an initialization state where the counters and the registers are

initialized. It then moves to a processing state which reads the values from the sensors

and determines what to do next. If there is a hazard, the state is moved to warning and the

warning module is notified. If there is not a hazard detected, the state is moved to the

Move state and the Locomotive module is notified of which direction to move to.

Initialize

Processing

MoveWarning

Sleep

Warning Condition No Warning Condition

Figure 11: State Machine State Diagram

Movement Algorithm (Andrew)

The robot will move around the environment by following a well-known wall follower

algorithm, but with a built in invisible grid similar to an invisible fence. The process will

start with the robot being placed on the ground and being powered on. The robot will

27

initialize its internal grid which will have configurable values for width and height. The

grid squares themselves will be a square foot. The default values for the grid width and

height will be 15x15, meaning that the robot will patrol around a 15x15 ft area. The robot

will then “place” itself at the top of the grid height wise and in the middle of the grid

width wise and assume a westward orientation. Figure 10 shows the robot being placed,

indicated by a blue grid in the simulation. The black squares indicate walls, and white

squares indicate open space. Added user obstacles are indicated by yellow squares.

28

Figure 12: Robot Placed

When the robot is powered on, or the simulation is started, the robot initializes its grid

(indicated by red squares on the simulation). Figure 11 shows the grid with the inserted

invisible grid.

Figure 13: Invisible Grid Initialized

From this point, the robot begins the right hand wall follower algorithm. The robot moves

by using the following priority system: Right > Forward > Left > Back.

29

This means that if the robot is able to move right, it will do so. Otherwise it will attempt

to move forward, left, and back (in that order of priority). If the robot is not able to move

in any direction (if there is an obstacle presented in each of the surrounding squares) the

robot will not move. The robot will also not attempt to leave the internal defined grid

indicated by the red squares.

Motor Movement and Corrections (Andrew)

The motors will be controlled by two analog pins on the microcontroller. The output of

the pins will vary between 0 and 5V. With the motor driver in analog mode, a signal of

2.5V indicates the motor should be idle. An output between 2.6 and 5.0 V indicates a

forward direction, with the speed increasing as the voltage increase. An output between

0.0 and 2.4V indicates a reverse direction, with the speed increasing as the voltage

decrease.

When it is desired for the robot to turn left or right, the robot will first be rotated 90

degrees in the appropriate direction. This will be accomplished by taking the current

reading of the gyroscope, then rotating one motor forward and the other in reverse. The

constant readings from the gyroscope will be monitored and as the turn closes in on 90

degrees, the motors will be slowed until they reach their desired position and are returned

to an idle state.

When the desired movement is forward, both motors will be powered forward. As they

accelerate and continue to move, the gyroscope will be monitored to ensure one motor is

not ever so slightly causing the robot to move off to the left or right. If this is the case, the

30

power for one of the motors will be slowed ever so slightly until the reading of the

gyroscope returns to its expected position.

To ensure the robot moved forward the proper distance, a combination of readings from

the PING sensors and the encoders will be used.

Software Pseudo Code (Andrew, Nate)

The following pseudo code illustrates how the various functions of the software modules will be implemented and interact with each other.

//Andrew int main(argc,argv) { //Initialize Counters, Registers, etc //Begin Finite State Machine Loop } void mainLoop() { while(true) { //Initialize state to Initializing switch(state) { case(STATE_INITALIZING): //If state is initializing, set up any necessary registers, set direction to West, etc //Transition state to Processing. case(STATE_PROCESSING): //Check sensors, if an alarm sensor is sensing an event, transition to Warning state //Otherwise, transition to Move state case(STATE_MOVE): //Call move function. This function will handle figuring out where and how to move. //Transition state to Sleep after setting a value for sleep time. case(STATE_WARNING): //Call the warning text and warning email functions with configurable values for email and phone #s. //Transition state to Sleep after setting a value for sleep time. case(STATE_SLEEP): //Sleep for time specified in the sleep time variable. //Transition state to Processing. } } } void initialize() //This function is called during the Initializing State { //Set up any necessary registers and global variables. } bool checkSensors() {

31

//Request sensor data from all available sensors (their results are stored in global variables). //Return a boolean indicating rather an event is occurring or not. NOTE: This might change from boolean to an enum depending on what level of detail our email/text will supply. } bool move() { //Determine where to move //Move to that location } bool canMoveForward() { //Check sensors to determine if moving forward is possible (also take into consideration current location on the grid). //Return a boolean indicating rather a forward move is allowed. } bool canMoveLeft() { //Check sensors to determine if moving left is possible (also take into consideration current location on the grid). //Return a boolean indicating rather a left move is allowed. } bool canMoveRight() { //Check sensors to determine if moving right is possible (also take into consideration current location on the grid). //Return a boolean indicating rather a right move is allowed. } bool canMoveBack() { //Check sensors to determine if moving back is possible (also take into consideration current location on the grid). //Return a boolean indicating rather a back move is allowed. } void moveForward() { //We will move the length of one square in the grid at a time (12 inches) //TODO } void moveLeft() { //Change direction 90 degrees to the left //Call move forward } void moveRight() { //Change direction 90 degrees to the right //Call move forward } void moveBack() { //Change direction 180 degrees //Call move forward } void spinAround(int degrees, enum direction) { //Get current reading from gyroscope //Depending on direction, turn one motor on and the other motor in an opposite direction //Continue to check gyroscope reading. As it nears the correct number of degrees deaccelerate both motors.

32

//When the gyroscope indicates we have spun enough, stop both motors. } void sleep() { //Clear sleep counter //Wait until sleep counter has reached pre-determined value set in the sleep timer variable. //Return after this sleep counter has been reached. } //Nate void sendEmail(string email) { //Compile Email Message //Send Message } void sendText(int phoneNumber) { //Compile Text Message //Send Message } void getPingSensor(int number) { //Use switch case statements to pick correct pins for correct sensor and choose correct array index to store value data //Case 'number' //set pin as output //next operations should take 5 microseconds //set pin high //wait 'x' microseconds //set pin low //set pin as input //wait for pin to go high //count clock cycles while pin is high //once pin goes low, calculate distance based on pulse width } void getMotionSensor(int number) { //Get value from motion sensor //Add value to motionSensor array } void getMicrophone(int number) { //initialize A2D converter //get A2D data from channel 'number' microphone is wired to //add data to storage array } void getGlassBreakSensor(int number) { //we should have two wires on this sensor. One wire should go from a 5 VDC point to one side of the normally closed contact. //the other wire should go from the other side of the normally open contact to an "interrupt on change" input. //Now for the pseudo code //when pin goes low, enable interrupt service routine //Call "sendEmail" function and pass it data indicating glass breaking //call "sendText" function and pass it data indicating glass breaking //clear interrupt flag } void getGasSensor(int number) {

33

//initialize A2D converter //get A2D data from channel 'number' gas sensor is wired to //add data to storage array } void getUVTron(int number) { //as with glass break sensor, use an interrupt pin //when pin goes high/low (configurable), enable interrupt //Call "sendEmail" function //call "sendText" function //clear interrupt flag } void getGyroscope() { //initialize SPI port //SPI read of gyroscope data //calculate angular rate of change //store data in array }

Configurable User Parameters (Andrew)

The user will have the option via some interface to configure several system parameters.

The table below shows the known configurable parameters and any default values they

might have.

Table 25: Configurable User Parameters

Configurable Setting Default

Invisible Grid Width 15

Invisible Grid Height 15

Warning Email <None>

Warning Text <None>

Software Testing (Andrew) There are three major groups of software components in this project.

Sensor Data Collection Testing (Andrew)

34

The first is the collection of the sensor data that are stored in global variables. Each type

of sensor will have a slightly different method for collection of data, and each will need

to be tested individually.

Locomotive Testing (Andrew)

The second group of software that will require testing is the locomotive system. The

algorithm for determining where to go has already been simulated and the general theory

has been proven to work as expected. When the real algorithm is implemented for the

PIC24F, the code can be simulated with simulated values for sensors before the real

system is ran for the first time. This will give us a high level of confidence that we are

making the right decisions as to where to move and that we move there correctly.

Warning Testing (Andrew)

The last major group of software that will require testing is the sending of the warning

emails and texts. This should be relatively easy as it can be done before the hardware is

ready to go. An email and phone number will be configured in software and the

individual email and text functions can be executed to ensure they work as expected.

Further testing of this module could include a simulated event to ensure that the state

machine properly calls the functions and that the correct formatted email is sent out.

35

Approximate Robot layout design

Figure 14: Mechanical Layout

Engineering Calculations Power balance:

𝑃! + 𝑃! = 𝑃! + 𝑃!! + 𝑃!! + 𝑃!! + 𝑃! [1]

𝐼!×𝑉! + 𝐼!×𝑉! = 𝐼!×𝑉! + 𝐼!!×𝑉!! + 𝐼!!×𝑉!! + 𝐼!!×𝑉!! + 𝐼!×𝑉! [2]

m = motor/motor supply, e = electronic supply, e1 = sensors, e2 = transceiver, e3 = amplifier, l = loss.

𝑃! = 𝑉!×𝐼! = 𝑇!×𝜔! [3]

36

Equation [1] is derived from the hardware block diagram level 2. This equation states

that the power drawn from the power source must equal the power use by each block plus

some loss. Equation [2] shows the same relationship, but it is broken down into voltage

and current. Equation [3] shows the relationship between the voltage and current in the

motor vs. the motor torque and angular velocity.

37

Motors (Megel Troupe)

The Drive sizing is intended to give an idea of the type of drive motor required for your

specific robot by taking known values and calculating values required when searching for

a motor.

Table 26: Driver motor input specifications

Robot Mass 9.072Kg

No. Of Motors 2

Wheel Radius 0.0635 m

Robot Velocity 0.3 m/s

Max Incline 20 0C

Supply Voltage 24V

Desired Acceleration 0.15m/s2

Desired operating time 3Hrs

Total Efficiency 75%

38

Table 27: Driver Motor Output Calculated Values

These values were calculated based on the motor input specified values.

Angular Velocity 45 rpm 4.7 rad/s

Torque 1.3 Nm 13.7 kgf-cm

Total Power 6.4 W 0.009 hp

Max Current 0.3A

Battery Pack Amp Hours 1.6 AH

The table below lists the motor characteristics. This motor has a small torque of about 20

kgf-cm. The motor utilizes a 1:84 gear reduction. The gear motor is 24VDC. A picture of

this motor can be seen below in figure x. These gear motors have encoders mounted to

the tail shaft of the motor. They are Hall Effect encoders that count the revolutions the

motors make. Since it’s a two channel encoder you can detect the direction of rotation

and pick up 4 rises and falls per revolution of the motor. By apply the gear ratio of the

motor and any further reduction of your drive train to get total revolutions of your wheel.

Table 28: Motor Characteristics

Reduction Ratio

Rated Torque Rated Speed

Rated Current

No Load Speed

No Load Current

kgf-cm rpm mA rpm mA

1:84 20 75 <2300mA 83 <750mA

39

Figure 15: 24V Motor

Figure 16: Encoder Pins

Figure 17: Encoder Pin Descriptions

40

Driver motor output calculations :(Megel Troupe)

To calculate the required torque, power, current and battery pack required by the robot,

several factors were taken into consideration, for example Force; Power; Current and

Voltage. In order to roll on a horizontal surface, the robot motors must produce enough

torque to overcome any imperfections in the surface or wheels, as well as friction in the

motor itself. Therefore, in theory, the robot does not require much torque to move purely

horizontally.

In order for a robot to roll up an incline as seen in figure 10, at a constant velocity it must

produce enough torque to “counteract” the effect of gravity, which would otherwise

cause it to roll down the incline. On an inclined surface (at an angle theta) however, only

one component of its weight (mgx parallel to the surface) causes the robot to move

downwards. The normal force the surface exerts on the wheels balances the other

component, mgy.

𝑚𝑔𝑥 = 𝑚𝑔× sin𝜃

𝑚𝑔𝑦 = 𝑚𝑔× cos𝜃

𝑇 = 𝑓×𝑟 (Torque required)

To select the proper motor, we must consider the “worst case scenario”, where the robot

is not only on an incline, but accelerating up it, see figure 18.

41

Figure 18: Wheel Dynamics

Balancing the forces in the x-direction:

Σ𝐹! = 𝑚×𝑎 = 𝑚𝑔! + 𝑓

⇒ 𝑚 ∗ 𝑎 = 𝑚𝑔! ×𝑠𝑖𝑛𝜃 + (𝑇/𝑟)

⇒ 𝑇 = 𝑎 + 𝑔!𝑠𝑖𝑛𝜃 ×𝑚×𝑟

The torque value represents the total torque required to accelerate the robot up an incline.

However, this value must be divided by the total number (n) of drive wheels to obtain the

torque needed for each drive motor.

⇒ 𝑇 = !!!!!"#$ ∗!∗!!

, where n= number of motors

⇒ 𝑇 =(0.15 + 9.81 sin 20 ∗ 9.072𝑘𝑔 ∗ 0.0635𝑚

2= 1 𝑁𝑚

42

The final point to consider is the efficiency (e) in the motor, gearing and wheel (slip).

This increases the torque required and compensates for inefficiencies.

𝑇 = 100 𝑒 ∗(0.15+ 9.81 sin 20 ∗ 9.072𝑘𝑔 ∗ 0.0635𝑚

4 =

⇒ 𝑇 = 100 75 ∗(0.1+ 9.81 sin 20 ∗ 9.072𝑘𝑔 ∗ 0.0635𝑚

2 = 1.3 𝑁𝑚

The total power per motor:

𝐿𝑒𝑡: 𝑃 = 𝑇 ∗ 𝜔

Where: 𝜔 = !!= !.!!/!

!.!"#$!= 𝑎𝑝𝑝𝑟𝑜𝑥 4.7 rads/s

Therefore: 𝑃 = 1.6𝑁𝑚 ∗ 4𝑟𝑎𝑑/𝑠 = 𝑎𝑝𝑝𝑟𝑜𝑥 6.4 𝑊

T is known from above and the angular velocity (𝜔) is specified. The maximum angular

velocity was used so to be able to find the corresponding maximum power. Knowing the

maximum power and the supply voltage (V) which was chosen, this gives an idea of the

maximum current (I) requirements:

𝑆𝑖𝑛𝑐𝑒: 𝑃 = 𝐼𝑉

⇒ 𝐼 =𝑇 ∗ 𝜔𝑉 =

6.4 𝑊24𝑉 = 𝑎𝑝𝑝𝑟𝑜𝑥 0.3 𝐴𝑚𝑝𝑠

43

This value is large because the rated amp hours are not an accurate indicator of the

maximum current the pack can produce for extended periods of time. Also, the total

charge is rarely retained over time. This way you will ensure the battery pack you select

will be capable of producing the current your motors require, for the time you require and

with the inefficiencies inherent in recharging battery packs.

𝐶 = 𝐼 ∗ 𝑡 ∗ 𝑛 (The capacity of the battery)

Therefore: 𝐶 = 0.3 ∗ 3 ∗ 2 = 𝑎𝑝𝑝𝑟𝑜𝑥 1.6 𝐴𝐻𝑟𝑠

Motor Driver/Controller (Megel Troupe)

The motor controler that will be used is the Sabertooth 2x12 Seen in figure x below. The

motor controller will communicate with the PIC 24FJ128GA010 microcontroller, which

would be the on the Explore 16 board, configured in the Analog operation mode. The

analog input mode takes one or two analog inputs, in this case two inputs, S1 and S2 and

uses those to set the speed and direction of the motor. The valid input range is 0v to 5v.

This makes the Sabertooth easy control using the PWM output of a microcontroller.

Figure x: Sabertooth 2x12 motor controller

44

There are three operating options for analog input, mixed mode, exponential response and

4x Stativity. These are selected with switches 4, 5 and 6. All the options can be used

independently or in any combination. In Mixed mode, see figure 19 switch 4 is in the UP

position. This mode is designed for easy steering. The analog signal fed into S1 controls

the forward/back motion of the robot, and the analog signal fed into S2 controls the

turning motion of the robot. If Switch 4 is in the DOWN position, the Sabertooth 2x12 is

in Independent mode. In Independent mode, the signal fed to S1 directly controls Motor 1

(outputs M1A and M1B) and the signal fed to S2 controls Motor 2.

Figure 19: Mixed Mode

If switch 5 is in the DOWN position, the response to input signals will be exponential.

This softens control around the zero speed point, which is useful for control of vehicles

with fast top speeds or fast max turning rates. If switch 5 is in the UP position, the

response is linear.

Figure 20: Exponential Response

45

If switch 6 is in the UP position, the input signal range is from 0v to 5v, with a zero point

of 2.5v. If switch 6 is in the DOWN position, 4 x Sensitivity mode is enabled. In this

mode, the input signal range is from 1.875V to 3.125V, with a zero point of 2.5v. This is

useful for building analog feedback loops

Figure 21: 4x Sensitivity

Pulse Width Modulation (PWM)

Pulse Width Modulation is the ability to generate a pulse whose width/duration can be

altered. By turning an output pin repeatedly high and low very quickly then the result is

an average of the amount of time the output is high. If it is always low the result is 0v,

always high then the result is 5v, if half-and-half then the result is 2.5v.The percentage of

time that our output pin is high will give the duty time from which the duty cycle can be

realized.

46

Figure 22: Pulse Width Modulated Signal

Motor Driver Construction :(Megel Troupe)

The Sabertooth 2x12 will be constructed using a two small 24V DC Motor, in the Analog

Mode. In this Mode, Control input S1 is directly controlled M1A and M1B outputs. The

positive lead of the DC Motor is connected to M1A and the negative lead to the M1B.

When a voltage between 2.5 volts and 5 volts is applied to the control input the motor

rotated in a clockwise direction. When a voltage between 0 volts and 2.5 volts is applied

to the control input the motor rotated in a counter clockwise direction. The counter is true

when the control input S2 is directly controlled M2A and M2B outputs. The positive lead

of the DC Motor was connected to M2A and the negative lead to the M2B. When a

voltage between 2.5 volts and 5 volts is applied to the control input the motor rotated in a

counter clockwise direction. When a voltage between 0 volts and 2.5 volts is applied to

the control input the motor rotated in a clockwise direction.

47

Block Diagram OF Motor Drive (Megel Troupe)

The motor drive block consists of five sub blocks, the sensors, microcontroller, motor

controller, power, and motors. The power block is use to supply the motor controller.

The motor controller takes its instructions (PWM) from the Pic24FJ128GA010, and the

microcontroller decision is influence by the information supplies to it by the sensor. The

actuator (DC motors) will then carries out the instructions of the motor controller. A

breakdown of the block diagram and its schematic can be seen below.

Figure 23: Motor System Closed Loop Configuration

48

Figure 24: Schematic of motor drive train

49

18650 Lithium Battery Pack (12V Li Ion Batteries): (Megel Troupe)

The power supply used to power the Motor Drive circuit above is two 12V 18650

Lithium ion battery packs. The batteries are placed in series and are connected to

terminals B- and B+. B- Connects to the negative side of the battery B+ connects to the

positive side of the battery. Figure n3 below shows a picture of the battery been used.

Figure 25: 18650 Lithium Battery Pack

12V Li-ion battery 18650 data sheet 12v Li-ion Battery Specification

Specification 12v 6000mAh Rechargeable polymer li-ion battery for LED light

Model HHS 18650

Weight 480g

Size Thickness × Width × Length (mm)

50

54±0.5×54±0.5× 66±0.5

Nominal voltage 12 V

Nominal capacity 6000mAh

Max charge current 1C

Max discharge current 1C

Discharge cut-off voltage 3.0 V, the over-discharge detection voltage of PCM

Operating environment Charging, 0°C ~ 45°C ; 65±20%RH

Discharging, -20°C~60°C ; 65±20%RH

Storage environment -20°C~45°

65±20%RH

storage for a long time(>3 months) and the storage condition shall be:<35°C;65±20%RH;3.7~3.9V

Cycle Life(80%Prime Capacity) :

>500times

51

Table 29: Worst Case Electronics Power Calculations

Worst Case Scenario Power Calculations

Total Current Draw Part

Max Current (A)

Voltage Supply (V)

Max Power(V*I)

Load Resistance (V^2/P)

0.1 PING))) Ultrasonic Sensor 0.02 5 0.1 250

0.16 CO (Carbon Monoxide) Gas Sensor 0.16 5 0.8 31.25

0.04 PIR Sensor (Rev A) 0.01 3.7 0.037 370 0.0005 Electret Microphone 0.0005 3.7 0.00185 7400

0.005

Parallax 3-‐Axis 250 / 500 / 2000° / s Gyroscope Module 0.005 3.7 0.0185 740

0.02 Glass Breaking sensor 0.02 11.1 0.222 555

0.15 Wi-‐Fi Radio Transceiver 0.15 3.7 0.555 24.66666667

0.25 Explorer 16 Demo Board 0.25 11.1 2.775 44.4

2 Foscam FI8918W Wireless IP Camera 2 5 10 2.5

Battery Life (h)

Total Current Camera On 2.7255 2.41

Total Current Camera Off 0.7255 9.09

camera power intermittent (30minutes)

7.72

Battery Total Amp Hours 6.6

From the above table, it can be seen that the robot satisfies the design requirement of 8 hours of continuous operation under the condition that the camera is only used intermittently.

52

Parts List The table below shows the list of parts needed along with the description of their

function. The table also shows the quantity and cost of the parts and the total budget of

the project. As seen in the table, the overall cost of the project is estimated at $724.20.

This is more than our initial limit of $400. Discussion with the Senior Design

Coordinator (Professor Lewis) and the Faculty Advisor (Dr. Tsukerman) will be

necessary to determine how to make up the remainder of the budget.

Table 30: Parts List

Unit Total

Qty. Part Num. Description Cost Cost 1 28015 PING))) Utrasonic Sensor $29.99 $29.99 1 28039 4 Pack of PING))) Utrasonic Sensors 99.99 99.99 1 Sabertooth 2X12 Sabertooth Dual 12A Motor Driver 79.99 79.99 2 IG-32GM 24VDC 067 RPM Gear Motor 22.74 45.48 1 MQ-7 CO (Carbon Monoxide) Gas Sensor 5.99 5.99 4 PIR Sensor (Rev A) Motion Sensor 4.99 19.96 5 RB-Spa-200 Electret Microphone 0.95 4.75

1 L3G4200D Parallax 3-Axis 250 / 500 / 2000° / s Gyroscope Module 29.99 29.99

1 GLASSTECH Glass Breaking sensor 28.00 28.00 1 DM240001 Explorer 16 Demo Board 129.99 129.99 1 MRF24WB0MA/RM Wi-Fi Radio Transceiver 26.98 26.98 1 FI8918W Foscam FI8918W Wireless IP Camera 74.99 74.99 1 18650 11.1V Li-Ion 2200mAh Battery Pack 26.99 26.99 1 ITEAD EBB002 Electronic Brick 5V Relay 2.96 2.96

4 RB-Ban-142 BaneBots Wheel, 4-7 / 8" x 0.8", 3 / 8" Key Mnt, 40A, Blk / Orange 6.80 27.20

1 RB-Spa-262 On/Off Switch 1.95 1.95

1 R345-UVTRON-PKG UVTron flame sensor Package 89.00 89.00

Total $724.20

Listed on the following pages are the details of each part.

53

FOSCAM WI-FI Camera:

Figure 26: FOSCAM Camera

Technical Description:

The FOSCAM Camera is a security camera with remote viewing capability and built in

video recording ability. The camera will act as a standalone unit on the security robot and

will activate upon specific alarm conditions. The power to the camera will from the 5V

power source through a 5V relay (RB-Ite-39). The relay will be actuated by a 5V digital

signal from the microcontroller. When power is supplied to the camera, the user will be

able to view either video stream or recorded footage on a Smartphone or personal

computer.

Hardware design:

When an alarm condition is detected, power to the camera will be supplied via a relay

and the user will be able to interact with the camera via software. The reason the camera

should not be turned on at all times is because the camera has a very large current draw at

2A. Constant usage of the camera will draw too much power and deplete the batteries.

For information on what conditions will trigger camera power, refer to the software

design.

54

Electret Microphone


Figure 27: Electret Microphone

The above picture portrays the microphone that the surveillance robot will employ for the

detection of loud noises. The sensor is sensitive to sounds from 100 to 10,000 Hertz. The

sensor has the following amplitude response for the sensitive frequency range:

Figure 28: Amplitude Response of Microphone

55

The sensor will be powered using the 5VDC source. The output will be a voltage

corresponding to the amplitude (and frequency based on above curve) of the sound wave.

During testing, an appropriately loud sound will be tested and the corresponding output

voltage will be recorded as the threshold voltage for an alarm condition.

Hardware Design:

The following diagram depicts the Microphone circuit:

Figure 29: Microphone Example Circuit

The power source of 5VDC will be applied at terminal one across a load resistor of

2.2KOhms. The common will connect to terminal two and the output will be taken with a

decoupling capacitor attached to the same place as the power source. The analog output

will be connected to an analog pin on the microprocessor.

56

Module Microphone


Input 5VDC for power

Output Analog Voltage corresponding to sound wave amplitude

Description The microphone will capture sound waves and output a electrical signal corresponding to the amplitude.

57

Explorer 16 Demo Board


Figure 30: Explorer 16 Board

The microcontroller will receive data from the sensors, the transceiver, and feedback

from the motor driver. The sensors include 4 ping sensors, a carbon monoxide sensor, 5

microphones, a gyroscope, 4 PIR sensors, and a glass breaking sensor. The ping sensors

will connect to digital pins, the carbon monoxide sensor will connect to a analog pin, the

microphones will connect to analog pins, the gyroscope will connect to SPI serial pins

(clock, serial in, serial out), the PIR sensors will connect to digital pins, and the glass

breaking sensor will also connect to a digital pin. The ping sensors will operate at 5V, the

carbon monoxide sensor will operate at 5V, the microphones will operate at 5V, the

gyroscope will operate at 3.7V, the PIR sensors will operate at 3.7V, the glass breaking

sensor will operate at 11.1V (output signal will pass through a 5V linear regulator). The

motors also has 4 encoder outputs which will be fed back to the microcontroller (motor

position feedback).The processor will be programmed to process sensor inputs and

58

encoder inputs and output payload data to the transceiver as well as PWM signals to the

motor drivers.

Hardware Design:

Figure 31: Explorer 16 Pin Diagram

59

MQ7 Carbon Monoxide & Flammable Gas Sensor


Figure 32: Carbon Monoxide Sensor

The figure above is a picture of the gas sensor that will be used for detection of both

carbon monoxide and flammable gases. The sensor is composed of a micro AL2O3

ceramic tube, a Tin Dioxide (SnO2) sensitive layer, a measuring electrode and a heater.

The housing for the sensor components is made of stainless steel. The heater provides

necessary work conditions for work of sensitive components. When CO concentration in

the surrounding space is changed, the sensitive Tin Dioxide layer will change in

resistance. The output circuit will respond to changes in this surface resistance.

Hardware Design:

60

According to the design requirements, the gas sensor must be able to detect carbon

monoxide levels as low as 45ppm. According to the sensitivity table shown below, this

sensor meets the design requirements. According to the table, the sensor detects CO

levels at a minimum of 20ppm.

Figure 33: Carbon Monoxide Sensor Parameters

The pin diagram of the CO sensor is shown below:

Figure 34: CO sensor pin Diagram

61

From the figure, it can be seen that we should connect 5VDC to the circuit voltage at Vc

and 5VDC to the heater voltage at VH. The circuit voltage will allow an output voltage to

be detected across B and the heater voltage will make sure that the sensor is heated to

adequate operating conditions. A 10kOhm resistor can be connected across B and

common as specified in the datasheet.

Further testing should be done to determine what output voltage VRL corresponds to a

carbon monoxide level of 45 ppm. This can be done using a carbon monoxide testing kit.

The following waveform describes sensor response at 100ppm with an adequate load

resistor:

Figure 35: CO monoxide sensor output waveform

Module MQ-7 Carbon Monoxide and Flammable Gas Sensor


62

Input 5VDC for heater, 5VDC for circuit voltage

Output Output voltage corresponding to CO concentration above 45 PPM

Description Then Carbon Monoxide sensor output voltage will respond when CO concentration is above 45ppm.

63

Parallax 3-Axis 250 / 500 / 2000° / s Gyroscope Module


Figure 36: Gyroscope

The figure above is a picture of the Gyroscope that will be used to determine turning

radius. The device is composed of sensing elements sensitive angular rate in the x, y, and

z directions. The sensing element is manufactured using a dedicated micro-machining

process developed by STMicroelectronics to produce inertial sensors and actuators on

silicon wafers. A CMOS IC outputs the measured angular rate through an SPI interface. It

is necessary to detect turning radius because it will allow for more accurate turning of the

robot. The robot will receive feedback output from the gyroscope during turning to

confirm that the expected turning radius has been achieved.

Hardware Design:

The Gyroscope will be powered at pin 1 (Vdd) and pin 16 with 3.7VDC and will output

the Z axis turning voltage at pin 6 (OUTZ). Below is the pin diagram of the device:

64

Figure 37: Gyroscope Pin Diagram

The device will be mounted on the robot so that it is parallel with the surface that the

robot is moving on. When the robot turns, the inertial elements inside the package will

actuate an inertial rate. Processors inside the sensor package will then sample the analog

voltage from the inertial sensors. The sampled data is then stored inside a register to be

accessed via SPI or I^2C protocol (we will be implementing SPI interface). The

following is the pin diagram for SPI interfacing:

65

Figure 38: Gyroscope Pin Description

To set interfacing to SPI, CS is set to low. Serial read output data is obtained at the SDO

pin and input commands are input at the SDI pin. The SPI clock is input at the SPC pin.

For additional information on the SPI interface, refer to the software design.

Module Gyroscope


Input 3.3VDC power, angular rate differential

Output SPI interface with PIC24

Description The Gyroscope detects angular rate differentials and outputs to the PIC24 via SPI interface.

66

PING))) Ultrasonic Sensor


Figure 39: Ping Sensor

Position feedback of the robot in its physical location will be achieved using ultrasonic

ping sensors. A total of 4 ping sensors will be used to ping the distance of the robot from

the front, back, and side walls. The ping sensors will ping the distance of the robot and

send the distance data to the microcontroller where it will be compared with expected

values.

The wheels will adjust their speeds based on the data from the ping sensors. For example,

if the distance from the left wall is detected to be higher than expected, the left wheel will

slow down and the right wheel will speed up until the next sample. The same feedback

and compensation scheme is employed for the front, back and sides.

Hardware Design:

The following is a table showing a list of technical specifications for the ping sensor

* Range - 2cm to 3m (~.75" to 10')

* Supply Voltage: 5V +/-10% (Absolute: Minimum 4.5V, Maximum 6V)

67

* Supply Current: 30 mA typ; 35 mA max

* 3-pin interface (power, ground, signal)

* 20 mA power consumption

* Narrow acceptance angle

* Simple pulse in / pulse out communication

* Indicator LED shows measurement in progress

* Input Trigger - positive TTL pulse, 2 us min, 5 us typ.

* Echo Pulse - positive TTL pulse, 115 us to 18.5 ms

* Echo Hold-off - 750 us from fall of Trigger pulse

* Burst Frequency - 40 kHz for 200 us

* Size - 22 mm H x 46 mm W x 16 mm D (0.85 in x 1.8 in x 0.6 in)

From the above list, it can be seen that the ping sensor will be operational at a maximum

range of 10 feet. From this, it can be deduced that the maximum magnitude for either

dimension (width or length) of the room can be to satisfy requirements for accurate,

feedback compensated locomotion is 20 feet. This is because two pairs of ping sensors

will be mounted back to back. When both sensors (front and back or left side and right

side) in a pair detect maximum distance, the sum of the detect distances will be a little

above 20 feet.

68

Figure 40: Ping Sensor Pin Diagram and Output Waveform

The above diagram describes pin information for the sensor as well as the expected

output. As seen from the diagram, the output will be a pulse for which the length of the

wave will correspond to the time needed for the ultrasonic wave to travel from the impact

location back to the sensor. Simple division can be done to obtain distance information.

Module Ping Sensors Designer Roger Zhang Inputs 5V power, DC ground Outputs Echo Time Pulse Description The ping sensor uses ultrasonic pulses to determine the time required for

an echo wave. Time required divided by speed of wave yields distance from obstacle.

69

PIR Sensor:


Figure 41: PIR Sensor

The PIR (Passive Infra-Red) Sensor detects motion by measuring changes in the infrared

(heat) levels emitted by surrounding objects. This motion can be detected by checking for

a sudden change in the surrounding IR patterns. When motion is detected the PIR sensor

outputs a high signal on its output pin.

Hardware Design:

Below is the pin description of the sensor:

Figure 42: PIR Sensor Pin Descriptions

70

Figure 43:PIR Sensor Pins

As seen from the diagrams, the 3.7VDC power source can be applied across V+

and ground. The output will become high when a sudden change in infrared values

occurs. This means that the sensor is not sensitive to changes that occur when the day

progresses. The output can be fed into a digital pin on the microcontroller because the

output will trip high when the alarm condition is detected.

Four PIR sensors will be mounted on the robot on the front, back, and sides. The

sensor has a range of 20 feet. This means that moving objects within 20 feet of the robot

will set off an alarm.

Module PIR Sensor


Input 3.7VDC power, Infared Waves

Output Digital signal indicating change in IR spectrum

71

Description The UV Flame sensor detects changes in UV waves. The increased presence of UV waves will trigger an alarm condition.

72

Wi-Fi Radio Transceiver


Figure 44: WI-FI Transceiver

The MRF24WB0MA/RM Wi-Fi transceiver is used to send email messages via the user’s

home router. The transceiver operates at 2.4GHz (standard Wi-Fi frequency) and

interfaces with the microcontroller via SPI pins. When an alarm condition is detected, the

proper payload information is passed via SPI to the transceiver and the user is noted of

the alarm condition via e-mail.

Hardware Design:

73

Figure 45: Transceiver Pin Diagram

The transceiver will be powered at GND and VDD with 3.3 volts. The 3.3V power will

be sourced from a 3.3V switching power pin on the microcontroller. Power to the

transmitter can be cut off and only supplied after alarm conditions. Powering the

transmitter only after alarm conditions can save power.

The transmitter will interface with the microcontroller using the SPI pins SDI (serial data

in), SDO (serial data out), SCK (serial clock), CS (Chip select). For more information

about implementation of the serial interface (timing, clock frequency, etc…) refer to the

software design.

Module WI-FI Radio Transceiver Designer Roger Zhang Inputs Serial Data In, Serial Clock, 3.3V Power Outputs Serial Out to Microcontroller, transmission to router

74

Description The transceiver will receive payload data from the microcontroller. Software implementation will allow the transmitted payload to reach the user in the form of a e-mail.

75

UV TRON Flame Sensor


Hamamatsu R2868 is a UV TRON ultraviolet detector that makes use of the photoelectric

effect of metal and the gas multiplication effect. It has a narrow spectral sensitivity of 185

to 260 nm, being completely insensitive to visible light. The R2868 has wide angular

sensitivity and can reliably and quickly detect weak ultraviolet radiations emitted from

flame due to use of the metal plate cathode. According to the UV TRON datasheet, the

sensor can detect the flame of a cigarette lighter at a distance of more than 5 m. This

means the UV TRON sensor will meet our design spec of detecting a candle flame at a

distance of 3m.

Hardware Design:

Figure 46: UV TRON Flame Sensor

76

Figure 47: UV Tron Pin Diagram and Suggested Setup

The above diagram portrays the placement of the nodes of the sensor with respect to the

sensing range. As seen from the diagram, the sensor has a wide range. As seen from the

circuit diagram, the suggested sensor circuit scheme involves a power source of 25V.

However, our battery will provide 5VDC to the UV TRON sensor. From the schematic,

the mega-ohm resistor and the 220pF capacitor serves as a low pass filter, and the

4.7kOhm resistor serves as a current limiting resistor. For our 5VDC regulated power

source, a low pass filter should not be needed. However, the 4.7kOhm resistor might be

useful since the rated current is only 30mA. A load resistor and a load capacitor will be

placed at the cathode output as shown in the circuit diagram. The output capacitor will

introduce a small time delay. This can reduce the number of false alarms.

77

The pulsed output will be input to a digital pin on the microprocessor. When the pulse

reaches high, an alarm condition can be triggered. For more information, refer to the

software design.

Module UV TRON Flame Detector


Input 5VDC across anode and cathode

Output Output pulse to digital pin

Description The UV Flame sensor detects changes in UV waves. The increased presence of UV waves will trigger an alarm condition.

78

Electronics Power Supply and E-Stop:


The electronics power supply consists of three 3.7V batteries connected in series. Voltage

potentials of 3.7V, 7.4V, and 11.1V can be directly drawn from the individual batteries.

The power distribution lines will be actuated by an on off switch as well as three relays.

A Lithium Polymer charger unit is used charge all three 3.7V batteries at the same time at

a rate of 1A.

Figure 48: On Off Switch

79

Figure 49: 5V Relay

The on off switch (left figure) will close the connection from the electronics power

supply to various electronics. It does this by actuating a 5V (7.4V passed through 5V

linear actuator) signal to three 5V relays. The relays will be normally open but when

actuated by 5V will close.

Hardware Design:

The relays have a peak voltage of 110V at 10A. The power sources that the relays will

actuate are at 3.7V, 7.4V, 11.1V, 24V respectively. The current draw from these power

sources will all be lower than 10A. This shows that the relay is adequate for the purpose

of power switching.

The on off switch is rated at 4A at 125V. The voltage that the on off switch will be a

regulated 5V voltage from the 7.4V supply. The 5V voltage will then actuate the 4 relays

connected to the 4 power sources.

80

Project Schedules

Fall Gantt Chart

83

Figure 50: Fall Gantt Chart

84

Spring Gantt Chart

<I

86

Figure 51: Spring Gantt Chart

87

Design Team Information The list below consists of the design team members and the responsibilities:

§ Andrew Biddinger, Software Manager, CE

§ Nathaniel Fargo, Archivist, EE

§ Megel Troupe, Team Leader, EE

§ Roger Zhang , Hardware Manager, EE

Conclusion and Recommendations

The surveillance robot will be designed to deliver a reasonable level of efficiency and

simplicity, providing each user with a streamlined user experience. The surveillance

robot is aimed at providing monitoring inclusive of vision, motion, fire, and carbon

monoxide with limited setup. The surveillance robot can be customized to fuse

seamlessly to any home, apartments or multi-dwelling units. Based on modular designs

and complete scalability, the surveillance robot is designed to be expandable and allow

for future home control upgrades, thus enhancing the protection of your home as time and

lifestyles change.

88

References [1]Ruifeng Li and LijunZhao.“The Development of a General Type of Security

Robot“.International Conference on Robotics and Biomimetics.December 15 -18, 2007.

(http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&arnumber=4522133&openedRefin

ements%3D*%26filter%3DAND%28NOT%284283010803%29%29%26pageNumber%

3D11%26searchField%3DSearch+All%26queryText%3Drobot).

[2]Tomohiro Uchimoto, Sho’ji Suzuki and Hitoshi Matsubara.“A method to estimate

robot’s location using vision sensor for various type of mobile robots.”

(http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&arnumber=5174771&openedRefin

ements%3D*%26filter%3DAND%28NOT%284283010803%29%29%26pageNumber%

3D21%26searchField%3DSearch+All%26queryText%3Drobot)

[3]Jang M. Lee, M. Y. Han, B. H. Kim, M. H. Lee, K. Son, M. C. Lee, J. W. Choi, and S.

H. Han.“A Study on Pose Determination of a Mobilemask Robot for Manipulating Using

Active Calibration Method.”Proceedingsofthe1999 IEEVRSJ International Conference on

Intelligent Robots and

Systems.(http://ieeexplore.ieee.org/search/srchabstract.jsp?tp=&arnumber=811734&open

edRefinements%3D*%26filter%3DAND%28NOT%284283010803%29%29%26pageNu

mber%3D5%26searchField%3DSearch+All%26queryText%3DRobot)

[4] Sridhar Lakshmanan, Vin Joe Varghese, Narasimhamurthi Natarajan. “Miniature

surveillance robot” (http://www.google.com/patents/US7436143)

[5] U.S. Consumer Product Safety Commission. Carbon Monoxide Questions and

Answers CPSC Document #466. (http://www.cpsc.gov/cpscpub/pubs/466.html)

surveillance robot - ua home robot project design ... abstract (nathaniel) this project attempts to...

Documents