An investigation into robotics for
application in hazardous
environments using Lego
Mindstorms.
Simon Wozniak.
BSc (Hons) Computer Science.
2001/2002
The candidate confirms that the work submitted is their own and the appropriate credit has
been given where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be
considered as plagiarism.
(Signature of student) _______________________________
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Summary
Modern battlefields are littered with unexploded weapons and mines. These need to be
removed to allow ordinary civilians to live without risk of injury or death. Many military and
civilian personnel have been killed and injured whilst engaged in this process, proving the
requirement of a system which can perform this task without risk to human lives
This project aims to investigate the techniques and methods behind creating a robot that
could conceivably perform such a task, using the Lego Mindstorms Robotics kit.
BSc Project Report
i
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Acknowledgements
I would like to thank my Supervisor, Professor Tony Cohn, for all his help and
encouragement throughout this project. I would also like to thank the guys in my project
group for exchanging ideas and parts. Finally I would like to thank all my friends for helping
me throughout, and checking my project once finished.
BSc Project Report
ii
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Contents
1. Introduction
1
1.1 Introduction to Lego Mindstorms
1
1.2 Report Overview
1
1.3 Objectives
2
2. Background
2
2.1 General Background
2
2.2 Requirements of the Robot
3
2.3 Evaluation of hardware
4
2.3.1 Computer Hardware
4
2.3.2 Robot Construction
4
2.4 Evaluation of Software systems to program Robot
9
2.4.1 Alternative languages
9
2.4.2 Different Software development methodologies
11
2.4.3 Analysis of Search Algorithms
13
3. Design
15
3.1 Hardware
15
3.1.1 Chassis
15
3.1.2 Grabber Arm
17
3.2 Software
18
3.2.1 Search Algorithm
18
3.2.2 Control Program
20
3.2.3 Software Development Methodology
21
4. Implementation
4.1 Hardware
22
22
4.1.1 Chassis
22
4.1.2 Grabber Arm
23
4.2 Software
24
4.2.1 Search Algorithm
24
4.2.2 Control Program
24
5. Evaluation
26
5.1 Evaluation of different sensor positions
26
5.1.1 Evaluation of position of light sensor
26
5.1.2 Evaluation of position of touch sensors
28
5.2 Evaluation of performance on minimum requirements and enhancements
BSc Project Report
30
iii
An investigation into robotics for application in hazardous environments using Lego Mindstorms
5.2.1 Experiment 1: Sense and pickup object
31
5.2.2 Experiment 2: Return to start position
32
5.2.3 Experiment 3: Measure Length and Width
33
5.2.4 Experiment 4: Test Manual Control
36
6. Conclusion and Possible further developments
38
6.1 Overall Conclusion
38
6.2 Further Work
39
APPENDIX A – Personal Reflection on the Project.
40
APPENDIX B- Final Hardware design.
41
APPENDIX C- Final program.
46
Bibliography
51
BSc Project Report
iv
An investigation into robotics for application in hazardous environments using Lego Mindstorms
1.Introduction
1.1 Introduction to Lego Mindstorms
The Lego Mindstorms Robotics Invention System is based on established Lego Technics
technology. This system enables you to design, build and program real robots with the ability
to move, act and ‘think’ on their own. The core of the system is the RCX; an autonomous
Lego microcomputer that can be programmed using a PC. The RCX basically serves as the
“brain” of the robot by using sensors to record data from the environment, processing this
data and signalling output motors to turn on and off as a result.
The way this system works is simple; firstly you design and build your robot, then you create
a program on your PC using the supplied RCX Code programming language (Other
languages and methods can be used, (see Chapter 2.3)). The next step is to download the
program to the RCX using the supplied infrared transmitter. The robot is now ready to
interact with the environment, fully autonomous from the computer. The Lego Mindstorms
Website provides more information and ideas [1].
1.2 Report Overview
Today millions of unexploded weapons litter the battlegrounds of past and present conflicts.
These explosives are highly dangerous and directly affect civilians attempting to rebuild or
go about their lives, thus they must be removed and destroyed. The task of finding and
removing these weapons is even more hazardous, and numerous civilian and military
personnel have been killed and injured in the process. This project is based around the
requirement for an automated system (robot) that can perform this job more effectively and
safely than a human. The military also require such systems whilst engaged in operations,
making such robots a highly desirable technology.
The aim of this project is to produce a robot, built using a Lego Mindstorms kit, that will
mimic human behaviour on a low-level by autonomously searching a room for an object,
picking it up, and bringing it back to the starting position. The robot will be able to process
information about its environment that it has measured using on-board sensors to aid its
search. The ultimate intention is to build a robot of the kind that could remove human risk
from dangerous environments such as war-zones. Due to the limitations of the kit, this robot
will not have sufficient capabilities to operate in such a way, but will provide a representation
BSc Project Report
1
An investigation into robotics for application in hazardous environments using Lego Mindstorms
for testing software design and implementation methodologies, as well as analysis of
algorithms and code for future, similar projects.
The Written report will cover all steps covered within research, design, implementation,
evaluation and conclusion of the project. The background-reading chapter represents the
research done into similar projects and all aspects of the project including hardware and
software. The design chapter will demonstrate how the robot was designed and what
considerations had to be made to allow the robot to accomplish the objectives. The
implementation chapter will provide an overview of how the robot was built and programmed,
with design changes that evolved during this phase. Finally the evaluation and conclusion
will show how the robot was tested, demonstrating parts that worked, did not work, and how
it could have been better implemented.
1.3 Objectives
The basic objectives for this project are as follows:
•
Create a Robot that will be able to respond to user input
•
Create a Program that will automatically guide and control the robot.
•
Write a report on the performance of the Robot.
The intention is that by accomplishing these objectives, much experience and insight will be
gained into the correct methods and techniques that should be used to design and build a
working robot for the real-world application mentioned previously (Section 1.2). This includes
the software and less importantly hardware design methodologies, along with algorithm
design and implementation.
2. Background
2.1 General Background
Lego Mindstorms has not previously been used within the School of Computing. This is the
first year a project of this type has been implemented and so there are no similar projects to
review from previous years, although projects on software engineering in general prove
useful for reference on style.
There are numerous projects on the Web that provide excellent hints on hardware and
software design.
BSc Project Report
2
An investigation into robotics for application in hazardous environments using Lego Mindstorms
One notable project [2] has very similar objectives to the robot to be constructed here and
has proven especially useful for design of the hardware of the robot. This robot, however,
runs on less complex and powerful software than is ultimately needed to accomplish all
requirements here, and so bears little relevance for software design.
The background chapter covers reading and research collated and analysed that is relevant
to this project.
2.2 Requirements of the Robot
The minimum requirements of the robot are set down to provide ‘goals’ to be achieved.
These are as follows:
•
To compile a report on similar projects based on a literature search.
•
To physically build a Lego Mindstorms Robot.
•
To design and implement a program to control the robot.
•
To evaluate the performance of the robot.
•
To write an overall project report.
Possible Enhancements:
•
Create a program that will allow remote switching between Automatic and
manual control of the robot. This will involve sending the robot messages with
commands to implement different programs while it is away from the start
position, allowing the user to choose between manual control, or allowing the
robot to operate and move using its own sensors.
•
Create an additional program that will allow the robot to record the layout of
the environment. This will involve the robot recording information on the
layout of its current environment in addition to retrieving the object. This
would represent a secondary role of reconnaissance in a real-world
implementation.
BSc Project Report
3
An investigation into robotics for application in hazardous environments using Lego Mindstorms
2.3 Evaluation of hardware
2.3.1 Computer Hardware
There is little information provided within literature on the types of Computer hardware that
are in use. The basic assumption made of the computer used is an x86 PC running a
Windows or Unix Operating system. The infrared tower and software required to run the it is
RoboLab (See 2.4.1) which will run on any Pentium PC and above, installing easily on all
versions of Windows 95 and above.
The system setup chosen for this project will be a P600 laptop running Windows XP with the
USB-version of the infrared tower. The USB version of the tower has longer range and is
self-powered compared to the standard serial version, which requires a battery. A laptop is
used as this will allow the system and the robot to be portable- evolving the idea for a
deployable robot that can be setup to run anywhere, rather than limited to one place, for
example, next-to a fixed position desktop.
2.3.2 Robot Construction
There are no modules on offer in the School of Computing at Leeds University that cover
practical hardware design and construction. The information here is all collected from
projects on the Web and within the Manual that is included with the Lego Mindstorms kit.
Chassis
The chassis structure is tailored directly to the drive mechanism that is used, with
allowances for strength and ability to support all the components needed. A design that most
closely resembles the type of robot to be built here has already been created [2] with a low,
wide chassis and enough strength to support the RCX, motors, grabber arm and sensors.
The kit only provides two motors that would most likely be used to propel the robot along the
surface it will be operating on. There are two main methods of construction and design that
could be used to build the chassis of the robot, hinging on the type of drive mechanism used.
The first method involves the use of one motor to drive the robot forwards and backwards
(Fig 2.1). This motor is fixed in position to simply drive the left and right-rear wheels forwards
and backwards.
BSc Project Report
4
An investigation into robotics for application in hazardous environments using Lego Mindstorms
The second motor is used to steer. This is accomplished by connecting it to a rod that it
moves left and right, causing the wheels to tilt and altering the direction of travel of the robot.
WHEEL
COG
TEETH
DIRECTION
OF MOTION
Fig 2.1: Standard drivetrain layout
This method is very similar to the drive system used in most automobiles. The advantages to
this method are that it follows conventional design, and so there will be numerous versions
to analyse and use. This method is also efficient and will travel quickly as no energy is lost
during turning, as all wheels work with each other (in the same direction). The method can
only be used with standard wheels because they have to be able to operate independently.
A tricycle arrangement could, alternatively, be implemented with one wheel steering at the
front or driving at the back.
The second method has each motor driving a separate side of the robot (Fig 2.2). To go
forwards, both motors are switched on at the same speed for the same amount of time, and
motor direction is reversed to go backwards. For the robot to rotate left, the right motor is
switched onto forward, and the left onto reverse, the opposite applies to turn right.
BSc Project Report
5
An investigation into robotics for application in hazardous environments using Lego Mindstorms
CATERPILLAR
TRACK
DIRECTION
OF MOTION
Fig 2.2: Caterpillar tracked drivetrain layout
This method is much simpler to implement than the previous method, and can be used with
caterpillar tracks as well as standard wheels, making it more versatile. It is however, slightly
less efficient, as when turning the tracks are working against each other, negating some of
the power output from the motors, but the turning circle is much tighter; it can turn on the
spot. This makes it better-suited to this application, as for obstacle avoidance and object
retrieval in enclosed areas these precise movements can mean the difference between
survival or destruction.
Pick-up Mechanism
The pick-up mechanism is slightly more complicated to design and build than the chassis.
There will only be one motor available for this mechanism, meaning it will have to move in
two directions under one motor- the pincer arms moving together to grasp the object, and
the arms moving up to lift the object once it has been secured.
There are two basic methods identified for this mechanism, the first is based on that
implemented on the Fetchbot [2]. This design is very efficient, using cams to control the
vertical motion of the arm, and gears to operate the swinging motion of the grabber.
BSc Project Report
6
An investigation into robotics for application in hazardous environments using Lego Mindstorms
This design allows a firm grasp of the block, as the motor will keep closing the grabber until
sufficient resistance is detected, then transferring the power to the vertical motion of the arm,
lifting the object up.
Fig 2.3: Grabber arm design
The diagram (Fig 2.3) shows the various stages in operation of the arm. Top left is the arm in
relaxed position, with no force applied. Top right shows the arm in closed position, after the
motor has been switched on forward, the arm has closed and been lifted up by the cams.
Bottom right demonstrates the reverse position, where the motor is switched in reverse and
the grabber opens and lifts up.
The second version of the grabber arm, involves using a ‘worm gear’ [3] (Fig 2.4). This gear
moves along an axle, applying rotation to one set of cogs when the motor is switched on.
When the motor is reversed the worm gear slides across the axle, disengaging one set of
cogs and transferring power entirely to the other set. This means that, depending on the
direction of the motor, two different directions of movement can be implemented using one
motor. The disadvantage with this method is that it is larger and slower to operate than the
other design because it requires more gears and connectors between the differing axles.
BSc Project Report
7
An investigation into robotics for application in hazardous environments using Lego Mindstorms
There is also a period when the worm gear is moving along the axle when it is not turning
any cogs, thus being inefficient.
Fig 2.4: Worm gear design[3]
Sensors
There are varied examples of sensor placement and configuration to consider. The first
major area involves detection of the object.
The Fetchbot [2] example uses a light sensor to detect the object. The idea here is that the
light sensor will be reading a constant value for light, until the object passes under its’
downwards pointing sensor. The light reading will then fluctuate, telling the robot that the
object is present and to engage the grabber mechanism. The problem with this method is
that it relies on the object being a different colour to the floor or background, in order to
acquire a different reading. The light reading is also heavily affected by ambient light
conditions within the operating environment, so the reading of a particular object may be
different with natural light to artificial light. This means that unless threshold values within the
program can be changed, the robot may not detect the object at all. The major advantage in
favour of using the light sensor, is that when the threshold is set correctly to the environment
(within the program), it is very efficient at detecting the object.
An alternative method of detecting the object involves using a touch sensor as a mini
bumper [4] that is pushed in when the object touches it, telling the robot that the object is
present and to engage the arm mechanism. This design is reliable as it will consistently
detect the object (it being very difficult not to activate the sensor if the object is there), and is
not dependent on external conditions such as light or operating surface to work.
BSc Project Report
8
An investigation into robotics for application in hazardous environments using Lego Mindstorms
The major problem is that it can only detect the object when it is touching the bumper,
meaning there could be parts of the bumper in the way of the grabber when it operates
rendering grabber design less flexible.
The next sensor to consider is the rotation sensor. This measures the number of rotations
completed by an axle; sixteen counts per full rotation. This can be used to work out
distances by taking a simple formula which will divide the total rotation sensor reading by
sixteen and multiply it by the distance travelled for one full rotation. There is very little
literature available that describes the implementation of rotation sensors, and that which
does exist is more concerned with creating ‘home-made’ sensors.
The touch sensors work as a type of switch; they have a button on the front that is held in
the out or ‘off’ position by a spring, sending the RCX a Boolean reading of false. When this
button is pressed the sensor sends a true to signify ‘on’. The common use for these sensors,
other than to detect objects as mentioned previously, would be to stop the robot when it
comes into contact with walls and obstacles.
2.4 Evaluation of Software systems to program Robot
The most important part of the implementation for the robot concerns the program that will
be written to control it. The first thing that had to be done was look at the available
environments with which it could conceivably be programmed. Various sites contain
information on the languages compatible with the Lego RCX.
The RCX stores and runs the programs, processing inputs from the sensors and outputting
to the motors. The robot is built around this programmable block.
2.4.1 Alternative languages
RoboLab
RoboLab [5] is the software supplied with the Mindstorms kit that allows rudimentary
programming and control of the RCX. It is basically an icon-based, diagram-building
programming environment. The user simply drags and drops the commands to control the
robot into a table, and this is downloaded to the RCX. This software has limited functionality;
being designed for children.
BSc Project Report
9
An investigation into robotics for application in hazardous environments using Lego Mindstorms
There is no provision for variables, and commands are limited to those supplied with no
extra use of operators. The program is entirely graphics based with no standard text input for
programming. This software would not be capable of achieving the stated goals and
requirements.
LegOS
LegOS is described as ‘an open-source embedded operating system for LEGO Mindstorms,
to be downloaded to the RCX. Compared to the standard software, it offers vastly superior
performance and flexibility’ [6]. LegOS offers a graphic interface similar in concept to that of
RoboLab but with several important additions including;
•
Pre-emptive multitasking- for division of processor time between different tasks.
•
Dynamic memory management- for allocation of memory between different
processes.
•
Dynamic loading of programs and modules- for efficient loading of tasks and
programs within the RCX.
•
Full IR packet networking- downloading of data to the RCX.
•
Drivers for all RCX subsystems- provision for recognition of additional sensors and
add-ons
This system does provide improvement over the basic RoboLab software, but still has no
provision for variables or advanced operators, again making it too simple for use in this
project.
Visual Basic
Visual Basic provides a flexible programming environment for the RCX that allows the
creation of graphical displays to control the robot and its associated functions. There is full
provision for variables and operators as the language used is actually Visual Basic rather
than a language loosely based on it. The main disadvantages to using Visual Basic in this
application is that it is generally less capable and powerful than NQC (See below). Visual
Basic also uses less efficient (as well as longer) code compared to NQC for the
implementation of complex algorithms, meaning the finished program would run slower.
BSc Project Report
10
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Not Quite C
Not Quite C [7] is a more complex language with a C-like syntax that can be used to
program the Lego RCX programmable brick, from the Mindstorms set. Preferences among
established programmers generally adhere to using command line interfaces, rather than
dragging and dropping icons. The advantages of this language are that it allows a much
greater level of flexibility; there are provisions for variables and all the functionality that would
be needed. The disadvantages are that as it is based on the firmware that already comes
with the robot (RCX code, RoboLab)- therefore there is no provision for floating-point
support. It is described as ‘Not Quite C’ for this reason, as it has most of the features of the
C-language, but just lacks some of these basic features.
Being a C-style language, this correlates best to previous knowledge and experience of
programming acquired during a degree in Computer Science at Leeds University. C++ is the
language taught primarily to all computing students in their first year, in the modules
introduction to programming 1(SO11) and 2(SO12). C and C++ are also used in later
modules such as Introduction to (SI23) and Advanced (SI31) Graphics as well as ObjectOrientated
Programming
(SO21),
Compiler
Design(CO32)
and
Practical
Parallel
Programming (SO31).
2.4.2 Different Software development methodologies
Investigation into the recognised design processes that could be used to create a solution to
this problem yielded four models [8] identified as: the waterfall model, evolutionary
development, formal systems development, and re-use based development.
Formal Systems Development
This is the most formal process model. The development starts with a complete user
requirements specification that the whole development is based around. Next, the user
requirements are converted into a formal mathematical model of the system, using a
language such as Z. The Mathematical model is transformed into computer code using a
number of steps, and the finished product produced. This process model is very rigid,
meaning any changes to the initial user requirements are difficult to implement once the
design process has begun.
BSc Project Report
11
An investigation into robotics for application in hazardous environments using Lego Mindstorms
The Systems Specification and Design(PS21) module within the School of Computing
teaches this style of design process. This module centres around the use of Z to create a
mathematical model of systems, and gives good insight and experience into the techniques
used in formal development. The use of this model would be inappropriate as the software
does not follow a strict set of user requirements that could be broken down to the correct
level.
The Waterfall Model
The waterfall model was used in one of the modules studied in the second year of Computer
Science, Software project Management (SO22). This process model is structured and not
very versatile if alterations are desired, because every previous stage that has been
completed has to be re-visited and altered accordingly. This model suggests that each stage
is completely finished before the next one begins, yet in practice each stage overlaps the
next one to some degree. The biggest problem with this model is that the user requirements
are identified early in the process. Any changes that need to be made to them later in the
process are difficult to implement as the product has already had a significant amount of
finalization introduced at the end of each stage. The waterfall model would not have the
flexibility necessary for a project of this kind, because there is a definite need to make
alterations to code during the entire process of implementation, in order to synchronise the
software with the hardware.
Evolutionary Development
This could perhaps be best described as rapid prototyping; exemplified by Microsoft when
they were designing Windows 95. The idea behind this process model is that producing
many fast iterations of the product will allow the user to see how the product is developing,
and be able to give immediate feedback on what has and has not been successful. A system
of rapid-prototyping would be more appropriate to this robot, as it would allow creation and
testing of various functions and hardware systems throughout the implementation.
Re-use -Orientated development
Within Software Engineering, it is common to adapt existing code towards another similar
purpose. The re-use orientated approach assumes a large database of pre-existing
modules, like a room full of spare computer parts.
BSc Project Report
12
An investigation into robotics for application in hazardous environments using Lego Mindstorms
The required modules for a project are researched and collected from the database and any
code that is required but not available from the database is written, and then added to the
database at the end of the project. This method reduces the amount of time spent on coding
significantly. There is a large amount of stored programs available on the Web, yet no formal
database, meaning that this method is plausible for this project.
2.4.3 Analysis of Search Algorithms
The importance of algorithms is exemplified by the following:
“like computer science, robotics is fundamentally about algorithms” [9]
The algorithms used to control robots are one of the most important parts of the software
design process. The algorithm must be well-constructed, efficient and as simple as possible,
to make it easy to read and be understood by future users or analysts.
‘The primary goal of a robot algorithm is to describe a procedure for controlling a subset of
the real world- the environment- in order to achieve a given goal’ [9].
There are few examples of algorithms to analyse, but the extraction of the main routines
from a problem can be converted to an algorithm as demonstrated here; [9]
‘Consider the task of orienting a part P on a horizontal table. If a vision system (for instance
a classical 2D binary vision system) is available with the camera looking from above, the
robot can use this sensor to measure P’s orientation. This yields the following sort of robot
algorithm:
1. Determine P’s initial orientation using the vision system.
2. Move the gripper to the grasp position of P.
3. Close the gripper (i.e., grasp P).
4. Rotate the gripper by the difference between P’s initial and goal orientations.
5. Open the gripper (i.e., ungrasp P).
6. Move the gripper to a resting position.’
The example above demonstrates how the problem is split down into its constituent parts,
which represent the operations that have to be carried out.
BSc Project Report
13
An investigation into robotics for application in hazardous environments using Lego Mindstorms
This can then be further split down into pseudo-code; an algorithmic representation. The
next step is to program the algorithm in the language of choice.
Useful templates for search algorithms can be found in the Lego Mindstorms guides [10].
The basic structure of search algorithms designed for Lego Mindstorms robots seems to be
fairly similar judging by actual pseudo-code and interpretation of programs.
For example:
While (Robot has not found object)
Move forward
If (Bumper activated)
Stop
Rotate random angle
If (Object detected)
Stop
Retrieve Object
Return to Start
End
This code obviously represents a simplification of the problem, for example if the robot was
rotating a random angle, some kind of sensor would be needed to record where the robot
was, otherwise it would not be able to return to the start.
The reason these algorithms generally seem to follow this basic pattern is most likely down
to the hardware setup; the sensor’s and motor’s capabilities only really allow for this level of
break-down because of their lack of ultimate flexibility and numbers.
Algorithm design and analysis is extensively encountered whilst studying Computer Science
at Leeds University. The reason for this is that it is an essential part of this subject (See
Quote at top of this chapter). There is an introduction to algorithms in first year in the module
Analysis of Algorithms (CO12). Algorithms are then used extensively in other Computer
Science related modules throughout the degree program. Having an understanding of what
they are, and how to write and use them is essential to the implementation of a successful
robot-control program.
BSc Project Report
14
An investigation into robotics for application in hazardous environments using Lego Mindstorms
3. Design
3.1 Hardware
3.1.1 Chassis
The general design of chassis is intended to provide strength and efficiency, allowing the
robot to operate with a reasonable amount of accuracy based on the data from its sensors.
Basic Design and layout of structure
The focus was on a design that would allow strength, with extensive use of Lego strips to
securely hold the robot together. Lego is designed to come apart easily, therefore the robot
could break under stress unless some support is attached to counter or nullify this force
during operation. To maintain efficiency, the drive-train mechanisms such as wheels and
cogs are projected out from the chassis using spacers (small ‘nuts’ that slide onto the axle).
This means that they will not rub or stick against the chassis, slowing operation and wasting
power.
The RCX is positioned on top of the motors to allow room underneath to house the
mechanism of the grabber arm and thus reduce the length of the robot. Deceasing size and
profile of the robot means it will be able to operate in smaller spaces and will therefore be a
more durable machine. Reducing the length of the robot by moving the grabber arm back
means the centre of gravity is more centralised, and the robot will be more stable, allowing it
to operate with heavier objects without losing balance. Basic Lego bricks are to be used to
fill gaps and increase overall strength. This does provide a slight increase in weight, but is
rendered unimportant by the general durability of the robot.
Drive train
The robot will run on two caterpillar tracks, each one powered by a separate motor. This is
the best method as it provides the robot with a very small turning circle; it can basically spin
on the spot. With reference to the real-world application of such a robot, caterpillar tracks
would be most desirable as they would allow it to operate over more difficult terrain than
wheels, providing more grip, though less speed.
BSc Project Report
15
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Speed is not a major objective, though a reasonable level is desirable otherwise the robot
would take too long and therefore be inefficient and slow at completing it’s tasks. These
caterpillar tracks will be positioned on each side of the robot, extended outwards to enhance
stability. Turning is achieved by alternating the direction of the tracks, for example; to turn
left, the left caterpillar track rotates backwards, and the right track rotates forwards (as
mentioned in section 2.3.2).
Sensor Placement
The sensors will be positioned in order to allow maximum effectiveness and most accurate
readings without impeding the performance of the robot whilst moving.
Touch Sensor (Bumper)
There will be two touch sensors attached to the robot; one pointing forwards to cover
obstacles whilst moving forwards, and one rearwards to cover obstacles whilst reversing.
These will project out from the robot on ‘stalks’ so that they are the first parts to come into
contact with anything in the way, and stop the robot. The sensors work by sending the RCX
a Boolean reading of true or false when they are activated.
The bumpers will be tested to see whether extending the actual position of the switches so
that they are closer to the end of the robot, or extending the bumper that pushes the
switches in will be more efficient. This is recorded in evaluation (5.1.2)
Rotation Sensor
There will be a rotation sensor attached to one of the axles in order to measure the distance
travelled. This sensor works by sending the RCX a reading of 16 for every full revolution it
accomplishes. The sensor is not very accurate but will give a reasonably good reading.
There is little flexibility in position of rotation sensor as it has to be near an axle, although
with the use of gearing it could be positioned elsewhere and even rendered more accurate
by changing the gear ratio so that higher values of rotation will be recorded for each wheel
rotation; however, this is irrelevant as there are limited numbers of gears provided in the kit.
BSc Project Report
16
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Light Sensor
The light sensor will initially be positioned on the end of the grabber arm, pointing
downwards so that it will register a value when it is over the block. This sensor works by
giving a reading depending on how much light is being received. Different colours can be
distinguished by their light reading, with values up to about 100 (this value being for an
actual light source such as a bulb). The idea here is that the robot will sense a large black
Lego block by the fluctuation in light sensor readings as it is searching the room, and pick it
up.
The light sensor will then be moved so that it is pointing forwards. This will detect the block
when it is in front of the object and should be more efficient as it will be able to view a larger
area. The Evaluation Chapter shows the results of the comparison and which is actually the
most efficient (5.1.1).
3.1.2 Grabber Arm
The Grabber arm is the most complex and most important mechanical part of the robot.
There are numerous designs on the Internet for effective grabber arms, but the chosen
design works using one motor because of constraints on the number that the RCX will
support. The design has been taken from the Fetchbot [2], and adapted to make it work
effectively on this robot.
The whole arm is driven by a large-sized gear, which is in turn driven by a motor. When this
gear is rotated anti-clockwise, the cams push the entire arm up, while the smaller gears
cause the grabber to open wide. Clockwise rotation causes the grabber to close until it
reaches resistance and cannot close any further. Once the axle that controls movement of
the grabber can no longer rotate, the arm becomes locked to the main axle (which holds the
large, main gear) and the whole arm lifts up. Considerations that have to be made here are
that this operation puts a lot of strain on the small gears where the arm axle and the main
axle meet, requiring a large amount of reinforcing at the base of the arm to hold it in place
[2]. This makes the arm heavier and larger, slightly affecting performance and putting more
strain on the motor.
BSc Project Report
17
An investigation into robotics for application in hazardous environments using Lego Mindstorms
This design is compact, simple and efficient, requiring minimum coding, yet achieving
maximum performance. The advantages to the robot design in general include making it
smaller, lighter, simpler and easier to code.
3.2 Software
3.2.1 Search Algorithm
A simple algorithm is required that should provide an efficient method for the robot to search
the room. This will form the basis of the search program to control the robot. The algorithm
shown below is an extension of the simple control algorithm mentioned previously (2.4.3). To
ensure the robot is aware of its position in the room, sensors and variables are used to
record how far, and in what direction the robot has travelled, rather than a random search
pattern.
If (Object Retrieved = 0) {
// Object not yet retrieved
While ((Light > LightValue) and (Bumper = 0)) {
// No obstructions or objects
NumofRuns++
// Record no. of runs made across
Move forward
// Move straight forward
If (On first run across room) {
// Length of room need only be
Measure length
// measured once
}
}
if ((Light > LightValue) and (Bumper = 1)) {
// Bumper activated
Stop
Turn 90 degrees right
// Turn to move across
Move across by the width of the robot
// Move across
Turn 90 degrees right
// Turn to face opposite direction
Bumper = 0
// Set Bumper to false
}
else if (Light < LightValue) {
// Object detected
Stop
Record x, z distance of object from start // Record position
Start Grabber
Object Retrieved = 1
// Pick up object
// Object retrieved
}
BSc Project Report
18
An investigation into robotics for application in hazardous environments using Lego Mindstorms
else if (Object Retrieved = 1) {
// Object has been retrieved
Move across width of the room
// Go across room to measure
width
Record distance for width
Turn around to face direction of start
// Return to start position
Move forward x distance of object
// We know that we are these Move
forward z distance of object
// distances away, so move these
// distances to return to start
}
The algorithm will dictate the automated search program for the robot and will cause it to
follow a track within the room as shown in the diagram (Fig 3.1).
KEY:
Path of Robot
Object to
be retrieved
MEASURE LENGTH
Walls of Room
CALCULATE OBJ. DIS.
MEASURE WIDTH
START
Fig 3.1: Search Pattern
The assumption made here is that the room will be a basic room of any size up to about ten
metres square, with four straight walls (i.e. square or rectangular).
BSc Project Report
19
An investigation into robotics for application in hazardous environments using Lego Mindstorms
This is to make the design simpler to implement in the limited time available. A more
advanced version would allow for different shaped rooms with obstacles included, but would
take too long to implement and test for this project. The algorithm does allow the robot to
start at any point along the wall, representing where the door opening would be (the point
from which the robot would enter the room). The reason the robot moves to the farthest wall
from the start first after finding the object, is so that it can measure the width of the room (to
be recorded for room layout). The length of the room is measured on the first run, with object
position reliant on values measured at the point where the object is retrieved for it to be
recorded.
3.2.2 Control Program
BrixCC (NQC)[11]
The chosen language to control the robot is NQC (Not Quite C), a C-based programming
language as this allows the most flexibility, and the ability to actually accomplish the
requirements as analysed previously (2.4.1) compared to the only other language with
sufficient capabilities- Visual Basic.
NQC will be combined with the BrixCC program. This program is run in Windows and
provides a Windows-style graphical interface for writing and managing the NQC code and
the RCX. Some of the features, such as manual control of the robot, have been partially
implemented in this program, meaning less direct coding is required.
To retrieve data from the RCX there is a datalog provided in BrixCC. Code is written within
the program that assigns variables to the datalog. Information stored in this variable can then
be uploaded using built-in tools. These tools also allow data to be plotted on a graph, which
can be used to represent the layout of the room by plotting the coordinates of the corners
and position of the object.
Automated Movement program
The program to control the movement will be entirely based on the search algorithm
conceived previously (3.2.1).
BSc Project Report
20
An investigation into robotics for application in hazardous environments using Lego Mindstorms
It will consist of a series of ‘tasks’ (similar to functions, but allowing more control, with the
ability to stop and start them at different points within the program). There will be tasks to
represent each of the functions that the robot will have to carry out:
•
Search-
A basic task that makes the robot travel in a straight line while there
are no obstacles or objects detected.
•
Check Bumper-
This task is constantly checking the bumper to see if it has been
activated. Once activated, it makes the robot turn around and then
restarts the search task; the assumption being that the robot has hit a
wall.
•
Pick Up Object-
This task will operate the grabber arm, once the object has been
detected.
•
Measure Width-
This task will cause the robot to move towards the sidewall, turn
around, and move across the room in order to measure the width.
•
Return to Start-
The purpose of this task is to return the robot to the approximate
position of where it started and put the retrieved object down.
3.2.3 Software Development Methodology
To introduce structure to the programming, a software development methodology must be
used. The style of the project suggests that the best method would be to combine and use
two methodologies: Evolutionary and Re-use Orientated Development.
Evolutionary Development (2.4.2) allows for constant and rapid prototyping of the program,
meaning that versions are created and used with feedback on what does and does not work
to be altered for the next version. This suits this program because the software does not
work independently; it has to control hardware, and until it is combined with the hardware it
is hard to tell exactly how well it will work. Constant prototyping means the robot can be
tested as it develops to make sure the functions work with the hardware.
Re-use Orientated Development (2.3.2) is based around a large database of pre-written
functions that can be used, and added to depending on what is required for the project. A
relevant database does not exist, but there are numerous projects with code available to use
as and when needed. Using this method allows a shortening of the time to write and test the
code, because the functions have already been proven to work.
BSc Project Report
21
An investigation into robotics for application in hazardous environments using Lego Mindstorms
4. Implementation
4.1 Hardware
The final outcome for hardware layout is in some ways very different to the original design.
The procedure followed was similar to that of the software methodology; Evolutionary
Development (2.4.2). This allowed for the robot to be built and constantly altered as parts
were found not to work, and better, more efficient designs were discovered.
4.1.1 Chassis
The chassis was the area that changed most drastically in implementation, where a better
structure was created (having implemented the original design first).
Construction of basic structure
The basic chassis evolved to become lower and wider, the RCX being positioned between
the motors and directly behind the grabber mechanism. This was changed once it was
realised that there was a lot of wasted space underneath the RCX as the grabber could not
be moved back any further. This change allowed the use of the shorter connection cables
that would not originally reach from the motors to the output ports.
Drivetrain
The drivetrain remained fairly consistent with the original design, but as a result of the
widening of the basic chassis, it was discovered that the track driving-wheels could be
moved in closer to the body, making them stiffer (in undesirable sideways movement) and
allowing tightening of the tracks, leading to increased efficiency.
Sensor placement
Sensor placement as defined below, was largely dependent on the results of simple
experiments to determine efficiency.
BSc Project Report
22
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Touch Sensor (bumper)
Following experiments with sensor placement (5.1.2), it was determined that both touch
sensors should be positioned at the front of the robot, one on each side facing forwards.
There were several reasons for this. Firstly, the rearwards sensor was found to be pointless,
as the robot only ever needs to reverse a short way, and that is in the direction from which it
has already come, so it will not risk reversing into any obstacles. The second reason is that
because of the grabber, a bumper linked to a single sensor cannot be positioned across the
entire front, yet full coverage is still required. The solution was a sensor either side of the
grabber with a simple straw extension so that they will be activated before the body of the
robot or grabber comes into contact with the wall.
Rotation Sensor
The rotation sensor was positioned on the axle for the right track. This allowed fairly
accurate readings to be taken, but ideally there would have been two sensors; one on each
side so that an average could be taken to increase accuracy
Light Sensor
After experiments with light sensor placements (5.1.1), it was found that placing the light
sensor to look forwards in front of the robot was better. The reason for this was that it could
view a wider area, so unlike with the other design which had it facing downwards, if the
object was not directly in front of the sensor, it could still detect it. This resulted in more
reliable detection of the object, and it could be configured so that the robot would stop at the
point where the object was in exactly the right place.
4.1.2 Grabber Arm
The implemented grabber arm was exactly the same as that conceived in the design (it
being based on an existing design). Attempts were made to strengthen the structure
because it was found that the axle running up the middle was only just long enough and the
cogs were prone to become loose under excessive stress. These attempts failed, however,
because there were no Lego pieces of the exact length needed, and even after an attempt at
re-design, no realistic solution could be found. The eventual outcome was to adjust the
motor power so that it was limited and the cogs could not be put under this stress.
BSc Project Report
23
An investigation into robotics for application in hazardous environments using Lego Mindstorms
It was also found that the grabber arm could not be moved back into the main structure,
because this compromised the strength of the structure, or conversely the operation of the
arm. The solution was to leave the grabber arm in position, and alter the chassis design as
discussed previously (4.1.1)
4.2 Software
Implementation of software proved more time-consuming than construction of the robot- as
could be expected considering the relative simplicity of Lego and complication of algorithms
and C.
4.2.1 Search Algorithm
The Search algorithm is intended to make programming more structured and easier, and
was successful in its task. Using the pseudo-code (3.2.1) to work from, it was easier to
interpret what the program had to do and implement successful, simple code.
4.2.2 Control Program
The automated behaviour program represented the majority of work in the project and
implementation, and thus took the most time to implement.
BrixCC (NQC)
BrixCC provided the interface for writing, managing and downloading the code into the robot.
This interface was found to be easier and neater than the command-line interface used with
the basic NQC, and saved a large amount of time.
Manual Movement
Manual movement proved very easy to implement. BrixCC provides a software ‘joystick’ that
allows control of the robot using cursor keys, or the mouse to click on buttons that represent
arrows for direction.
BSc Project Report
24
An investigation into robotics for application in hazardous environments using Lego Mindstorms
All that is required to get this working is to specify which ports the motors are attached to
and in what configuration (i.e. one motor driving and one steering, or both motors driving as
in this case).
Automated Movement program
The automated Movement program is basically the implementation of the search algorithm.
NQC was found to be durable and easy to work with, this was partially related to the fact that
it is a popular language for programming Lego Mindstorms Robots, and so comparisons with
other people’s code were easier. A particular problem experienced was that it was ‘Not quite
the same as C’ in several ways. It was found that some of the more advanced operators did
not always react as they do in C, for example; the ‘mod (%)’ operator in C was not initially
recognised by the NQC compiler, and some refining of the basic code had to be made to get
it to work properly. The main problems involved the use of built-in functions to operate the
RCX. These functions are unfamiliar to C-programmers, and so required a large degree of
trial and improvement to get them to work properly; this being particularly evident in getting
the block to send data back to the computer (4.2.2).
The evaluation proved the successful implementation of the automated program (5.2).
Data Retrieval from block
BrixCC provides a system called Datalogging, which allows retrieval of data from the RCX.
Problems were encountered trying to get the computer to actually record data, but this was
ascertained to be mistakes with the positioning of the code that assigns variables to the
datalog. For example; some of the code was positioned at the end of loops that were exiting
before they reached this code, meaning the values were never assigned and were outputted
as zero. Moving these lines to places where they where guaranteed not to be skipped
allowed the system to work properly.
Outputting layout of the room
Once retrieval was achieved attempts were made to create an automatically generated
‘graph’ (a feature included in the program that allows representation of the datalog in a
graph). The output was intended to display the size and outline of the room, together with
the starting position and position of the object.
BSc Project Report
25
An investigation into robotics for application in hazardous environments using Lego Mindstorms
The graph drawing facility was not advanced enough to be able to do this, and in the end the
reliance was on simply retrieving the coordinates of all positions.
5. Evaluation
The Evaluation Chapter covers all the testing of hardware design and software
implementation that took place.
5.1 Evaluation of different sensor positions
In order to determine the most efficient sensor positions, evaluation of the design ideas had
to be carried out (3.1.1).
5.1.1 Evaluation of position of light sensor
EXPERIMENT:
INTRODUCTION:
A simple Experiment was carried out to test for the best positioning of light sensor; between
pointing forwards, and pointing downwards.
METHOD:
The robot was built to the original design for chassis and all other factors except positioning
of the light sensor. A simple program was written and downloaded to the robot that allowed it
to record the time taken to find the block, following a very basic search pattern.
A simple ‘arena’ was set up with all variables remaining constant; such as ambient light
levels and surface colour.
The following test was carried out identically for both light sensor positions; pointing down
and pointing forwards.
The robot was positioned at the set start position and the program initiated. The time was
recorded from the start point to the robot finishing picking up the block. The experiment was
repeated three times for each block position, for several different block positions to improve
accuracy.
BSc Project Report
26
An investigation into robotics for application in hazardous environments using Lego Mindstorms
DIAGRAM:
Fig 5.1 Evaluation of position of light sensors
The diagram (Fig 5.1) represents the path the search algorithm will cause the robot to take,
and the position of the object at various points.
RESULTS:
Average of three runs taken.
OBJECT POSITION
Sensor Position Down
Sensor Position Forwards
NO.
(seconds)
(seconds)
1
UNDETECTED
3.12
2
3.21
3.09
3
3.09
3.01
4
3.20
3.06
5
UNDETECTED
3.15
6
UNDETECTED
9.30
7
9.34
9.29
8
9.28
9.30
BSc Project Report
27
An investigation into robotics for application in hazardous environments using Lego Mindstorms
9
9.26
9.20
10
9.45
9.31
11
UNDETECTED
9.35
12
UNDETECTED
UNDETECTED
CONCLUSION:
From the results, we can see that it is more reliable, efficient and quicker to have the sensor
pointing forwards than pointing downwards. The results prove that with the sensor pointing
downwards a smaller area is covered, and the block can only be detected if it is more
centralised, compared to pointing forwards where it can detect the block at any point across
the width of the robot.
5.1.2 Evaluation of position of touch sensors
EXPERIMENT:
INTRODUCTION:
An experiment was carried out to determine the best setup for the touch sensors. The
concept tested was whether having the sensors positioned closer to the obstacle would be
more or less sensitive than having the sensors positioned closer to the robot, making them
stronger, but attaching a longer bumper or device to activate them when contact with
obstacles is made.
METHOD:
The robot was constructed to the original design with the only alterations being the
positioning of the sensors- close to the robot, or close to the obstacle.
A simple program was used, based on the basic search algorithm, with a constant arena.
To test the sensitivity of each sensor, a simple box was used, which could be filled with
different size weights. The robot will collide with the box and push against it until the sensors
pick up the object presence and force it to stop, giving a reading for seconds taken. This will
accurately test the performance of the different sensors.
BSc Project Report
28
An investigation into robotics for application in hazardous environments using Lego Mindstorms
DIAGRAM:
Fig 5.2: Evaluation of position of touch sensors
The diagram (Fig 5.2) demonstrates how the robot will move until it comes into contact with
the object. Once it has reached the object it will keep going until the sensors detect sufficient
resistance and will then stop. The measurement made is the time it takes from start to stop
for the robot at different weights for both sensor-placement designs. A run of three is made
for each measurement, and average taken to improve accuracy.
RESULTS:
Average of three runs taken.
Weight(g)
Sensor close to obstacle
Sensor close to robot
(seconds)
(seconds)
0
6.01
6.02
25
5.87
5.85
50
5.63
5.61
75
5.55
5.55
100
5.13
5.11
BSc Project Report
29
An investigation into robotics for application in hazardous environments using Lego Mindstorms
125
4.67
4.74
150
4.21
4.44
175
3.87
3.88
200
3.12
3.15
CONCLUSION:
From the results it can be seen that the values are very close, and there is therefore no
advantage in speed or sensitivity for either style of sensor. Having the sensors closer to the
robot means there is less weight protruding from the robot’s centre of gravity, and the
sensors are stronger. The conclusion reached is that neither sensor position is more
sensitive, but having the sensors close to the robot and extended outwards is a stronger,
and thus better design. It was also realised in this experiment that two sensors are needed
at the front to cover both sides of the robot, rather than one in the middle, as the robot could
come into contact with an obstacle that does not line up with the sensor, causing the
collision detection to fail. No sensors are needed at the back because the robot will only be
reversing along a track it has already covered travelling forwards, and as a result will have
knowledge there will be nothing behind it, allowing it to move.
5.2
Evaluation
of
performance
on
minimum
requirements
and
enhancements
To be able to accurately assess the overall performance of the robot, there needs to be a
break-down of the different goals, and these should be separately tested, with all other
factors remaining constant. For all experiments, the robot was run inside a room with
constant ambient light levels to ensure consistency and accuracy, as fluctuation could
directly affect the performance of the robot when searching for the object. The robot was
also run on a consistently flat and solid surface to ensure maximum performance from the
drive system. An ‘arena’ was constructed out of boards (to represent the room the robot
would be searching) that were flat and capable of forming several different sized square and
rectangular outlines.
BSc Project Report
30
An investigation into robotics for application in hazardous environments using Lego Mindstorms
5.2.1 Experiment 1: Sense and pickup object
INTRODUCTION:
This experiment is designed to test both the hardware and software systems of the robot to
see whether it is capable of picking up objects positioned around the room automaticallyand thus achieving the minimum requirements.
METHOD:
The room was set up to a constant size and shape (as illustrated in the diagram). The robot
was always started off from the same position, using the same setup each time. The black
Lego block representing the object was positioned at each of the points represented on the
diagram, for each one of three runs (to increase accuracy).
DIAGRAM:
Fig 5.3: Experiment 1
This diagram (Fig 5.3) shows how the robot will move though the room (assuming the
objects are not there). If an object is encountered, the robot will run the rest of the program,
with a timer recording time taken to retrieve the block from the start.
BSc Project Report
31
An investigation into robotics for application in hazardous environments using Lego Mindstorms
RESULTS:
Block No.
Average time to retrieve
Successful Retrieval?
block (seconds)
9/8
1
2.12
9
2
2.09
9
3
2.11
9
4
7.32
9
5
7.29
9
6
7.30
9
7
13.01
9
8
12.98
9
9
13.04
9
10
21.34
9
11
21.32
9
12
21.29
9
CONCLUSION:
The results show that the robot was able to locate and retrieve every block in every position.
This proves that the automatic search software works well.
5.2.2 Experiment 2: Return to start position
INTRODUCTION:
The aim of this experiment is to determine whether the robot will be able to return to the start
position after it has finished all other tasks. This will test the return to start function, as well
as the rotation sensor and code to record the position.
METHOD:
This experiment was run in a constant shape and sized arena, with unfluctuating light
values. The Robot ran the entire program to pick up a block from different starting positions
along the wall, to simulate differing door positions. This was run for blocks in two positions in
the room, an average of three runs per starting position for each block. The final distance
from start position was measured once the program has finished running, and if this was
below the acceptable margin of error of 10cm, then a pass was awarded.
BSc Project Report
32
An investigation into robotics for application in hazardous environments using Lego Mindstorms
DIAGRAM:
Fig 5.4: Experiment 2
This diagram (Fig 5.4) demonstrates how the robot moves on a search pattern from start
position 1. It continues until it reaches the object, then carries on with the program to
measure the width, and continue back to the start. This is all repeated three times for each
block in each start position.
RESULTS:
Starting Position
Object Position 1
Object Position 2
Distance
Successful
Distance
Successful
from Start
Return?
from Start
Return?
Point (cm)
9/8
Point (cm)
9/8
1
3
9
2
9
2
4
9
3
9
3
2
9
3
9
4
*
8
2
9
5
*
8
6
9
BSc Project Report
33
An investigation into robotics for application in hazardous environments using Lego Mindstorms
6
*
8
5
9
* Object not successfully retrieved.
CONCLUSION:
The results show that the robot was unable to pick up the block if the starting position was to
the left of the block position. This is because the robot runs its search assuming the block
will be on its right. The robot was, however, successful with all other block and start
positions, proving that as long as the block is to the right of the robot, it will be able to pick it
up and return to the start.
5.2.3 Experiment 3: Measure Length and Width
INTRODUCTION:
This experiment aims to test the ability of the robot to accurately measure the size of the
room. The data will be sent back using the datalog, and so will also prove whether the robot
can store and transmit these values.
METHOD:
All factors were maintained at constant values, including program-run, object position and
robot start position. The size of the arena altered depending on what is being tested; for
example, to test width, the width was altered several times whilst length remains constant,
and for Length, the length was altered whilst width remains constant. The robot ran three
times for each measurement (to improve accuracy) and the distance was recorded in
comparison to actual distance. If the recorded distance was five or more centimetres out,
this was recorded as inaccurate and thus a fail.
BSc Project Report
34
An investigation into robotics for application in hazardous environments using Lego Mindstorms
DIAGRAM:
Fig 5.5: Experiment 3
The diagram (Fig 5.5) shows how different sized rooms are used to test the functions for
measuring length and width.
RESULTS:
Table for Width:
Width (cm)
Recorded Width (cm)
Accurate?
9/8
100
98
9
125
129
9
150
154
9
175
172
9
200
199
9
BSc Project Report
35
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Table for Length:
Length (cm)
Recorded Length (cm)
Accurate?
9/8
100
103
9
125
127
9
150
148
9
175
171
9
200
203
9
CONCLUSION:
The results show that the Rotation Sensor is always at least ninety-eight percent accurate,
which is sufficient for running the robot on smaller sized arenas (but may prove too
inaccurate over much larger distances). This proves that the software and hardware for
measuring distances works.
5.2.4 Experiment 4: Test Manual Control
INTRODUCTION:
This experiment is designed to test manual control. This will involve using the BrixCC
program’s manual control function to steer the robot through a rudimentary maze. The test
will ensure the robot can be communicated with independently of the direction it is pointing
with regards to the infrared transmitter.
METHOD:
The robot was configured to run using manual control (simply by clicking on appropriate
button in BrixCC). The robot was run thorough a simple maze that ensures there has to be
communication between RCX and infrared transmitter from every angle. This was run five
times to ensure a satisfactory result.
BSc Project Report
36
An investigation into robotics for application in hazardous environments using Lego Mindstorms
DIAGRAM:
Fig 5.6: Experiment 4
The diagram (Fig 5.6) shows how the robot is directed around the maze. The path shows
how the robot would be facing all angles at some point during the journey, meaning that
there must be constant communication between RCX and transmitter for the robot to
succeed.
RESULTS:
Run number Successful?
Comments
9/8
1
9
Robot responded well. Some delay with
communication and thus control when infrared
receiver close to, and thus shielded by walls.
2
9
Robot stuck at top right corner; eventually freed by
rapid movements forward and backwards.
3
9
Perfect Run.
4
9
Perfect Run.
5
9
Slightly delayed communication; most likely due to
BSc Project Report
37
An investigation into robotics for application in hazardous environments using Lego Mindstorms
low battery in RCX.
CONCLUSION:
The robot successfully completed all five runs with varying speed and consistency. Towards
the end of the experiment, any problems with communication were attributed to a low
battery; meaning the signal from the transmitter was not picked up as easily, causing the
robot to ‘stutter and stall’ slightly. The problems encountered in the first runs were attributed
to human error, and would be expected initially when the user has had no prior experience
or training. To achieve more consistent results, this experiment should have been run once
the user had adequate experience of the layout of the course.
6. Conclusion and Possible further developments
6.1 Overall Conclusion
The evaluation proves decisively that the robot has successfully accomplished all of the
minimum requirements (See 2.2) laid down early in the project process, as well as the
additional requirements. The results conclusively demonstrate that the robot can
successfully search a room for on object, and bring it back to the start. In addition the robot
can also record vital data about the room, such as the size and the position of the object
within the room, as well as allowing full manual control.
The final design bears significant resemblance to real robots built and designed for use in
bomb disposal, mine detection and nuclear accident response. The majority of such robots
follow design ideals of being light, highly manoeuvrable (through use of caterpillar tracks)
and as simple as possible- the obvious reason here being that making robots unnecessarily
complicated increases expense, meaning more money to lose if the robot gets destroyed
whilst completing its task. One important way this robot differs to others, is the use of
automation rather than direct user input. The majority of designs require full control from the
operator- which can make the job very specialised, and the robots harder to deploy. This
robot operates fully autonomously (or manually when needed), meaning it requires much
less user input. This means that it could be operated by civilians or soldiers with minimal
training, ensuring easy deployment, even onto the front line.
BSc Project Report
38
An investigation into robotics for application in hazardous environments using Lego Mindstorms
The ultimate conclusion is that although the robot has been successful in achieving its goals,
the Lego Mindstorms kit does not have the capabilities to allow creation of a robot of the
standard required for real-world application. The project has allowed analysis and design of
the techniques and styles used to create such a robot, but much further work would be
required to create a successful real-world operable version.
6.2 Further Work
The project provided a good insight into how a robot built to solve a problem, such as that of
explosives retrieval, could be designed, built and tested.
This project covered all areas of robot design in hardware and software, but unfortunately
due to the limited time-scale, was simplified in some respects to allow all areas to be
covered.
The main areas of improvement centre around the limitations of the robot design. The
greatest limitation with the design was the lack of flexibility of the Search Algorithm; the robot
could only detect and pickup an object if it was to the right of the initial start position because
the robot always runs its search from left to right until it hits the edge of the room. The
algorithm could be developed further, to allow the robot to start from any position in the room
(not just limited to any position along the front wall) and search systematically from that point
until the whole room has been covered, or the object found. This method would be as slow
as the original method, and therefore a more advanced sensor system could be used, such
as a camera. Using a camera would require image detection and analysis software that
would be long and difficult to implement, but would allow the robot to ‘scan’ the room and
then move towards the object once found, rather than having to search the entire floor area.
A further extension would be to modify the capabilities to allow the robot to operate in
alternative environments such as fields and open areas. The algorithm would allow the robot
to search a set sized area rather than relying on hitting obstacles (walls) to determine search
size. This could be achieved by extending the program so that it relies on distances recorded
in the rotation sensor to work out the point to turn around and continue the next run.
BSc Project Report
39
An investigation into robotics for application in hazardous environments using Lego Mindstorms
APPENDIX A – Personal Reflection on the Project.
I have really enjoyed this project and am glad that I achieved a successful outcome. I felt
that a project of this type; practical ‘hands-on’ work producing a working robot, was more
interesting and better suited to me than a generic research project.
The reason I chose this project is that it relates to my own experience and interests, having
been in the TA for two years prior to this. My intention upon leaving University is to go on
and work in the defence manufacturing industry hopefully working on real-life versions of this
project, making it an excellent choice and thoroughly worthwhile.
The main lesson learnt whilst implementing this project was that I did not have enough
knowledge and experience of the capabilities of the kit and what other people had
accomplished. If I had researched more intently from the very start, and had been able to
experiment with the kit before I had to come up with a problem and requirements, I would
certainly have found the project easier and have been able to create a more complicated
and better solution. This lack of experience meant I had to come up with a project based on
what I thought it could do, but I discovered a lot of hidden features and design ideas once I
had started and could not afford time to change everything. A warning to future users would
be to experiment and ‘get to know’ the kit from an early stage, so that they have knowledge
from the start of what it is capable of, and can tailor minimum requirements more precisely
as a result.
In retrospect I would have studied real-world designs more intently, and improved upon
these, rather than coming up with an entirely new design (although in the end it was very
similar to those real robots). This should be the principle behind future projects of this type;
re-use of tried, tested and proven technologies.
I found this project challenging and fun, but am glad that it is over because the pain of trying
to work out why a basic C-style function will not work in NQC is unbelievably frustrating.
There is plenty of room for expansion and improvement, and I hope that myself or some
other budding robotics programmer will be able to continue where this project finishes.
BSc Project Report
40
An investigation into robotics for application in hazardous environments using Lego Mindstorms
APPENDIX B- Final Hardware design.
Fig B.1: Infrared Tower
Figure B.1 shows the Infrared Tower. This is connected to the computer using a USB port.
The tower is self-powered via the port, and is used to transmit data to the RCX at varying
ranges that can be set within the control program.
Fig B.2: RCX
Figure B.2 is the RCX. This is the computer that controls the robot, taking inputs in from
sensors attached to the grey ports evident in a line of three on the top, and outputting to
motors connected to the black ports closer to the front of the brick.
BSc Project Report
41
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Fig B.3: Left Side of Complete Robot
This view (Figure B.3) shows the complete left side of the robot. The large grey cog at the
rear on the right is attached to the motor, driving the cog attached to the axle. The caterpillar
tracks are evident here, stretched along the length of the main chassis. The grey touch
sensor can be seen on the left, with the yellow straw attached that projects out in front as a
bumper.
Fig B.4: Back of Complete Robot
Figure B.4 displays the rear of the robot, with the RCX clearly visible in the middle, with
infrared receiver (the black strip on the very back top of the RCX) free from obstruction to
receive transmissions. The blue rotation sensor is clearly visible at the bottom-right, attached
to the right axle.
BSc Project Report
42
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Fig B.5: Front of Complete Robot
This is the front view (Figure B.5) of the entire robot, clearly displaying the grabber arm in
the centre, ‘flanked’ by the yellow object bumpers which direct objects into the path of the
grabber should they not be on centre. The two touch sensors are immediately visible on
either side, with yellow straws protruding forwards either side of the grabber arm.
Fig B.6 Front View of basic stripped-down Chassis
This picture (Fig B.6) shows the chassis, stripped of the RCX and grabber arm to
demonstrate the chassis design. The gap in the middle rear is for the RCX, with grabber arm
at front middle. The strength can be ascertained here by the amount of Lego built up either
side of the centre-channel, designed to hold the RCX and grabber in position, which in turn
aid strength of the overall structure. The light sensor can now be seen at the middle front,
positioned underneath the grabber.
BSc Project Report
43
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Fig B.7: Light Sensor placement
This view (Figure B.7) shows the position of the light sensor beneath the grabber-arm, yet inbetween the cams so as not to inhibit operation.
Fig B.8: Grabber Arm detached from chassis and relaxed
Figure B.8 shows the grabber-arm detached from the chassis. The large grey cog to the left
of picture drives operation, and is powered by another cog attached to the motor.
Fig B.9: Grabber Arm fully open
This picture (Figure B.9) shows the grabber fully open, the effect if the motor is switched on
in reverse.
BSc Project Report
44
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Fig B.10: Underside of Grabber Arm
Figure B.10 shows the underside of the grabber-arm, demonstrating the amount of
reinforcing required to stop the arm from disintegrating under stress.
BSc Project Report
45
An investigation into robotics for application in hazardous environments using Lego Mindstorms
APPENDIX C- Final program.
The following code is written in NQC. This is the program for automated control of the robot.
/*
`/ NQC Program to Control Lego Mindstorms Robot
/
/ Simon Wozniak
/ 18/04/2002
*/
/* Assign Outputs
#define GRABBER
#define LEFT
#define RIGHT
*/
OUT_B
OUT_C
OUT_A
/* Assign Inputs */
#define BUMPER SENSOR_2
#define LIGHT SENSOR_1
#define ROTATION SENSOR_3
/* Define Motors-movement */
#define STOPMOTOR
Off(LEFT);
Off(RIGHT);
#define STOPGRAB
Off(GRABBER)
#define L_FWD OnFwd(LEFT)
#define L_REV OnRev(LEFT)
#define R_FWD OnFwd(RIGHT)
#define R_REV OnRev(RIGHT)
#define GRAB_OPEN OnFwd(GRABBER)
#define GRAB_CLOSE OnRev(GRABBER)
int ObjRetrieved = 0; /* Bool value to check whether object has already
been retrieved */
int NumofRuns = 0;
/* Number of runs up and down the robot has completed
*/
int DistFromStart = 0;/* X Distance travelled by Robot from start */
int EndMeasWidth = 0; /* Bool value to check whether Width has been
measured */
int NegXDistance = 0; /* Value to show distance to be taken off Width for X
measurement of object */
int ObjZDistance = 0; /* Value to show z-distance of object */
int ObjXDistance = 0; /* Value to show x-distance of object */
int LightThreashold = 27; /* Value to allow adjustment of light value for
object */
/* Store Values for Dimensions of Room */
int LengthZ = 0;
/* Value for Length of Room */
int WidthX = 0;
/* Value for Width of Room */
/*
/ Search Program to interpret standard behaviour of the robot whilst
searching
*/
task Search()
{
/* Initiate standard straight line movement for search */
while ((BUMPER != 1) && (ObjRetrieved == 0)) {
ClearSensor(ROTATION);
NumofRuns = NumofRuns + 1;
BSc Project Report
46
An investigation into robotics for application in hazardous environments using Lego Mindstorms
}
}
L_FWD; R_FWD; Wait(3000); /* Move Forward */
/*
/ Function to Operate the Grabber to pick the object up
*/
void PickUpObject()
{
/* Odd runs, pointing away from you, ObjZDistance = Distance travelled */
if (NumofRuns % 2 == 1) {
ObjZDistance = ROTATION;
}
/* Even runs, pointing towards you, ObjZDistance = Total Distance Distance travelled */
else if (NumofRuns % 2 == 0) {
ObjZDistance = LengthZ - ROTATION;
}
AddToDatalog(ObjZDistance);/* Send to Datalog */
}
stop Search;
STOPMOTOR;
GRAB_CLOSE; Wait(150);
ObjRetrieved = 1;
PlaySound(SOUND_UP);
STOPMOTOR;
STOPGRAB;
start MeasureWidth;
/*
/ Function to Check whether bumper is activated
*/
task check_bumper()
{
while (true) {
if ((BUMPER == 1) && (ObjRetrieved == 0) && (LIGHT > LightThreashold))
{
stop Search;
if (NumofRuns == 1) {
LengthZ = ROTATION;
AddToDatalog(LengthZ);
}
STOPMOTOR; Wait(10);
ClearSensor(ROTATION);
while (ROTATION > -5) {
L_REV; R_REV;
}
STOPMOTOR; Wait(10);
if (NumofRuns % 2 == 1) {
ClearSensor(ROTATION);
while (ROTATION > -32) {
L_FWD; R_REV;
}
STOPMOTOR; Wait(10);
/* Record length of Room */
/* Reverse slightly */
/* Turn 90 Degrees Right */
ClearSensor(ROTATION);
while (ROTATION < 32) {
BSc Project Report
47
An investigation into robotics for application in hazardous environments using Lego Mindstorms
L_FWD; R_FWD;
}
STOPMOTOR; Wait(10);
/* Move Forward Slightly */
ClearSensor(ROTATION);
while (ROTATION > -32) {
L_FWD; R_REV;
}
STOPMOTOR; Wait(10);
/* Turn 90 Degrees Right */
ClearSensor(ROTATION);
while (ROTATION < 32) {
L_FWD; R_FWD;
}
STOPMOTOR; Wait(10);
/* Move Forward Slightly */
ClearSensor(ROTATION);
while (ROTATION > 32) {
L_REV; R_FWD;
}
STOPMOTOR; Wait(10);
/* Turn 90 Degrees Left */
}
else if (NumofRuns % 2 == 0) {
ClearSensor(ROTATION);
while (ROTATION > 32) {
L_REV; R_FWD;
/* Turn 90 Degrees Left */
}
STOPMOTOR; Wait(10);
}
STOPMOTOR;
start Search;
}
else if ((LIGHT < LightThreashold) && (ObjRetrieved == 0)) {
PickUpObject();
}
else if ((BUMPER == 1) && (ObjRetrieved == 1) && (EndMeasWidth == 0)) {
stop MeasureWidth;
NegXDistance = ROTATION;
EndMeasWidth = 1;
STOPMOTOR; Wait(100);
ClearSensor(ROTATION);
while (ROTATION > -5) {
L_REV; R_REV;
}
STOPMOTOR; Wait(10);
/* Reverse slightly */
ClearSensor(ROTATION);
while (ROTATION > -64) {
L_FWD; R_REV;
}
STOPMOTOR; Wait(10);
/* Turn Around */
ClearSensor(ROTATION);
L_FWD; R_FWD;
/* Move Forward */
}
else if ((BUMPER == 1) && (EndMeasWidth == 1)) {
stop MeasureWidth;
WidthX = ROTATION + 10;
ObjXDistance = WidthX - NegXDistance;
BSc Project Report
48
An investigation into robotics for application in hazardous environments using Lego Mindstorms
}
}
}
DistFromStart = ObjXDistance - (NumofRuns * 16);
AddToDatalog(ObjXDistance);
AddToDatalog(WidthX);
AddToDatalog(DistFromStart);
STOPMOTOR;
start ReturnToStart;
/*
/ Function for Measuring Width of the Room
*/
task MeasureWidth()
{
ClearSensor(ROTATION);
while ((BUMPER == 0) && (ObjRetrieved == 1)) {
/* Odd runs, pointing away from you, rotate Right */
if (NumofRuns % 2 == 1) {
ClearSensor(ROTATION);
while (ROTATION > -32) {
L_FWD; R_REV;
/* Turn 90 Degrees Right */
}
STOPMOTOR; Wait(10);
}
/* Even runs, pointing towards you, rotate left */
else if (NumofRuns % 2 == 0) {
ClearSensor(ROTATION);
while (ROTATION < 32) {
L_REV; R_FWD;
/* Turn 90 Degrees Left */
}
STOPMOTOR; Wait(10);
}
ClearSensor(ROTATION);
L_FWD; R_FWD; Wait(3000);
/* Go Forward */
}
}
/*
/ Function to send the Robot back to the start
*/
task ReturnToStart()
{
stop MeasureWidth;
STOPMOTOR; Wait(150);
ClearSensor(ROTATION);
while (ROTATION > 10) {
L_REV; R_REV;
}
STOPMOTOR; Wait(10);
/* Reverse Slightly */
ClearSensor(ROTATION);
while (ROTATION > -64) {
L_FWD; R_REV;
}
STOPMOTOR; Wait(10);
/* Turn Around */
ClearSensor(ROTATION);
while (ROTATION > DistFromStart) {
L_FWD; R_FWD;
/* Go Forward to point of start */
BSc Project Report
49
An investigation into robotics for application in hazardous environments using Lego Mindstorms
}
STOPMOTOR; Wait(10);
ClearSensor(ROTATION);
while (ROTATION > -32) {
L_FWD; R_REV;
}
STOPMOTOR; Wait(10);
/* Turn 90 Degrees Right */
ClearSensor(ROTATION);
while (ROTATION < ObjZDistance) {
L_FWD; R_FWD;
/* Forward to start */
}
PlaySound(SOUND_FAST_UP);
STOPMOTOR;
StopAllTasks();
}
/*
/ Main Function
*/
task main()
{
SetSensor(BUMPER, SENSOR_TOUCH);
SetSensorMode(BUMPER, SENSOR_MODE_BOOL);
SetSensor(ROTATION, SENSOR_ROTATION);
SetSensorType(ROTATION, SENSOR_TYPE_ROTATION);
SetSensor(LIGHT, SENSOR_LIGHT);
SetSensorType(LIGHT, SENSOR_TYPE_LIGHT);
CreateDatalog(10);
GRAB_OPEN; Wait(50);
STOPGRAB;
}
start check_bumper;
start Search;
BSc Project Report
50
An investigation into robotics for application in hazardous environments using Lego Mindstorms
Bibliography
[1] http://www.mindstorms.com
[25th April 2002]
Official Lego Mindstorms Site
[2] http://unite.com.au/~u11235a/lego/fetchbot/index.html
Ben Williamson, 1998
[25th April 2002]
Fetchbot- A Robot to seek an object and pick it up
[3] http://www.sonic.net/~rci/transmission.htm
Michael Powell, 2000
[25th April 2002]
Directional Transmission
[4] http://www.coginst.uwf.edu/lego/designexamples.html
[25th April 2002]
Design hints and ideas on building Robots
[5] http://www.lego.com/dacta/robolab/productoverview.htm
[25th April 2002]
RoboLab- Product Overview
[6] http://www.noga.de/legOS/
[25th April 2002]
LegOS- An open-source embedded operating System for Mindstorms
[7] http://www.enteract.com/~dbaum/nqc/index.html
Dave Baum, 2000
[25th April 2002]
NQC- Web-page on C-like programming language
[8] Pressman R.S., Software Engineering A Practitioner’s Approach (European
Adaptation), 5th Edition, McGraw-Hill, 2000
[9] K Goldberg, D Halperin, J Latombe and R Wilson, Algorithmic Foundations of
Robotics, A K Peters, 1995
BSc Project Report
51
An investigation into robotics for application in hazardous environments using Lego Mindstorms
[10] Dave Baum, Definitive Guide to Lego Mindstorms, Apress, 1999
[11] http://members.aol.com/johnbinder/bricxcc.htm
John Binder, 2001
[25th April 2002]
Contains information on, and software to download BrixCC- graphical interface for
management of NQC programs and the RCX.
[12] http://www.astolfo.com/lego/robots.asp
Dave Astolfo, 2001
[25th April 2002]
Recycler- A Robot to seek an object, pick it up and follow a line
[13] http://cs.smith.edu/~thiebaut/classes/100/
D. Thiébaut and D. Weinberger, 2000
[25th April 2002]
Introduction to Engineering
[14] http://www-scf.usc.edu/~csci445/
Maja Mataric, USC, 2001
[25th April 2002]
Course Resource- University–run Lego Robot projects
[15] http://www.neilvandyke.org/magellan/
Neil W.Van Dyke, 2001
[25th April 2002]
Magellan Lego Robot- Maps a room
[16] http://www.techbooks.co.nz/Eng/LEGOMindstorms.htm
[25th April 2002]
Creative Project with LEGO Mindstorms
[17] http://www.cs.brown.edu/courses/cs148/assignments.html
[25th April 2002]
Building Intelligent Robots
BSc Project Report
52
An investigation into robotics for application in hazardous environments using Lego Mindstorms
[18] http://schalburg.homepage.dk/Spider/Spider.html
[25th April 2002]
Creating a Spider Robot using LEGO-Mindstorms
[19] http://www.webremote.co.uk/Down_Lego.html
JetByte Limited, 1999-2000
[25th April 2002]
WebRemote - Download Lego Mindstorms Driver
[20] http://www3.ltu.edu/~chung/robot/s00/syl.htm
Department of Math. and Computer Science, Lawrence Tech. University, Spring 2000
[25th April 2002]
MCS5403 Robotics Programming
BSc Project Report
53