Tallinn University of Technology

TallinnUniversity of Technology

Department of Mechatronics

Firefighter SAM

Mechatronics (MHK0030)

Tallinn 2006

Table of contents

1Abstract

2Kokkuvõte eesti keeles

3Introduction

4The Task

5Ideas

6Problems

7Specification

7.1Product idea

7.2Functional requirements

7.3Behavior

7.4Limitation

7.5Time schedule

7.6Block diagram

7.7Data flow

8Mechanics and Robot Body

9Motors

9.1Servo parameters

9.2Motor configuration

10Sensors

11Electronics

11.1Connection schematics

11.2Bill of Materials

12Programming

12.1Programming environment

12.2Algorithm

12.2.1Moving

12.2.2Finding the candle

12.2.3Blowing the candle

12.3Code

13Conclusions

13.1.1Conclusion of Märt

13.1.2Conclusion of Margus

13.1.3Conclusion of Sulev

14References

Appendix 1: Source code

1Abstract

Current documentation is compiled as a part of mechatronics course held in Tallinn University of Technology. Main objective of the course was to build a firefighting robot, which is able to find candle from known maze and stop the fire. To see exact task, please the appendix. Team consisted of three persons - one was responsible of software, second was responsible for mechanics and third was responsible of electronics. Important milestones were 21.09.2006 for idea presentation. 12.10.2006 for presentation of first solution, where our robot was able to move. 09.11.2006 was milestone for prototype presentation where nothing much was different from 12.10.2006. At the same date with Robotex contest on 24.11.2006 there was held contest between course members. Robot was able to move in the maze but it couldn’t find the candle.

Team met at least twice a week. Protocol was written after meeting where important decisions were marked down (given also in appendix). Team members used forum for communication. For creating the documentation there was WIKI style homepage used.

At first the task didn’t seem very difficult. After we have started working on the system we found out that algorithm for moving along the wall was already a difficult task.

It must mentioned, that teamwork is also very important. Although each team member worked hard for the target, robot couldn’t succeed with the task on 24-th of November.

2Kokkuvõte eesti keeles

Tallinna Tehnikaülikoolis, Mehhatroonika (MHK0030) aine raames tuli luua “Firefighter” robot. Vaata ülesande püstitust lisast, töö lõpus. Meeskond roboti loomiseks koosnes kolmest liikmest, kus üks oli vastutav tarkvara, teine mehhaanika ja kolmas elektroonika eest. Olulisemad tähtajad olid 21.09.2006, kus toimus ideede presentatsioon. 12.10.2006 toimus esmalahenduse demonstratsioon, kus käesoleva töö käigu valmistatav robot suutis liikuda. 09.11.2006 toimus prototüübi presentatsioon, kus roboti tarkvara oli pisut täiendatud, kuid midagi suurt ei olnud lisatud. Robotexi võistlusega samal päeval, 24.11.2006 toimus võistlus kursuses osalenute vahel, kus loodud robot suutis ruumides ringi liikuda, kuid küünalt leida ei suutnud.

Meeskonnatöö käigus saadi vähemalt 2 korda nädalas kokku. Kohtumiste kohta kirjutati tavaliselt ka protokoll, kust oli võimalik välja lugeda kokkulepped jms. Suhtlemiseks kasutati foorumit, kuhu said kõik meeskonnaliikmed enda ideed kirja panna. Dokumentatsiooni loomiseks kasutati WIKI keskkonda.

Küünlakustutamise ülesanne ei tundunud esialgu väga keeruline. Olles aga reaalselt süsteemi looma hakanud selgus, et näiteks algoritm roboti mööda seinaäärt liikumiseks on juba raske luua.

Suur roll kogu ülesande edukaks täitmiseks on meeskonnatööl. Iga meeskonna liige andis endast kõik, et robot täidaks talle ette antud ülesande. Kahjuks 24-ndal novembril temale roboti jaoks seatud ülesanne jäi täitmata.

3Introduction

4The Task

The task for robot is to find a candle in a maze and blow it. Exact maze layout is known and given in the specific task description (see appendix). Money which can be used for robot parts is limited. Size of the robot is also limited.

5Ideas

Idea of our team about the robot is as following:

Move along walls using IR distance sensors and Ultra Sonic sensors;
Find the candle, using IR photo diodes;
When candle has been found then blow it with ventilator.

6Problems

Following problems occurred when robot was implemented:

It is not easy to make 90 degree turns as motors act differently in different situations;
Finding candle with an IR photo diode is not possible because of IR noise from surrounding environment (people, light bulbs etc)
It is difficult to find a room as there is no wall which leads into the room;
Time planning is more important then it may seem, even when we thought we have working and realistic time schedule, at the end of the course it just stopped working.
Temporary things tend to live forever. Until they break, stop working or just cause major loss of time when debugging (bad cable connectors, lots of open wires)

7Specification

7.1Time schedule

Group gathered together at least once a week, usually 2-3 times per week. On every first meeting of the week we set up tasks and checkpoints for upcoming week and analyzed last week's progress.

Tasks and actions of the 1. week (week 38, 18-24 September):

Set up communication channel (phpBB forum)
Familiarize with AVR Kit and Atmega128
Check out possible motor variants
First tests with fan and candle
Set deadline to 8th of November

Tasks and actions of the 2. week (week 39, 25 September - 1 October)

Modify servos & first experiments with PWM and servo motors
Make robot body and wheels out of acrylic

Tasks and actions of the 3. week (week 40, 1 - 8 October)

Motors, wheels and body assembled
Robot is able to move, no intelligence or sensors yet
Software development
First problems with supply voltage, common ground and servo interference

Tasks and actions of the 4. week (week 41, 9 - 15 October)

Read and act according to sonars and IR sensors
Balance and stabilize robot
Common ground and supply voltage problems somehow solved
Find and order IR sensors for flame detection

Tasks and actions of the 5. week (week 42, 16 - 22 October)

First signs of stagnation, quite quiet week, mostly some brainstorming
Some supply board improvements (5V regulated voltage)
Software development

Tasks and actions of the 6. week (week 43, 23 - 29 October)

Some software developement

Tasks and actions of the 7. week (week 44, 30 October - 5 November)

Software development, dealing with serial communication for debugging

Tasks and actions of the 8. week (week 45, 6 - 12 November)

Robot presentation
Dealing with I2C communication (sonar uses I2C)
Serial communication working
Mount and wire all the sensors

Tasks and actions of the 9. week (week 46, 13 - 19 November)

Software development
Fan switching circuit

Tasks and actions of the 10. week (week 47, 20 - 26 November)

Changed most of connectors
New supply and fan switching circuit
Fan mounted
Tried several wall-fallowing algorithms
Robot is now in needed dimensions
Demo run at Robotex - did not find the candle

Tasks and actions of the 11. week (week 48, 27 November - 3 December)

Touch sensors mounted
Code improvements and documentation

7.2Block diagram

Simple block diagram of created robot is given on picture below.

Figure 1Block diagram of robot

Where abbreviations of inputs are as following:

US - Ultrasonic (distance sensor)
IR dist. - Infrared (distance sensor)
IR - Infrared photodiode for candle detection
Touch - touch sensors for impact detection

Abbreviations of outputs are as following:

servo - servo motors used for moving
LED - light emitting diode for showing that robot is alive
UART - RS-232 port used for debugging the SW
LCD - liquid crystal display for debugging purposes
VENT - fan to extinguish the fire

7.3Data flow

Input dataflow diagram is given on the picture below.

In robot SW the timer is generating interrupt after 1000 controller ticks. When the interrupt has been generated then time of the timer is looked. When the timeout for IR distance, IR photo diode or ultrasonic sensor has been reached then the measuring of the signal is started. ADC input values are pushed into channel_buffer array which is working like FIFO. Use of the buffers is as following:

Channel_buffer[0] – LEFT_DIST_SENSOR;
Channel_buffer[1] – RIGHT_DIST_SENSOR;
Channel_buffer[2] – LEFT_CNDL_SENSOR;
Channel_buffer[3] – RIGHT_CNDL_SENSOR.

Ultrasonic measurement values are inserted into FIFO uh_channel_buffer.

When touch sensors indicate collision then left_touch or right_touch values is set to TRUE.

When timer generates interrupt it always increases the time in time value buffers time_high and time_low. There are two buffers used for counting time as one value. Time low counts the tick of micro-controller. Time_high is increased after time_low buffer overflow.

PE6 port is set high for starting the ventilator to blow the candle off.

For controlling the motors the different PWM duty cycle is set using following registers:

OCR1A – RIGHT_SERVO;
OCR1B – LEFT_SERVO.

8Mechanics and Robot Body

The main idea behind developing the robot mechanics was to keep everything as simple as possible. Also all mechanics had to be improvable (adding and removing different parts with no further damage to the rest of mechanics).

Robot main body parts were built of plexiglas which were cut out with the help of the CNC machine. CNC was used because of the good output quality. CNC used CAD drawings as the input and this made easier to get quickly new body if necessary. The body drawing is shown on the Picture 1, which shows the body from top view. All the necessary holes for different sensors, AVR, servos and fan are shown on this picture.

The initial competitions rules made some boundaries for developing the mechanics, the robot had to fit in the tube of diameter 150mm and height 100mm. Also the weight had to be less than 1200 grams. The robot bottom side was round but the sides were cut off, otherwise the robot would not fit to the boundaries. Sides cut also made connecting the wheels easier. The wheels are made of plexiglas and are controlled by the servo motors. The wheels were covered with tape which removed the slickness. Servo motors came with special connectors so the connecting motor with wheel was easy. The motors were connected under the bottom of robot with the help of plexiglas joints which were fitted to special holes in the robot bottom (Picture 1). The joints and motors were connected with bolt and nut. Robot body was supported with two static feet. With the help of these feet, the robot would always be in balance. The AVR kit was connected to the body with 4 spacers so the kit is about 10mm from bottom of the robot.

Picture 1. The top view of the robots body

Picture 2. The side view of the robots body with sensors, AVR and fan

On picture 2, it is shown the placement of the sensors. This picture is from one side and gives overview of the placement of different parts of the robot. The IR distance sensors on the sides were connected with metal strip which had holes in it so the position of the IR sensors is easy to change by connecting the sensor with bolts to different holes. Ultrasonic sensor on the front of the robot is connected with spacer. The candle detection IR sensors were built in little pipes. The pipes were connected with special metal strip. The IR sensors were built in pipes because the idea was to get only direct IR light from candle all the other IR sources light would not reach to the end of the pipes, where the IR diodes were built in. The primal plan was connect the fan (for distinguishing the candle) on the top of the ultrasonic sensor but then the robot would not fit in the tube. So the fan had to connect to the back of the robot, so when the robot detects the candle it has to turn around. The fan propeller is moving in the special gap which was cut inside the Plexiglas(Picture 1), otherwise the robot would not fit to the limits. There were also used touch sensors which were little micro buttons, they were connected to metal strip so that when robot hits the wall on front or on the sides, then the metal strip with button is pressed against the robot body so that the button is switched on and the AVR knows that the robot has rammed the wall.

Picture 3. The real robot

The batteries were in two packages one was for supplying the AVR and the other was for motors. The motor supply package was connected to the bottom of the body between the servo motors, by placing the batteries under the body, the robot is more stable and doesn’t loose it balance so easily. The replacing of motors battery pack is made easy by the basic holding connections. The AVR battery was connected on the side of the AVR with double-sided tape. Because sensors, motors and controller all need different supply voltage a special supply board, this compact board was connected on the other side of the AVR. All the mechanics and joints were as basic as possible. The main reason why we had to keep the mechanics as simple as possible was that there were no mechanical engineer in our team , so we tried to keep everything as compact as we could

The Picture 3 shows the real output of our mechanical engineering skills, this picture is not the final look of our robot but it is almost the same.

9Motors

Servo motors were chosen because they come in full package and it is easy to control them. The full package means that there is not necessity for extra electronics like H-bridge. By connecting the supply wires and the PWM wire from AVR, there is no more further connections needed. The easiness behind controlling servos movements is quite basic. The motors are controlled by the changing PWM. The servo motor has some control circuit and a potentiometer that is connected to the output shaft. The potentiometer gives information about the current angle of the motor. If the motor is on the needed angle then the motors shuts off. But when the angle is not right then the control circuit commands motor to turn as long as the right angle is achieved. The angle which has to achieve is given by the PWM from AVR. The servo expects to see a pulse every 20 millisecond. The length of the pulse determines how far the motor has to turn. A 1.5 millisecond pulse means that motor wants to achieve 90 degree. If the pulse is shorter than 1.5 millisecond then the motor has to move to 0-90 degrees, if pulse is longer than 1.5 the achievable angle will be between 90-180 degrees. But the problem is that the standard servo is not meant to use to make a full turn, so it would not have any use in our project, if it wouldn’t be hackable. The idea behind hacking servo is to make the potentiometer to be always with one position so the control circuit would think that right angle is not achieved and so the motor goes around. The servos potentiometers were replaced with voltage divider (two same resistors, this means that the achievable angle is 90 degrees), so the control circuit thinks that 90 degree is not achieved yet, so it commands the motor to go around. Also a tab on the gear surface was removed to make possible for gear to make a full turn. By hacking we can use servos like usual DC motor, but with the difference that the motor is controlled by the PWM.

9.1Servo parameters

To find out the duty cycle for stop, there were several attempts executed.

RIGHT_SERVO : it was found out that motor stopped when OCR1A was set to 2484.

LEFT_SERVO : it was found out that motor stopped when OCR1B was set to 2510.

9.2Motor configuration

Idea was to find out timeouts, how long robot has to turn to get 180 degrees. Another target was to find out the motors speed.

It is possible to control the robot using HyperTerminal on PC. Feedback can be read from the HyperTerminal. I sent the command (TURN_RIGHT) to show the time to USART and start turning. When I sent command (STOP) then another timeout was shown on USART and robot stops. Time between these two events shows us the required time for 180 degrees turn.

'''Measure, HOW fast robot turns.'''

1) Press Forward ('a') - TIMER = 241, 241

2) Press STOP ('x') - TIMER = 241, 639

This means that 398 units. The angle was 180 degrees.

'''Measure, HOW fast robot moves.'''

1) Press Forward ('w') - TIMER = 6, 853 - 00:00:00 (mm:ss:msec)

2) Press STOP ('x') - TIMER = 12, 122 - 00:23:20 (mm:ss:msec)

This means that 6853 units = 00:00:00 and 12122 units = '''00:23:20'''. The length of the road was 281,5 cm. This means that robot moves 0,12 m/sec.

10Sensors

The final version of our robot uses 4 types of sensors.

1)IR-distance sensors: The plan was to use IR-distance sensors for detecting how far the robot is from the side walls. With the help of metallic strips two IR Sharp Long Distance GP2Y0A02YK (Picture 4-1) were mounted on the both sides of robot. These IR distance sensors consist of IR transmitter and IR receiver. The transmitter sends all the time out an IR beam which reflects from the walls, and the reflected IR is received by the receiver. The length between the wall and receiver is detected by the reflected beams angle(Picture 4-2).. The less the angle is the nearer the wall is and vice versa. The output of the sensors read by the A/D input of AVR and we can detect how far the wall is. These sensors give out creditable results between 20 and 150cm. These sensors were very useful until the robot was so far that we could put it in the maze, the problem was that in some corridors the walls were too close (less than 20cm), and so the output of a sensor is not accurate. Also we managed on the last week to supply one of the sensors with reverse voltage and after that the sensor was out of order. Fortunately we managed to get new Sharp IR sensor GP2D12(Picture 4-3) which saved our both problems, because this sensor range is between 10- 80cm, so we could even move in this narrow corridor without any big problems. The GP2D12 works on the same principle only in other distances.