Fire Fighting Robot

The main aim of the project is to build an autonomous vehicle (robot) that can detect a fire source, move towards it and extinguish the fire.

Major Components:

 

Arduino Uno, H-bridge circuit (L293D) – 2 nos. , IR photo diodes – 2nos. for detection, Fire sensor – 1 No (Can be another IR photodiode) and a Fan

Principle:

Fire sensors:

The spectral characteristics of the fire source depends on the source (or the burning material) of the fire. Most common fire sources emit radiations in the IR region of the spectrum and sensors that can sense radiations in this region can serve ideally for the purpose of detecting them.

Typical IR photodiodes have their sensitivity to be very high in the region from 870nm to 950nm wavelength, with daylight blocking filters to prevent any false triggers due to sunlight. These serve us ideally for fire detection purpose.

In this project, we intend to use three IR sensors –

Two on either sides in the front of the vehicle (Detectors) – This is for the initial fire detection and also for the purpose of guiding the vehicle in the direction of the fire source.

One in the centre with a high threshold (Activator) – This acts as a trigger for detecting the proximity of the fire and to take action (in our case switch on the fan) to extinguish it.

Controller:

An Arduino Uno is used here for controlling the robot. The main functions of the controller would be:

1. Initially be in scanning mode until any of the Detectors sense radiation.

2. Guide the vehicle by controlling the Left and Right motors based on the analog voltage levels from the Detectors.

3. When the fire source is close by, align the vehicle such that the fan faces the source (i.e the Activator is aligned to the fire). The Activator output is connected as an interrupt source to the Controller. Hence the extinguishing of fire takes place as part of the Interrupt Service routine (ISR)

4. Switch on the fan until fire is extinguished. H-bridge circuits are used for the purpose of motor and fan controls.

5. Return to scan mode

Circuit Diagram

Sensor Circuit:

1. The Value of R1 and R2 can be tuned based on the sensitivity requirement.

2.The 5V and GND can be derived from Arduino Uno board pins for convenience.

3. ANALOG_INPUT_LEFT, and ANALOG_INPUT_RIGHT can be any two analog pins on Arduino, say Analog 0, and Analog 1.

Fire Detection Circuit using Infrared Sensors

Flow Chart:

Algorithm for the Main Program

Interrupt Service Routine on detecting the Fire

 

Parsing GPS NMEA navigation message

A GPS receiver communicates its navigation solutions to the external world through a standard protocol. This protocol is a subset of the NMEA-0183 standard for interfacing marine electronic devices as defined by National Marine Electronics Association (NMEA). The NMEA reference manual provided along with each GPS receiver provides the details of the standard messages sent out by the particular receiver. Here we give an extract of a few basic messages that are essential for reading the PVT (Position, Velocity, and Time) solution.

Click Here for Introduction to GPS and How does a GPS Receiver Calculate Range from Satellites

The following table lists the entire set of NMEA messages related to GPS receiver and the information that they convey – 

Message Name	Information Contained
GGA	Time, Position, and Fix type
GLL	Latitude, Longitude, and UTC time of fix with status
GSA	Receiver operating mode, satellites used, and DOP
GSV	Number of satellites, elevation, azimuth, and SNR
RMC	Time, Date, Position, course, and speed
VTG	Course, and speed relative to ground
ZDA	PPS timing

Most of the receivers provide an option to enable / disable each of these messages depending on the bandwidth and data rate limits.

A typical GPS logs read from the receiver would be similar to this –

............................................................

............................................................

$GPGSV,3,1,12,04,64,168,27,17,50,004,32,28,42,059,40,08,34,149,22*75

$GPGSV,3,2,12,02,28,202,18,27,27,320,22,26,25,235,16,15,13,273,*7B

$GPGSV,3,3,12,09,12,323,26,10,10,163,39,07,08,149,25,20,04,075,*78

$GPRMC,125535.281,A,1908.0906,N,07254.3485,E,000.0,000.0,290611,,,A*6C

$GPVTG,000.0,T,,M,000.0,N,000.0,K,A*0D

$GPGGA,125536.281,1908.0906,N,07254.3485,E,1,07,1.4,33.2,M,-65.1,M,,0000*4F

$GPGSA,A,3,28,17,07,10,09,27,04,,,,,,2.0,1.4,1.5*33

............................................................

............................................................

In the current discussion, we shall only consider RMC and VTG messages, since these two messages contain the PVT solution required.

RMC – Recommended Minimum Specific GNSS Data:
$GPRMC,125535.281,A,1908.0906,N,07254.3485,E,000.0,000.0,290611,,,A*6C

Name	Example	Unit	Description
Message ID	$GPRMC		RMC protocol header
UTC Time	125535.281		hhmmss.sss
Status	A		A = valid; V = Not Valid
Latitude	1908.0906		ddmm.mmmm
N/S Indicator	N		E = East; W = West
Longitude	07254.3485		dddmm.mmmm
E/W Indicator	E		E = East; W = West
Speed Over Ground	000.0	Knots
Course Over Ground	000.0	Degrees	True
Date	290611		ddmmyy
Magnetic Variation*	12.123	Degrees
E/W Indicator	E		E = East; W = West
Mode	A		A = Autonomous, D = DGPS; E = DR**
Checksum	*6C
<CR><LF>			End of message

VTG – Course Over Ground and Ground Speed

$GPVTG,000.0,T,,M,000.0,N,000.0,K,A*0D

Name	Example	Unit	Description
Message ID	$GPVTG		VTG  protocol header
Course	000.0	degrees	Measured Heading
Reference	T		True
Course	005.6	degrees	Measured Heading
Reference	M		Magnetic
Speed	00.1	knots	Measured Horizontal Speed
Units	N		Knots
Speed	00.2	km/hr	Measured Horizontal Speed
Units	K		Kilometers per hour
Mode	A		A = Autonomous, D = DGPS; E = DR**
Checksum	*0D
<CR><LF>			End of message

* Magnetic variation data may or may not be supported in all the receivers

** DR = Dead Reackoning

Reading NMEA messages and displaying on LCD:

Two approaches can be taken to read the NMEA message through serial port and displaying them on the LCD screen , each method having its own merits and demerits –

1.  Interrupt based architecture (Process function as a background process)

In this method, we keep filling a global circular buffer, say

Rx_buffer[MAX_GPS_BUFFER_SIZE]

in the ISR. As an example an ISR written for ARM 7 processor reading GPS from UART0 is given here -

void Uart0_ISR(void) __irq

{

     char read_byte = 0;

     read_byte = U0RBR;

     Rx_buffer[Rx_buffer_pntr++] = read_byte;

     if(Rx_buffer_pntr >= MAX_GPS_BUFFER_SIZE)

     {

           Rx_buffer_pntr = Rx_buffer_pntr - MAX_GPS_BUFFER_SIZE;

     }

     VICVectAddr = 0;

}

The value of MAX_GPS_BUFFER_SIZE depends on the processing time of the foreground processes i.e. how often is the Rx_buffer checked for received bytes.

This approach is best suited for environments where many processes need to run in parallel. But it requires relatively large memory space to store the received bytes.

2. Polling based architecture (Processing function as a foreground process)

In this method, no other background process can be run along with message parsing. Here the program keeps polling the interrupt bit after receiving each byte. As an example, let us look at a 8051 based implementation, where the program polls each byte and waits until a $ is received –

while (1)

{

while(RI != 1);RI = 0;

if(ASCII_DOLLAR != SBUF)

{

continue;

}

....

....

....

}

This approach is suitable for small projects where the memory available is very small (e.g. in case of 8051, only 128 bytes is available for data) and GPS message reading is the only process running.

Steps to Parse NMEA messages

i.              Identify “$GP” symbol, which signifies the start of the message

ii.             If the characters that follow $GP are “RMC”, then go to the parsing function for RMC. Similarly if it is “VTG” go to the processing function for VTG.

iii.            In each of the messages, use comma (,) as the separator for the values to be extracted.

iv.            The message delimiter is identified as an asterisk symbol (*) which is followed by the checksum. The checksum in the message is an exclusive-or of all the bytes received between $ and *, not including both.

The last two bytes received after * represent the two nibbles of the 1 byte check sum.

Consider the following message –

$GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*48

Checksum = (ASCII_G) XOR (ASCII_P) XOR .... so on up to ... (ASCII_K)

If the message is received properly, the Checksum must read 0X48. Once the checksum passes, copy the values of Longitude, latitude, time and Velocity to corresponding buffers for display on LCD. 

Click here for C-code Interfacing 8051 with LCD and Geolocation Tracking with GPS and GSM project

GPS Interfaced with 8051 showing Latitude and Longitude



GPS Interfaced with 8051 showing Velocity and Time

Bluetooth Controlled Car via Android

The main objective of this project is to build a car that can be controlled from an Android app via bluetooth communication.

The project consists of two modules

1. The Car

It consists of a 8051 micro controller interfaced to a Bluetooth module via a serial port. The Bluetooth module receives the commands sent by the Android App. We have commands for the car to move Left, Right, Forward, Reverse and Stop. Based on the inputs the micro controller sends commands to H-Bridge L293D to drive the car in the required speed and direction.

2. The Controller

It consists of a Android phone having the hardware support of Gyroscope and Bluetooth. The App detects the orientation of the Gyroscope and sends appropriate commands to the car via the Bluetooth in the phone. The application is fixed in Landscape mode and we use the two axes of the gyroscope i.e the heading and the roll for the operation. Heading is used to detect Left/ Right while Roll is used for Forward/Reverse/Stop. The compass on the screen conveniently shows the direction in which the car is supposed to move.