a petri net based lego for searching

A Petri Net based Lego for searching

Vegard Torkelsen and Jonathan Brian T. Alcoriza

May 2012

Summary (Abstract)

The aim of this project is to create a robot which implements a searching routine

to �nd objects in an area, removing them from the search area. The search-

ing routine will be fully autonomous, meaning that the robot will �nd objects

and remove them, making all the decisions and calculations by itself with no

interaction from the user. Lego Mindstorms NXT is a programmable robotics

kit by LEGO. In this project the Lego Mindstorms NXT 2.0 is used, which is

the newest set in LEGO's Lego Mindstorms series. The NXT we are going to

design will have 2 wheels on individual motors and will use an ultrasound sensor

to �nd the objects. The NXT will calculate and �nd the object closes to its

current position and drive towards the closes object. We constructed a grabbing

mechanism, a �claw� which uses a third motor to open and close. After the NXT

has found and positioned itself in front of the object, it will close the �claw� and

drive to edge of the search area. We will be using a Bluetooth connection to

communicate between the NXT and a computer. This is implemented using

Petri NET and GePEN sim.

1

Acknowledgements

We would like to thank our teacher prof. Reggie Davidrajuh for guidance and

tips on GpenSim and Ståle Freyer for lending us the Lego Kit and helping us

when we had questions about the Lego and setting up the connection.

2

Contents

1 Introduction 5

1.1 Problem de�nition . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Relevance and adoption . . . . . . . . . . . . . . . . . . . . . . . 6

2 Background 7

2.1 Lego Mindstorms NXT . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 RWTH - Mindstorms NXT Toolbox for MATLAB . . . . . . . . 10

2.4 Petri Net and DEDS . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 GpenSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Autonomy and Arti�cial Intelligence . . . . . . . . . . . . . . . . 11

3 Method and design 12

3.1 Implementation and coding . . . . . . . . . . . . . . . . . . . . . 13

4 Testing, analyzing and result 35

4.1 Example run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2 Limitations and challenges . . . . . . . . . . . . . . . . . . . . . . 59

4.3 Analyzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5 Discussion 63

5.1 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3

CONTENTS 4

5.2 Petri Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3 Further work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Image Reference 66

Bibliography 66

A Building guide 69

B User manual for Lego NXT Clean-up robot 70

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

B.2 The search area . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

B.3 Adjusting and starting the program . . . . . . . . . . . . . . . . 72

C Installation guide for Lego NXT Clean-up robot 73

C.1 Installing software . . . . . . . . . . . . . . . . . . . . . . . . . . 73

C.2 RWTH Mindstorms NXT Toolbox . . . . . . . . . . . . . . . . . 73

C.3 Installing the program . . . . . . . . . . . . . . . . . . . . . . . . 74

C.4 Setting up the bluetooth.ini �le . . . . . . . . . . . . . . . . . . . 74

C.5 Connecting to the NXT . . . . . . . . . . . . . . . . . . . . . . . 75

C.6 Troubleshooting the bluetooth connection . . . . . . . . . . . . . 75

D MATLAB code 77

D.1 Action Commands . . . . . . . . . . . . . . . . . . . . . . . . . . 77

D.2 Main program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

D.3 Transitions (in alphabetical order) . . . . . . . . . . . . . . . . . 95

Chapter 1

Introduction

This project was created for the subject MID-280 Discrete Simulation and per-

formance analysis spring semester 2012

by Vegard Torkelsen and Jonathan Brian T. Alcoriza.

1.1 Problem de�nition

The main issue of this project is to create a robot using Lego Mindstorms NXT

that will implement a searching routine which has been created using GpenSIM

and Petri Net. Petri Net is a discrete event dynamic system. We wish to create

a robot that is as autonomous as possible - the robot should be able to make

decisions on its own. It will be interesting to see how well GpenSIM and Petri

Net works in this �eld and if GpenSIM should be used in more robotics. In

this project the Lego Mindstorms NXT 2.0 will be used, which is the newest

set in LEGO's Lego Mindstorms series. The NXT we going to design will have

2 wheels on individual motors and will use an ultrasound sensor to �nd the

objects.

1.2 Motivation

We are both studying Cybernetics and played with Lego when we were younger.

Robots and new technology are interesting for us, and being one of the �rst

5

CHAPTER 1. INTRODUCTION 6

students to get to program and try out the Lego NXT at the University of

Stavanger is a good opportunity for us to try something new.

1.3 Relevance and adoption

Robots which are fully (or almost fully) automated are being used more and

more in everyday life as well as in industrial work.

Some examples of real life AI[4]:

- Warehouses with mobile robots that store and fetch requested items

- Agents outperforming humans in trading on the stock exchange

- Automated scanning and interpretation of X-ray images in medicine

- Image matching and recognition in mobile Internet search

- Neural networks for fraud detection in banking transactions

- Autonomous cars navigating and driving unassisted in normal tra�c

In this project, the robot created has been inspired by mobile robots in ware-

houses that looks for items, and puts the items at the required area.

Chapter 2

Background

2.1 Lego Mindstorms NXT

Lego Mindstorms NXT [8] is a programmable robotics kit by LEGO. In this

project the Lego Mindstorms NXT 2.0 was used, which is the newest set in

LEGO's Lego Mindstorms series.

2.1.1 NXT Intelligent Brick

The main component of the Lego Mindstorm kit is the NXT intelligent brick,

which is a brick-shaped computer. It can get input from up to four di�erent

sensors[3] and three outputs which can control up to 3 motors using RJ12 cables.

It has a monochrome screen which is 100x64 pixel and four buttons with menus

using hierarchy. The brick also have a speaker that can play sound �les.

7

CHAPTER 2. BACKGROUND 8

Figure 2.1: NXT Intelligent brick

Technical speci�cations:

- 32-bit ARM7 micro controller

- 256 KBytes FLASH, 64 KBytes RAM

- 8-bit AVR micro controller

- 4 KBytes FLASH, 512 Bytes RAM

- Bluetooth wireless communication

- USB full speed port, 12MBit/s

- 4 input ports, 3 output ports, 6-wire cable digital platform

- 100 x 64 pixel LCD graphical display

- Loudspeaker, 8kHz

2.1.2 Sensors

There are many Lego sensors[3] that can be bought separately and third-party

sensors, like color sensors, sound sensor, compass, gyroscopic, RFID reader,

accelerometer and temperature measurer.


Figure 2.2: Push Sensor

- Push sensor - can detect whether it is being pressed, released or bumped.

Figure 2.3: Ultrasonic sensor

- Ultrasonic sensor - measures distances in centimeters and in inches and it can

detect movement. The sensor can measure distances from 0 to 233 cm with a

precision of 3 cm. The ultrasonic sensor measures the distance by calculating

the time it takes for a sound wave to hit an object and returns.

Figure 2.4: Light sensor

- Light sensor - detects light levels by sensing the re�ected light using a build-in

red LED or ambient light. It can also read light intensity of colored surfaces.


Figure 2.5: Servo Motor

- The servo motors have built in rotary encoders that senses the rotation of the

motor with an accuracy of one degree.

2.2 MATLAB

MATLAB[10] is a high-level programming language for numerical computing,

data acquisition and analysis. It can be used to control LEGO NXT robots

over a Bluetooth serial port (serial port communication is part of the base

functionality of MATLAB) or via a USB connection. There are several papers

found in [14] that take on the topic of LEGO NXT programming in MATLAB.

2.3 RWTH -Mindstorms NXT Toolbox for MAT-

LAB

RWTH toolbox [14] is developed to control Lego Mindstorms NXT robots with

MATLAB via a USB connection or over a Bluetooth serial port. RWTH toolbox

is a free open source software. The toolbox functions are based on the Lego

Mindstorms NXT Bluetooth communication protocol to control the intelligent

NXT Brick via a wireless Bluetooth connection or via USB.

2.4 Petri Net and DEDS

Petri Net (Place/transition net) is a mathematical modelling language for de-

scribing distributed systems. Petri Net o�ers a graphical notation for stepwise

processes that include choice, iteration and concrete execution. Petri nets are

a popular way for modelling concurrency and synchronisation in distributed

systems. Petri Net is a discrete event dynamic system[5] (DEDS), which are


dynamic systems that are not synchronized (asynchronous, not driven by a

clock), but moves forward with the occurrence of events.

2.5 GpenSIM

General purpose Petri-net simulator[1] is a Petri Net simulator, which satisfy

the three criteria of �exible, extensible and easy to use. GpenSIM is a toolbox

in the MATLAB platform. Diverse toolboxes like Fuzzy toolbox and Control

system toolbox can be used in the models developed with GpenSIM. There are

other tools for discrete event simulation like Automata, State�ow and Petri Net,

but unlike GpenSIM, these tools are stand-alone systems and integrating with

other types of tools like control systems is not possible.

2.6 Autonomy and Arti�cial Intelligence

Autonomous robots are machines which can do task at environments that has

no set structure and without or limited human interaction.

There are di�erent levels of autonomy[2]; from the system o�ering no assistance

at all - leaving all the decisions and actions to the user, to the computer decides

everything and acting autonomously, completely ignoring the user. A high level

of autonomy is usually required at di�cult environments like in space, deep sea,

sewage systems etc. At high level autonomy the robot can get information about

the environment, work for an extended period without human interaction, move

itself or parts of itself without being controlled by a human and avoid hurting

itself, humans or the environment (unless this is what the robot is speci�cally

designed for).

Why use autonomy? Less workload for the user by letting the system do the

mundane decisions, while the user makes the important decisions. This will help

increase the e�ectiveness and lower the cost.

Chapter 3

Method and design

We used a simple robot with two individually rotating wheels by using one mo-

tor for each wheel with a balance wheel behind. The robot has 4 sensors: push

sensor, light sensor, ultra sonic sensor and rotational sensor in the servo motors.

The push sensor is placed on top and pressing this will start the program. The

push sensor was added so that the robot would not start if we accidentally star-

ted the program from the computer. The light sensor will be facing downwards

to the �oor. The light sensor will detect when it is about to drive outside of

the search area which are marked up. The ultrasonic sensors is placed were

the front is considered, it is like the eyes of the robot. The ultrasonic sensor

are what are used to �nd objects. The light sensor does not work well to �nd

objects, because you will need special lighting conditions and the search objects

have to be di�erent. The rotational sensor will be used to calculate positions

and angles of the robot.

We are going to design the robot to have a �exible autonomous behavior, mean-

ing that the robot have a main goal which is �nding objects in the search area,

but we want it to know what to do if it does not �nd an object and �nds an ob-

ject outside the search area. We will do this by planning and optimizing action

sequence to achieve our goals. We will modify our plans as we go further into

the programming. We will improve by learning from experiences by debugging

and analyzing past experience to detect potential for improvements and imple-

ment the improvements in the system. While testing and analyzing we found

that using balls as search object were easiest for the ultrasonic sensors to read

when scanning for objects. Another method that can be used, is making the

12

CHAPTER 3. METHOD AND DESIGN 13

robot move in a speci�c pattern or follow a path like in [11]. We chose not to

use this method since we wanted a more autonomous behaviour.

3.1 Implementation and coding

3.1.1 Bluetooth

To communicate with the NXT with MATLAB we used a serial port pro�le

which works like a virtual serial port. Through serial port commands we can

send and receive data to MATLAB. We connect the bluetooth we used a .ini-�le

which had setting for MATLAB which was placed in the current directory.

bluetooth.ini �le:

[Bluetooth]SerialPort=COM23BaudRate=9600DataBits=8SendSendPause=5SendReceivePause=25Timeout=2

The variable 'SerialPort' is where the bluetooth is connected, this is the most

important part of this �le. We used Windows XP were it is a COM-port, in our

case COM-port 23. For further explanation see Appendix C.

3.1.2 Main MATLAB codes

The main program are in these �les found in Appendix D.2, for more information

on how to run the program see Appendix B:

• CONNECT.m

This �le is the initiation �le; it connects the NXT to the PC using bluetooth. It

implements the bluetooth.ini �le. Running this .m-�le will reset all connections

and sensor and connect the NXT to the bluetooth unit.

• NXT_Clawbot_def.m

This is the de�nition �le of the Petri Net. It includes arcs, places and transitions.


• NXT_Clawbot.m

It includes the initial token de�nition and initial �ring de�nitions.

• initNXT.m

Initiation �le for the NXT. It sets the di�erent global variables needed to run

the robot and sets the di�erent ports to motors and sensors.

See Appendix D for more information and all the MATLAB code.

3.1.3 Modules

There are several ways to detect objects, in [12] a camera has been used to detect

faces in images, a similar technique can be used to detect the balls, if the robot

had been �tted with a camera. We decide to go with a simpler approach, by

using a sonar sensor as mentioned earlier. Another method worth mentioning

is simultaneous localization and mapping (SLAM), which is used in [6]. This

method would be to complicated and time consuming for us to implement.

The scan sequence is the sequence which scans an area in front of the robot

for objects. The robot starts by pressing the start button. It will turn 45

degrees to the right and start searching while turning to the left. The NXT

is limited so it cannot read and send signals to its motors at the same time,

so the robots turns to the left in small increments, reads from the ultrasonic

sensor (see �gure 2.3) and sends the reading to the computer and continues until

its turned 90 degrees. For every rotational step, the robot saves the distance

returned by the ultrasonic sensor and the distance it has rotated. The distance

to the closes object is calculated and the NXT will position itself towards the

object by rotating the calculated angle. The angle is calculated by taking all the

saved distance points, �nd the one closes to the NXT and take all points which

only varies +/- 5cm from the closes one and �nding the middle one. Then the

NXT will drive forward until the calculated distance, grab the object and drive

until it �nds the edge of the search area (we created a search area by making a

circle with A4 paper). When the border of the search area is detected the NXT

stops and releases the object, reverses a bit, turns 180 and drives forward and

starts the searching loop again.

If all scanned points from the ultrasonic sensor are over 100 cm away, all points

will be set to zero. This is done so that the robot does not detected too many


objects which are too far away. If the scan area size is increased, the threshold

should increase. In the NXT_Clawbot_def.m �le, we could not divide into

modules in the code, it would stop when trying to change modules.

All the .m-�les used can be found in Appendix D.

The searching routine can result in four di�erent scenarios which we have divided

into modules:

Module 1:

Object detected normally: In this module, the robot detects a object in the

search area at the initial scan, grabs the object and drops it o� at the edge of

the search area. After the robot has removed 5 objects, the program will stop.

Figure 3.1: Module 1

Module 1 event sequence:

1. Push button is pressed to initiate program.

2. The NXT starts to scan

3. Finds an object

4. Positions itself towards the object

5. Drives to the object

6. Grabs the object

7. Drives until edge is detected

8. Stops when edge detected

9. Drops object


10. Reverses

11. Turns 180 degrees

12. Drive forward

13. Back to 2

Here we set it to run through the loop 5 times. This can be seen at the arc

between P18 and tDone in �gure 3.1. P19 works as a sink.

Figure 3.2: Sensor read when ball is in center

The points located between 15 and 25 in �gure 3.2 is an object close to the

robot, the point in the center of those points are marked red and is the center

of the object it found. The robot will use this point to calculate which angle

the servo motors have to rotate in order to position itself in front of the object

if found in order to drive towards it.


Figure 3.3: Ball in center

Figure 3.3 is an illustration of the scan where the search object is found in the

middle of the scan.

What happens in the transitions in Module 1:

• tScan1_post.m is shown here:

function [] = tScan1_post(transition)

global global_info;

ACTION_scanDistance;

b2 = 1;

end

• As shown in the code, the tScan1_post. m �le calls ACTION_ScanDistance.m,

where in the end of the code the edge detector is as seen here:

% check if target is at edge of scan-area.

if distance(1) > 0 || distance(2) > 0 || distance(37) > 0 || distance(38) > 0


global_info.edgeDetected = 1

else


end

• Here the tDToTarget_pre checks that the edgeDetect from the code above

is 0 and that there is a token at p5 as seen here:

function [fire, transition] = tDToTarg_pre(transition)

global global_info;

b4 = get_place('p5');

if global_info.edgeDetected == 0 && b4.tokens == 1;

fire = 1;

end

• tDToTarget_post calls ACTION_DriveToTarget.m as seen here:

function [] = tDToTarg_post(transition)

ACTION_DriveToTarget;

end

• tClose_pre check if falseTarget is 0 as seen here:

function [fire, transition] = tClose_pre(transition)


global global_info;

if (b5.tokens && global_info.falseTarget == 0)

fire = 1;

else

fire = 0;

end


• If tClose �red then tClose_post will call ACTION_CloseClaw.m as shown

here:

function [] = tClose_post(transition)

pause(5);

disp('Target aquired!! These ARE the droids we are looking for');

ACTION_CloseClaw;

end

• After the robot has picked up the search object tRot180 �res and tRot_post

calls ACTION_Rotate180.m as shown here, which makes the robot rotate

180 degrees

function [] = tRot180_post(transition)

ACTION_Rotate180;

end

• tBorder �res and in tBorder_post ACTION_FindBorder.m is called, which

uses the light sensor to �nd the border and will make the robot stop before

driving outside the search area.

function [] = tBorder_post(transition)

ACTION_FindBorder;

end

• After the border is found tOpen will �re and in tOpen_post ACTION_OpenClaw.m

is called, as seen here, which opens the claw and releases the search object


function [] = tOpen_post(transition)

ACTION_OpenClaw;

end

• The tReverse �res and calls ACTION_Reverse.m as seen here, and the

robot reverses

function [] = tReverse_post(transition)

ACTION_Reverse;

end

• Then the robot rotates when tRot1802 calls ACTION_Rotate180.m as

seen here


ACTION_Rotate180;

end

• Then it drives forward a bit when tForward calls ACTION_Forward.m

when �ring as seen here

function [] = tForward_post(transition)

ACTION_Forward;

end


• tBu�er is just a transition we added after we could not run without it for

some unknown reason

function [fire, transition] = tBuffer_pre(transition)


fire = b12.tokens;

• tDone works as a sink and will �re when p18 have 5 tokens, which is when

5 objects have been found and placed outside the search area. A typical

run is shown in Example run.

Module 2:

The robot detects an object, but it has be detected on either edge of the sensor

while in the scan sequence. The robot will therefore position itself towards

where it thinks the ball is, scan again, position itself towards the ball according

to the new scan, then move into module 1. This module was created in order to

make sure that the robot correctly �nds object. While testing, we found that

without this module the robot often missed the search object and sometimes

bumped it out of the search area.

Figure 3.4: Petri Net graph of Module 2



1. Object detected in edge of the sensor in the scan sequence

2. Redirects itself towards the detected object

3. Scans again

4. Position itself towards of the detected object

5. Drives to object

6. Continues like in Module 1:

Note: At point 3 if the sensor does not detect anything will lead to the program

will stop, but while testing and simulating this was not a problem. The reason

for this module is to recalculate the rotation angle in order for the robot to more

accurately drive to the object it already found.

Figure 3.5: Sensor read when ball is on the edge

Object detected on the edge of the sensor: As seen in �gure 3.1.3; the object

was found in the beginning of the scan. When the robot completes the sequence

it will believe that the center of the search object is located in the where the

red point is marked. Since the robot might not have scanned the entire search

object, this might be inaccurate. It will therefore rotate towards the marked

point, then do another 90 degree scan. This is to ensure that the robot scans the

entire search object and get and more accurate reading. The same will happen

if the sensor will scan the closes object in the end of the 90 degree scan.


Figure 3.6: Ball on edge

Figure 3.6 is an illustration of when the robot scans and don't scan the whole

search object by it being on the edge of the scan. The same will happen if the

search object will be scanned on the other edge.


In the end of ACTION_ScanDistance.m it will detect if the object is found in

the beginning or the end of the scan as shown here:




else


end

• When there is a token at p5, tEdge is enabled. tEdge_pre.m will check

that edgeDetect is 1 and will �re as shown here:


function [fire, transition] = tEdge_pre(transition)

global global_info;


if b5.tokens && global_info.edgeDetected == 1

fire = 1;

else

fire = 0;

end

• tScan3 will �re and tScan3_post calls ACTION_ScanDistance.m as seen

here, which makes the robot scan again to recalculate the position of the

search object:


ACTION_ScanDistance;

end

• When tToTarg �res tToTarg_post.m will call ACTION_RotateToTarget.m

as seen here, making the robot turn to the search object

function [] = tToTarg_post(transition)

ACTION_RotateToTarget;

end

• The robot will now continue like in Module 1:


Module 3:

No object detected: All points scanned are over 100 cm; this means that there

are no objects in the current scan, and the robot will continue to search towards

the left. If the robot has search an entire 360 degree rotation, but has still not

found any objects, the robot will move a certain distance forward, then start

scanning again.

Figure 3.7: Petri Net Graph of Module 3


1. Scans

2. Nothing detected

3. Continue scan to the left another 90 degree

4. Repeat 3. until scanned 360 degrees

5. If nothing is found after scanning 360 degrees; drive forward, if something

is found; continue like in Module 1:

6. Back to 1

In �gure 3.7 after tScan1 �res, P3 will receive a token. If an object is found

tTarget will �re and the token from P3 will be placed in P4, but if nothing is

detected tNoTarg will �re and a token will be placed in P14. A new scan will

start (the robot just continues to scan to the left) and a token is placed in P15,

if an object is found tTarget2 will �re and the token from P15 will be placed in


P4, but if nothing is detected tNoTarget2 will �re and a token will be placed

in P14 and P16. It has now scanned 180 degrees. This will loop until P16 has

three tokens and t360Scanned �res or the sensor �nds something and tTarget2

�res and continues like in Module 1:. If t360Scanned �res three tokens will be

taken from P16 and one will be placed in P17. After that, tForward2 will �re

making the robot move forward a bit and a token will be placed in P2 and will

continue. tCleanUp1 and tCleanUp2 works as sinks, these will take the excess

tokens from P16 if tTarget2 �res.

Figure 3.8: Sensor read when nothing is detected

Figure 3.8 shows what the sensor read out looks like when no objects are found.


Figure 3.9: Ball is out of sight

Figure 3.1.3 is an illustration of the search object is outside of the scan of the

robot


In the end of ACTION_ScanDistance.m which is called in the tScan1 it will

check if there is an object near by as seen here:

% % Confirm target detection and plot destination

finalTarget= tachoArea(int8(length(tachoArea)/2));

if distance > 100

global_info.targetAcquired = 0;

elseif distance < 100


plot(finalTarget/5,distance(finalTarget/5),'-*r');

end

• When a token is in p3 tTarget and tNoTarg are enabled, if targetAcquired


is 0 then tNoTarget will �re as shown here:

function [fire, transition] = tNoTarget_pre(transition)

global global_info;

% global targetAcquired;


if ((b2.tokens == 1) && (global_info.targetAcquired == 0))

fire = 1;

else

fire = 0;

end

• When tScan2 �res it calls ACTION_ScanDistance2.m in tScan_post.m

as shown here, this will make the robot scan another 90 degrees to the left


ACTION_ScanDistance2;

end

• ACTION_ScanDistance2.m works like ACTION_ScanDistance.m and will

also have an targetAcquired like shown above. After tScan2 has �red a

token is placed in p16 which enables tTarget2 and tNoTarget2, if target-

Acquired is 1 tTarget2 will �re and it will continue in Module 1:, however

if targetAcquired is 0 tNoTarget2 will �re putting a token in p16 and one

in p14 as seen here:

function [fire, transition] = tNoTarget2_pre(transition)

global global_info;





fire = 1;

else

fire = 0;

end

• When a token is placed in p14 tScan2 will be enabled again and make it

scan again. If target is acquired tTarget2 will �re and it will continue in

Module 1:, and tCleanUp1 will also �re, sinking the excessive token. If

no target is acquired tNoTarget 2 will �re again putting another token

in p16. This will continue until a target is acquired or t360Scanned is

enabled when 3 tokens is at p16 and one token is at p14 as shown here:

function [fire, transition] = t360Scanned_pre(transition)

display('WE ARE IN T360SCANNED_POST');



fire = (b15.tokens == 3) && b13.tokens;

• tForward2 will now be enabled and when �ring it calls ACTION_Forward.m

as seen here:


ACTION_Forward;

end

• After driving forward it will continue like in Module 1:


Module 4:

Object detected outside search area (false target): While scanning, the robot

might detect an object it have already removed from the search area. When this

happens, the robot will drive towards the object like in Module 1:, but when the

search area border is detected with the light sensor, the robot will stop rotate

180 degrees and search again.

Figure 3.10: Petri Net of Module 4


1. The NXT starts to scan

2. Finds an object

3. Positions itself towards the object

4. Drives to the object

5. Border is detected

6. Stops

7. Turns 180 degrees

8. Drives forward

9. The NXT robot starts to scans again


Note: While testing we experienced that the robot got stuck when we made

the search area in various shapes. It might get stuck in an in�nite loop if two

search objects are on each side of a corner and the robot is searching between

that corner. It will end up with scanning, �nding an object, being stopped by

the border, turn around, scan again and �nd the other object and continue like

this until the battery dies. To make sure this does not happen, the search area

should be as circular as possible.

Figure 3.11: Object detected outside search area

Figure 3.11 is an illustration of the NXT robot when it �nds an object outside

the search area. The search area is a black line and the robot will detect it when

driving towards the search object with the light sensor, which is pointing to the

�oor.


• In the end of ACTION_DriveToTarget.m which is called in tDToTarget

in will check the light sensor if it �nds the border of the search area as

seen here:

OpenLight(SENSOR_2, 'ACTIVE');


light = GetLight(SENSOR_2);

if light > 350

global_info.falseTarget = 1;

end

CloseSensor(SENSOR_2);

end

end

disp('falseTarget');

global_info.falseTarget

• When a token is placed in p6 tClose and tFalseTarget is enabled, if the

falseTarget is 0, tClose will �re and continue like in Module 1:, however if

falseTarget is 1 then tFalseTarget will �re as shown here:

function [fire, transition] = tFalseTarg_pre(transition)

global global_info;



fire = 1;

else

fire = 0;

end

• Then tRot1803 �res and calls ACTION_Rotate180.m in tRot1803_post.m

as shown here, making the robot rotate 180 degrees


ACTION_rotate180;

end


• Then tForward2 �res and calls ACTION_Forward.m in tForward2_post

as shown here, making the robot drive forward a bit


ACTION_Forward;

end

• After driving forward it will continue like in Module 1:


Complete search routine

When all 4 modules are combined, we get the complete Petri NET:

Figure 3.12: Complete Petri Net graph

Chapter 4

Testing, analyzing and result

In our testing we tried di�erent search objects; like cans, balls and building

small square pieces with Lego. We found that the balls worked the best for the

ultrasonic sensor. In this chapter we will look at the di�erent problems and

bugs we found while testing and programming.

4.1 Example run

To give the reader a good overview of the systems functionality, a step-by-step

example run will be presented below.

35

CHAPTER 4. TESTING, ANALYZING AND RESULT 36

Figure 4.1: Here we assume that the bluetooth connection has been establishedand that the software has been started according to the user manual. The userwill here push the start button and the routine will begin. The �rst action therobot will do is a 90 degree scan, illustrated by the blue �eld in front of therobot.


Figure 4.2: The robot will here detect the ball and, position itself towards it.


Figure 4.3: Then the ball will drive towards to ball stopping directly in front ofit. It will then close its claw, securing the ball


Figure 4.4: After the robot has secured the ball it will turn 180 degrees.


Figure 4.5: Once the robot has repositioned itself it will drive until it reachesthe border.


Figure 4.6: As the robot reaches the border, the light sensor will detect thechange in color and the robot will stop. When the robot has stopped the clawwill open to release the ball.


Figure 4.7: Once the ball is released, the robot will drive backwards, reenteringthe search area.


Figure 4.8: The robot will then rotate 180 degrees so that it is pointing towardsthe center of the area. After it has rotated, it will drive forward by a �xedlength.


Figure 4.9: When the robot has stopped, it will scan again. In this case thereare no balls in the search area and it will continue search in 90 degree intervalsuntil it has searched a full 360 degrees.


Figure 4.10: When the robot has scanned 360 degrees around one point withoutdetecting any balls it will drive forward.


Figure 4.11: The robot will then scan a new 90 degree area. Again the robotwill fail to detect any balls any will continue scanning another 90 degrees.


Figure 4.12: On the next scan it will detect a ball, however it is on the edge ofthe search area.


Figure 4.13: The robot will therefor position itself towards where it thinks theball is an scan again. This is to ensure that it positioned correctly towards theball.


Figure 4.14: As earlier the robot will now position itself towards the ball, anddrive towards it.


Figure 4.15: Once it has reached the ball, it will grab it and rotate 180 degrees.


Figure 4.16: The robot will then drive forward until it reaches the border. Letgo of the ball, and reverse as shown earlier.


Figure 4.17: It will again rotate 180 degrees so that it is pointing towards thecenter of the search area.


Figure 4.18: Again it will start to scan. This time, the robot will have to scan360 degrees until it �nds the last ball.


Figure 4.19: Once the ball is detected it will position itself towards it, and driveforward.


Figure 4.20: When the robot stops, it will close the claw to secure the ball.


Figure 4.21: After the ball has been secured, it will rotate 180 degrees. Anddrive towards the border. Once the robot has reached to border and release theball, the program is complete.


Below is a table which show estimate times the robot uses to perform di�erent

actions. The times here are found during a test where the ball was 20 cm

away from the robot during the scan sequence, and it had to travel 1m to reach

the border. The times here are given as a rough estimate. Exact times are not

possible to acquire for all actions due to the random nature of the balls locations

in the search area.

Action performed Time taken

Normal Scan 29s

Reposition towards ball 5s

drive to ball (20cm) 7s

close claw 4s

Drive to border (1m) 6s

open claw 4s

Drive backwards 2s

Rotate 180 degrees 5s

Drive forward 5s

A short video was created that shows the search function of the robot which

will be available if reader access to complete zip �le

4.2 Limitations and challenges

- Bluetooth

Connecting the NXT to MATLAB using bluetooth takes a lot of time, the NXT

will only connect to certain types of bluetooth radios or external bluetooth

dongles.

- NXT limitations

The NXT cannot send and receive signals at the same time. Transferring large

amount of data is something the NXT cannot handle. One challenge was if the

Clean-up robot detected one of the object it had already cleaned up and placed

outside the search area. The NXT could not continuously scan to check if it

was within the search area using the light sensor, while scanning for objects

using the ultrasonic sensors. This makes the scanning routine very slow. The

NXT has only 130 kB storage space, which might not be a big problem since


programs use little storage space, but if desired to have custom sound on the

NXT the storage space will be used up with only a few �les.


- Lego bricks

We were given a building set with only enough pieces to build the di�erent

robots from that the set. The robots from that set could not preform the tasks

we wanted, they had no grabbing mechanism. The robot we created is not

completely symmetrical in its looks since we did not have enough pieces. There

was not enough pieces to build the claw like we wanted; had a desire to build a

claw that would lift up the search object when grabbing it.

- Servo motors

Using two individual and unique motors, the do not rotate at the same speed.

One motor always start a short time before the other, causing the robot to turn

a bit when we program it to go straight forward. Sometimes it has problems

with very small rotations. This may cause the robot to miss its intended target.

- Sensors

The ultrasonic sensor has sometimes hard time sensing when it comes to di�erent

object, for example if you are creating an obstacle avoidance program using the

ultrasonic sensor as detection sensor it can avoid a square item which is standing

perpendicular to the ultrasonic sensor, but if the �nds the object in a di�erent

angle, then it gets inaccurate reading which may result in the robot bumping

into the items.

- Battery and recharging

The NXT is battery driven, and it needs to be charged time to time. When

the battery is not fully charged, the robot sometimes have a hard time making

small turn or it works slower.

4.3 Analyzing

By doing test-runs with the robot we have seen that the program itself runs

correctly through all stages of the petri-net. However the inaccuracy of the

hardware components on the robot will sometimes lead to failures in the pro-

grams functionality. For instance if the robot detects a ball and is to drive

forward to the ball, it might not drive straight enough to be able to position


itself correctly. This may result in a failure to grab the search object, and even

though it fails to grab the search object the NXT will continue without remov-

ing the search object from the search area. If program is set to �nd a speci�c

amount of search objects, this will result in a search object is left in the search

area.

When the robot has found an object, grabbed it and is on its way to put it

outside the search area, if there are some objects in the way, the robot will

simply drive straight towards it and hitting it. While testing

No module was for created a scenario where two search objects were place right

next to each other. If this scenario would happen then the program created

would just read the two objects as one big object and drive in the middle of

them, picking up both or none. While testing, the search objects would always

be placed apart from each other so this would not happen.

4.4 Result

The clean-up robot got completed and works like it is suppose to, but with the

limitations and challenges mentioned. The routine is fully autonomous like we

wanted it to be. In ideal conditions (set search environment, search objects

placed apart and good lighting) the robot can run by its self. With the limited

resources and time we are satis�ed with the outcome. We have reached the

conclusion that using a model and simulation approach to program a robot in

this intended level of autonomy will be too poor compared to other types of

programming.

In this report we included a building instruction on how to build the exact

model we created found in Building guide, a full user guide on how to run the

program we created with the robot model found in User manual for Lego NXT

Clean-up robot and installation guide on what programs are needed to run the

program created found in C.

Chapter 5

Discussion

Discussion of the limitation and the challenges and possible solutions.

5.1 Connection

Since bluetooth is the only wireless connection available on the NXT kit we are

bound to use it if we don't want a long USB cable hanging from it. Bluetooth

makes it di�cult to send and receive data at the same time. The NXT brick also

has a 30ms latency when it switches from receiving data to sending data which

means that the expected latency for a sensor reading request is 60 ms. If this

was on an industrial level, it might be a problem and even dangerous. On [14]

it is recommended to use USB for real time programming, but then we would

need a long USB cable and the robot might detect the cable as an obstacle. A

WiFi connection would be more preferable, since it process more data and also

easier to connect..

5.2 Petri Net

Using Petri Net to program a robot is workable, but not ideal. Many times

while working with this project we felt that Petri Net programming limited us

too much. Since we wanted to program an autonomous robot it is hard using

Petri Net since its execution is non-deterministic: when multiple transitions are

enabled at the same time, any of the enabled transitions may �re (but don't

63

CHAPTER 5. DISCUSSION 64

have to). Petri nets are more suited for concurrent programming, which in this

case it is not. Creating a program directly in MATLAB would be easier and

possibly better.

5.3 Further work

There are several things that can be added to this project.

• Speed

The robot has a slow search routine since its calculations are slow and the

NXT cannot process large amounts of data at the same time. This can be

compensated by adding more robots to the search area, this can be controlled

using swarm intelligence[9], where the robots share their current position so each

robot searches a distinct part of the search area, and avoids colliding with each

other. This will severely decrease the time it takes to clear the area of objects.

• Increased accuracy

One of the most important things that this robot needs is an increase in accur-

acy. The robot needs mainly two things to increase its performance, increase

in measurements from the sonar, so that the robot will stop at the correct dis-

tance from the ball. And increase the motorcontrol so that the robot can drive

straighter than it currently does, this is to ensure that the robot actually hits its

designated target. This can be achieved by scanning for the ball several times

as the robot is advancing towards it. This will however severely increase the

time the robot uses to clear objects from the search area. Another method that

could be used is to add use a camera, either on the robot or externally with a

overhead view and using object detection[12] algorithms. Some of these meth-

ods are covered in [15], but here the program was not created with GpenSIM,

but directly in MATLAB.

• Color detection

The robot can be �tted with a color sensor, so that it can remove balls with a

certain color.

CHAPTER 5. DISCUSSION 65

• Obstacle detection

For the robot to be fully autonomous, it would need an obstacle detection sensor.

All 4 sensor ports were used in this robot, but by adding an additional NXT

programmable brick, you will get another 4 sensor ports.

• Communication

As mentioned earlier in this report we had severe problems with the bluetooth

connection. Improving this connection or �nding alternative forms of commu-

nication would make the robot a lot more user friendly.

• Tracking

It would be ideal if the robot could remember where it has searched before so

it wouldn't have to search there again, which would increase the speed of the

routine. And it also would be better if the robot could place all the search

object in one place.

• New claw design

When building the robot a di�erent claw design was desired; one where the

claw would lift up the object the robot found. We would also like the claw to

be bigger, so accuracy will be better.

Chapter 6

Image Reference

• Figures 3.2, 3.1.3 and 3.8 are graphs showing the ultrasonic sensor readouts

that were sent to MATLAB

• Figures 3.12, 3.1, 3.1.3, 3.7 and 3.10 are drawn using PIPE21

• Figures 2.3, 2.4, 2.2 and 2.5 found at

http://www.brickset.com/browse/themes/?theme=Mindstorms&subtheme=NXT

• Figures 3.3, 3.6, 3.1.3 and 3.11 the Lego model was created using Lego

Digital Designer2 and edited with Paint.net3

1PIPE2 is an open source, platform independent tool for creating and analyzing Petri netsincluding Generalized Stochastic Petri nets.

2LEGO Digital Designer, or LDD, is a free computer program produced by the LEGOGroup as a part of LEGO Design byME. The program allows users to build models using vir-tual LEGO bricks, in a computer-aided design like manner. Found here: http://ldd.lego.com/

3Paint.NET is free image and photo editing software for computers that run Windows.Found here: http://www.getpaint.net/

66

http://www.brickset.com/browse/themes/?theme=Mindstorms&subtheme=NXT

http://ldd.lego.com/

http://www.getpaint.net/

Bibliography

[1] Reggie Davidrajuh. GPenSIM: A New Petri Net Simulator, Petri Nets

Applications, Pawel Pawlewski (Ed.), ISBN: 978-953-307-047-6. InTech,

2010.

[2] Richard M. Deci, Edward L.; Ryan. The support of autonomy and the

control of behavior. Journal of Personality and Social Psychology, Vol

53(6):1024�1037, Dec 1987.

[3] Wikipedia The Free Encyclopedia. "lego mindstorms nxt - sensors".

http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT.

[4] Roar Fjellheim. Ai and autonomy in oil and gas, March 2012. NFA

Autonomy in oil and gas industry.

[5] Hassane Alla Francois Charbonnier and René David. The supervised con-

trol of discrete-event dynamic systems. 7 no. 2:1, March 1999.

[6] Sta�an Ekvall; Danica Kragic; Patric Jensfelt;. Object detection and map-

ping for service robot tasks. Robotica, Volume 25 Issue 2:175�187, March

2007.

[7] Lego. Lego digital designer. http://ldd.lego.com/.

[8] Lego. "nxt" retrieved april 13, 2012 from lego.com.

http://mindstorms.lego.com/en-us/whatisnxt/default.aspx.

[9] Alcherio Martinoli. Swarm intelligence in autonomous collective robotics:

From tools to the analysis and synthesis of distributed control strategies.

1999.

[10] MathWorks. Matlab - the language of technical computing.

http://www.mathworks.se/products/matlab/.

67

BIBLIOGRAPHY 68

[11] Robert W. Hogg; Arturo L. Rankin; Stergios I. Roumeliotis; Michael C.

McHenry; Daniel M. Helmick; Charles E Bergh; Larry Matthies. Al-

gorithms and sensors for small robot path following. Proceedings of the

2002 IEEE International Conference on Robotics 8 Automation, May 2002.

[12] Constantine P. Papageorgiou; Michael Oren; Tomaso Poggio;. A general

framework for object detection. Center for Biological and Computational

Learning , Arti�cial Intelligence Laboratory , MIT.

[13] RWTH. Install guide. http://www.mindstorms.rwth-

aachen.de/trac/wiki/Download#InstallationGuide.

[14] RWTH Aachen University. "rwth - mindstorms nxt toolbox for matlab" re-

trieved february 6, 2012 from:. http://www.mindstorms.rwth-aachen.de/.

[15] Marco Casini; Andrea Garulli; Antonio Giannitrapani; Antonio Vicino. A

matlab-based remote lab for multi-robot experiments.

Appendix A

Building guide

See additional �le Building Instructions [claw].html

69

Appendix B

User manual for Lego NXT

Clean-up robot

B.1 Introduction

This is a small user manual for the Lego NXT Clean-up robot. If you have not

read the installation guide, do it now. The Clean-up robot is extremely easy to

use once you have been able to get the bluetooth connection up and running.

B.2 The search area

The �rst thing you need to do is to create your search area and place out the

balls that come with the NXT kit. The search area should have a white border

made from, for instance white A4 papers. It is important that the search area is

placed on a dark colored �oor and that the border is white, so that the robot is

able to distinguish between the search area and the border. We recommend an

area with a diameter of roughly 1.5 to 3 meters. Once the search area is ready

place as many balls as you want within its borders, preferably minimum 30cm

apart, this is so that the robot does not confuse two or more balls for one ball.

It is also advised that the area is built where there are few objects close to the

border, since this might lead to the robot �nding objects outside of the search

area, resulting in a prolonged search time.

70

APPENDIX B. USER MANUAL FOR LEGO NXT CLEAN-UP ROBOT 71

Figure B.1: Search Area

APPENDIX B. USER MANUAL FOR LEGO NXT CLEAN-UP ROBOT 72

B.3 Adjusting and starting the program

Once the search area is ready you need to open MATLAB and go to the folder

containing the program. If you have recently gone through the installation

manual you should have the robot connected to the computer over bluetooth,

if not run the connect.m �le, make sure that the motorcontroller program is

running on the NXT.

Open the NXT_ClawBot_def.m and change the variable numberOfBalls to the

number of balls that you have on your search area, then place your robot near

the border of the search area, facing inwards. Run the �les NXT_ClawBot.m,

you should hear a beep from the robot to con�rm that the program has started.

When you are ready press the push button on the robot and stand back. The

robot will now start to remove the balls from the search area and it will stop

when all the balls have been removed.

Appendix C

Installation guide for Lego

NXT Clean-up robot

Building instructions for the robot can be found in Appendix 1B and Appendix

2B. There you will �nd a HTML version and a Lego digital designer �le, in the

latter you can view the build instructions while being able to rotate the model.

To be able to use this, you have to download and install Lego digital designer,

found at [7].

C.1 Installing software

There are numerous software and drivers needed to be able to run the robot

from a computer.

C.2 RWTH Mindstorms NXT Toolbox

A link to the download site has been given in [13]. Download the newest, stable

version. This project used version 4.7, however if a newer, stable versions have

been released this should work as well. Once the toolbox has been downloaded,

�nd the readme.txt �le and follow the instructions carefully. Some things are

especially important, checking that the NXT has the correct �rmware version,

checking that the bluetooth adapter is compatible and when you create the

bluetooth.ini �le, that you are sure you have the correct COM port or MAC

73

APPENDIX C. INSTALLATIONGUIDE FOR LEGONXT CLEAN-UP ROBOT74

address. Also make sure that you have updated the driver for the bluetooth

adapter.

C.3 Installing the program

The program for the Clean-Up bot needs to be installed on your computer. To

do this, follow these steps.

1. Place the program �les in a suitable folder.

2. In MATLAB, go to File -> Set Path and select the folder where you placed

the �les. Then click Add with sub folder.

C.4 Setting up the bluetooth.ini �le

Once you have everything correctly installed, you have to set up the blue-

tooth.ini �le, you can either do this manually by looking at the example �les

that came with the toolbox, or use the script as explained in the readme �le.

Remember that on windows 7, you have to use MAC address and on other

windows version you have to use COM ports.

• COM ports.

To �nd your com port, you can double click the bluetooth icon on the right part

of your task bar. The click the COM Ports tab. Here you should see two COM

ports listed, one for outgoing and one for incoming. The bluetooth.ini �le needs

to have the outgoing com port addressed to it. If there are only one COM port

listed, you have to add the second one, simply press �add� and select the NXT.

• MAC address

To �nd the correct MAC address, you need to press start -> run, type in �cmd�.

In the window that opens type in �ipcon�g /all�. On the following information

look for �physical address� There should be 12 letters and numbers following

this line, that is your mac address.

Example: Physical address . . . . . . 00-0F-FE-54-37-C1


C.5 Connecting to the NXT

Once you have the bluetooth.ini �le, you can move it to the same folder as

the program. When you have done that you can go to your NXT, navigate to

the bluetooth menu and select �search�. The NXT should now search for your

computers bluetooth. Once the NXT has found the bluetooth, select it and

con�rm the passkey �1234�. There should now pop up a bluetooth noti�cation

on your computer, enter the same passkey and hopefully you have been able to

connect the NXT to your computer through bluetooth.

If this fails, you can try to go the other way, by searching for bluetooth units

on your computer. To do this double click the bluetooth icon on the right on

your task bar and select �add�. Make sure that the NXTs bluetooth is turned

on, check the box that says �My device is set up and ready to be found� and

press �next�. Once you �nd the NXT, double click it, you will now get a similar

passkey on the computer and the NXT, enter 1234 as before. When you have

done this, double check the COM-ports and mac address, if they have changed,

change them accordingly in the bluetooth.ini �le.

Once you have done all this you can go on the NXT to Bluetooth and then to

My Contacts. The computer should appear here now.

Run the connect.m �le in MATLAB and select the computer on the NXT, press

connect on the NXT and select 1. If everything was successful you should now

have connected the NXT to the computer. One way to verify that you have been

able to connect, is to check that the motorcontroller program has started

on the NXT.

C.6 Troubleshooting the bluetooth connection

Unfortunately the bluetooth connection is very hard to get stable, if you cannot

connect the devices together there are several things that you can try.

• Keep trying to connect as explained before, also rebooting the NXT once

in a while.

• Try pairing the bluetooth and the computer all over again, remember to

check MAC address / COM ports.

• Try a di�erent computer.


• It also appears that Mac computers handle bluetooth much better than

windows, if you have one available I highly suggest you try to use it �rst

Appendix D

MATLAB code

D.1 Action Commands

The software has a series of �les called action commands; these tell the robot

what actions it should take. Below is a list of all the �les, and what actions the

robot will do.

ACTION_CloseClaw.m

This action will rotate the center motor, causing the claw to go from open

position to closed position, enabling the robot to grab the spheres lying around

the search area.

It is important that this command is not sent to the robot while the claw is

already closed, this will cause the motor to try to reach a position it is not able

to go to.

global portC;

global global_info;

mClaw = NXTMotor(global_info.portC); %

mClaw.SpeedRegulation = true; %

mClaw.Power = 20; % positive = close

mClaw.TachoLimit = 35;

mClaw.ActionAtTachoLimit = 'Brake';

77

APPENDIX D. MATLAB CODE 78

mClaw.SendToNXT();

ACTION_OpenClaw.m

Similar to ACTION_CloseClaw.m however, the claw will now open.

global portC;

global global_info;

pause(1)

mClaw = NXTMotor(global_info.portC); %

mClaw.SpeedRegulation = true; %

mClaw.Power = -20; % positive = close

mClaw.TachoLimit = 35;

mClaw.ActionAtTachoLimit = 'Brake';

mClaw.SendToNXT();

ACTION_DriveToTarget.m

The DriveToTarget action will drive forward towards the search object so that it

is within reachable distance for the claws. The robot will stop at given distances

and scan the light level of the surface it is currently on, this is to ensure that

the robot does not exit the search area. The distance it will drive has been

calculated in the scanDistance actions.

%drive to target

global global_info;

global MOTOR_A

global portM

global finalTarget

global distance

global falseTarget

falseTarget = 0;

drivenDistance = 0;

targetReached = 0;

while targetReached == 0 && falseTarget == 0;


if (distance(finalTarget/5)*18) - drivenDistance > 360

mTurn1 = NXTMotor(global_info.portM); % ports swapped because it's nicer

mTurn1.SpeedRegulation = false; % we could use it if we wanted

mTurn1.Power = 80;

mTurn1.TachoLimit = 360;

mTurn1.ActionAtTachoLimit = 'Brake';

mTurn1.SendToNXT();

pause(2)

drivenDistance = drivenDistance + 360;


light = GetLight(SENSOR_2)

if light > 350

targetReached = 1;


end


elseif(((distance(finalTarget/5)*18) - drivenDistance <= 360) && falseTarget == 0)



mTurn1.Power = 80;

mTurn1.TachoLimit = ((distance(finalTarget/5)*18) - drivenDistance+5); %- drivenDistance;


mTurn1.SendToNXT();

pause(2)

targetReached = 1;



if light > 350



end


end

end

disp('falseTarget');

global_info.falseTarget

ACTION_FindBorder.m

This action will be sent to the robot after it has obtained an item. The action

will cause the robot to drive forward until it reaches the border of the search

area, so that it can release the ball, hence, removing it from the search area.

Again the robot will stop at given distances and scan the light level so that it

can detect when it has reached the border.

%drive forward


global global_info;

global portM

trigger = 1;

while trigger;


if light < 350;



mTurn1.Power = 80;



mTurn1.SendToNXT();

elseif light > 350;




mTurn1.Power = 80;



mTurn1.SendToNXT();

trigger = 0;

end

end;


ACTION_Forward.m

When given this command, the robot will simply drive forward a set distance.

This is typically used after it has completed a full 360 degree scan without

�nding any objects.

global global_info;

global portM;

global finalTarget;

global distance;

mTurn1 = NXTMotor(global_info.portM);

mTurn1.SpeedRegulation = false;

mTurn1.Power = 80;

mTurn1.TachoLimit = 300*3;


mTurn1.SendToNXT();

% mTurn1.WaitFor();

pause(2)

ACTION_Reverse.m

This action is similar to ACTION_Forward but will go backwards instead of

forward. This is used after the robot has removed a ball from the search area,


so that the ball is clear of the claw.

global global_info;

global portM

global finalTarget

global distance



mTurn1.Power = -80;



mTurn1.SendToNXT();

ACTION_Rotate180.m

When the ACTION_Rotate180 command is sent to the robot it will rotate 180

degrees. This is typically used after the robot has removed a ball from the

search area and backed away from the ball. This will position the robot so that

it is facing towards the center of the search area.

global global_info

% Turn 90 degress to right

pause(1)

mTurn1 = NXTMotor(global_info.portM(1)); % ports swapped because it's nicer


mTurn1.Power = -40;



mTurn1.SendToNXT();




mTurn1.Power = 40;

mTurn1.TachoLimit =376;


mTurn1.SendToNXT();

pause(3)

ACTION_RotateToTarget.m

This action will be used after one of the ScanDistance actions has found an

object. During the ScanDistance actions the program will know how far the

robot has rotated when each distance measurement has been taken. By doing

this, we know how far the robot has to rotate to be able to face to object.

%turn to destination

global global_info;

global tachoLength;

global finalTarget;

global distance;

pause(1)



mTurn1.Power = -30;

mTurn1.TachoLimit = (max(tachoLength)-finalTarget)+10;


mTurn1.SendToNXT();



mTurn1.Power = 30;

mTurn1.TachoLimit = (max(tachoLength)-finalTarget)+10;


mTurn1.SendToNXT();

pause(3)

%check distance to target.

OpenUltrasonic(global_info.portUS, 'snapshot');


distanceCheck = GetUltrasonic(global_info.portUS);

CloseSensor(global_info.portUS);

%drive forward

ACTION_ScanDistance.m

When this action is sent to the robot it will �rst rotate 45 degrees to the right,

then rotate 90 degrees to the left. While rotating to the left the robot will stop

at certain intervals, scan in front of it, save the distance which is returned from

the scan and how far it has rotated at that scan. When it has �nished rotating

it will check if it has detected any objects.

function [tachoLength,finalTarget] = scanDistance()

% portUS = SENSOR_4;

% PortM = [MOTOR_A,MOTOR_B];

% PortC = [MOTOR_C];

% portA = [SENSOR_1];

global global_info

global h;

global tachoLength;

global finalTarget;

global distance;

global targetAcquired;

global edgeDetected;

COM_SetDefaultNXT(h);

clear figure(1)

clf

figure(1)

hold on

grid on

global_info.tachoLength = zeros(500,1);


global_info.distance = zeros(500,1);

n = 8; % bytes the US sensor received

count = 38; % how many readings until end?

plotcols = 8; % how many out of n echos to plot?

outOfRange = 160; % setting for out of range readings

targetAcquired = 0;

data = zeros(1, n);

allX = (1:count+1)';

edgeDetected = 0;

% Turn 45 degress to right

pause(1)



mTurn1.Power = -40;



mTurn1.SendToNXT();



mTurn1.Power = 40;



mTurn1.SendToNXT();

pause(3)

%start sweep and search

for i = 1 : count



mTurn1.Power = 20;



mTurn1.SendToNXT();




mTurn1.Power = -20;



mTurn1.SendToNXT();

pause(0.8)

if i == 1;

tachoLength(i) = 5;

else

tachoLength(i) = tachoLength(i-1) + 5;

end


distance(i) = GetUltrasonic(global_info.portUS);

CloseSensor(global_info.portUS)

plot(i,distance(i),'-*')

%

end%for

%determine closest target

global target

target = min(distance(1:i));

%remove other measurements ( above 100cm)

for j=1:i;

if distance(j) > target +5 || distance(j) < target - 5

distance (j) = 0;

elseif distance(j) == 100

distance(j) = 0;

end


end

v = 1;

targetArea = zeros(1);

tachoArea = zeros(1);

%find area of block

for u=1:i;

if distance(u) > 0;

temp = zeros(length(targetArea),1);

temp2 = temp;

temp = targetArea;

temp2 = tachoArea;

targetArea = zeros(length(temp)+1);

targetArea = temp;

tachoArea = zeros(length(temp2)+1);

tachoArea = temp2;

clear temp;

clear temp2;

targetArea(v) = distance(u);

tachoArea(v) = tachoLength(u);

v = v + 1;

end

end

%Confirm target detection and plot destination

finalTarget= tachoArea(int8(length(tachoArea)/2))

if distance > 100

global_info.targetAcquired = 0



global_info.targetAcquired = 1


end




else


end

ACTION_ScanDistance2.m

This action is used if the ACTION_ScanDistance.m does not detect any ob-

jects. The robot will then rotate another 90 degrees while scanning, saving the

distances and how far it has rotated. This action will continue to run until the

robot detects an object, or until the robot has rotated 360 degrees.

function [tachoLength,finalTarget] = scanDistance()

% portUS = SENSOR_4;

% PortM = [MOTOR_A,MOTOR_B];

% PortC = [MOTOR_C];

% portA = [SENSOR_1];

global global_info

global h;

global tachoLength;

global finalTarget;

global distance;

global targetAcquired;

COM_SetDefaultNXT(h);

clear figure(1)

clf

figure(1)

hold on


grid on

global_info.tachoLength = zeros(500,1);

global_info.distance = zeros(500,1);

n = 8; % bytes the US sensor received

count = 38; % how many readings until end?

plotcols = 8; % how many out of n echos to plot?

outOfRange = 160; % setting for out of range readings

targetAcquired = 0;

data = zeros(1, n);

allX = (1:count+1)';

%start sweep and search

for i = 1 : count



mTurn1.Power = 20;



mTurn1.SendToNXT();



mTurn1.Power = -20;



mTurn1.SendToNXT();

pause(0.8)

if i == 1;

tachoLength(i) = 5;

else

tachoLength(i) = tachoLength(i-1) + 5;

end



distance(i) = GetUltrasonic(global_info.portUS);

CloseSensor(global_info.portUS)

plot(i,distance(i),'-*')

%

end%for

%determine closest target

global target

target = min(distance(1:i));

%remove other measurements ( above 100cm)

for j=1:i;

if distance(j) > target +5 || distance(j) < target - 5

distance (j) = 0;

elseif distance(j) == 100

distance(j) = 0;

end

end

v = 1;

targetArea = zeros(1);

tachoArea = zeros(1);

%find area of block

for u=1:i;

if distance(u) > 0;

temp = zeros(length(targetArea),1);

temp2 = temp;

temp = targetArea;

temp2 = tachoArea;


targetArea = zeros(length(temp)+1);

targetArea = temp;

tachoArea = zeros(length(temp2)+1);

tachoArea = temp2;

clear temp;

clear temp2;

targetArea(v) = distance(u);

tachoArea(v) = tachoLength(u);

v = v + 1;

end

end

% % Confirm target detection and plot destination

finalTarget= tachoArea(int8(length(tachoArea)/2));

if distance > 100





end


D.2 Main program

• NXT_Clawbot.m

global global_info;

global_info.REAL_TIME = 1; % This is a Real-Time run

global_info.STOP_AT = current_clock(3) + [0 20 0]; % stop after 2 mins

global h;

h = initNXT();

png = petrinetgraph({'NXT_test_def'});

dynamicpart.initial_markings = {'p1',1,'p2',0,'p3',0,'p4',0,...

'p5',0,'p6',0,'p7',0,'p8',0,'p9',0,'p10',0,'p11',0,'p12',0,...

'p13',0,'p14',0,'p15',0,'p16',0,'p17',0,'p18',0,'p19',0,...

'p20',0,'p21',0,'p22',0,'p23',0};

dyn.initial_priority = {'tDone',2,'tScan',1,'tCleanup3',3,

'tCleanup2',2,'tCleanup1',1,'tFalseTar',2,

'tClose',1,'tEdge',2,'tDToTarg',1}; % initial priority

dynamicpart.firing_times = {'tStart',2,'tScan1',2,'tToTarg',2,

'tDToTarg',2,'tClose',1,'tRot180',2,

'tBorder',2,'tOpen',2,'tReverse',2,...

'tRot1802',1,'tBuffer',1,'tTarget',1,

'tNoTarget',1,'tScan2',1,'tTarget2',1,

'tNoTarget2',1,'t360Scanned',1,'tForward',1,

'tForward2',1,...

'tDone',1,'tFalseTarg',1,'tEdge',1,'tToTarg2',1,'tScan3',1};

display('Push button to start clean-up procedure!');

% dynamicpart.initial_priority = {'tPEDES_START',5, 'tPEDES_CYCLE',5,...

% 'tEM_START',5, 'tEM_CYCLE',5};


%disp('System is ready ...');

sim = gpensim(png, dynamicpart);

%

% % close_TL_NXT(); % Never forget to clean up after your work!!!

%

% print_statespace(Sim_Results);

% plotp(Sim_Results, {'p1','p2','p3'});

• NXT_Clawbot_def.m

function [png] = NXT_test_def()

png.PN_name = 'PDF for nxt test';

png.set_of_Ps = {'p1','p2','p3','p4',

'p5','p6','p7','p8',

...

'p9','p10','p11','p12',

'p13','p14','p15','p16','p17',...

'p18','p19','p20','p21','p22','p23'};

png.set_of_Ts = {'tStart','tScan1','tToTarg',

'tDToTarg',...

'tClose','tRot180','tBorder',

'tOpen','tReverse',...

'tRot1802','tForward','tBuffer','tTarget','tNoTarget',...

'tScan2','tTarget2','tNoTarget2','t360Scanned','tForward2',...

'tDone','tCleanUp1','tCleanUp2','tCleanUp3','tFalseTarg',...

'tRot1803','tForward3','tEdge','tToTarg2','tScan3'};

png.set_of_As = {'p1','tStart',1,'tStart','p2',1,'p2','tScan1',1,'tScan1'...

,'p3',1,'p3','tTarget',1,

'tTarget','p4',1,'p4','tToTarg',1,'tToTarg','p5',1,

'p5','tDToTarg',1,'tDToTarg','p6',1,...

'p6','tClose',1,'tClose','p7',1,'p7','tRot180',1,'tRot180','p8',1,'p8',


'tBorder',1,...

'tBorder','p9',1,'p9','tOpen',1,'tOpen','p10',1,'p10','tReverse',1,'tReverse','p11',1,...

'p11','tRot1802',1,'tRot1802','p12',1,'p12','tForward',1,'tForward','p13',1,

'p13','tBuffer',1,...

'tBuffer','p2',1,...

'p3','tNoTarget',1,'tNoTarget','p14',1,'p14','tScan2',1,'tScan2','p15',1,

'p15','tTarget2',1,...

'tTarget2','p4',1,'p15','tNoTarget2',1,'tNoTarget2','p14',1,'tNoTarget2','p16',1,

'p16','t360Scanned',3,...

'p14','t360Scanned',1,'t360Scanned','p17',1,'p17','tForward2',1,'tForward2','p2',1,...

'tBuffer','p18',1,'p18','tDone',3,'tDone','p19',1,'p2','tDone',1,...

'p16','tCleanUp1',1,'p16','tCleanUp2',2,'p16','tCleanUp3',3,...

'p6','tFalseTarg',1,'tFalseTarg','p20',1,'p20','tRot1803',1,'tRot1803','p21',1,...

'p21','tForward3',1,'tForward3','p2',1,...

'p5','tEdge',1,'tEdge','p22',1,'p22','tScan3',1,'tScan3','p23',1,...

'p23','tToTarg2',1,'tToTarg2','p5',1};


D.3 Transitions (in alphabetical order)

• t360Scanned_pre.m

function [fire, transition] = t360Scanned_pre(transition)

display('WE ARE IN T360SCANNED_POST');



fire = (b15.tokens == 3) && b13.tokens;

• t360Scanned_post.m

function [] = t360Scanned_post(transition)

end

• tBorder_pre.m

function [fire, transition] = tBorder_pre(transition)


fire = b7.tokens;

• tBorder_post.m

function [] = tBorder_post(transition)

ACTION_FindBorder;

end

• tBu�er_pre.m

function [fire, transition] = tBuffer_pre(transition)


fire = b12.tokens;


• tBu�er_post.m

function [] = tBuffer_post(transition)

end

• tCleanUp1_pre.m

function [fire, transition] = tCleanUp1_pre(transition)


fire = b3.tokens;

• tCleanUp2_pre.m

function [fire, transition] = tCleanUp2_pre(transition)


fire = b3.tokens;

• tClose_pre.m

function [fire, transition] = tClose_pre(transition)


global global_info;


fire = 1;

else

fire = 0;

end

• tClose_post.m

function [] = tClose_post(transition)

pause(5);

disp('Target aquired!! These ARE the droids we are looking for');

ACTION_CloseClaw;

end


• tDToTarget_pre.m

function [fire, transition] = tDToTarg_pre(transition)

global global_info;


if global_info.edgeDetected == 0 && b4.tokens == 1;

fire = 1;

end

• tDToTarget_post.m

function [] = tDToTarg_post(transition)

ACTION_DriveToTarget;

end

• tEdge_pre.m

function [fire, transition] = tEdge_pre(transition)

global global_info;


if b5.tokens && global_info.edgeDetected == 1

fire = 1;

else

fire = 0;

end

• tEdge_post.m

function [] = tEdge_post(transition)

end


• tFalseTarg_pre.m

function [fire, transition] = tFalseTarg_pre(transition)

global global_info;



fire = 1;

else

fire = 0;

end

• tFalseTarg_post.m

function [] = tFalseTarg_post(transition)

disp('false target aquired! Reinitiate search routine');

end

• tForward_pre.m

function [fire, transition] = tForward_pre(transition)

global global_info;


fire = b11.tokens;

• tForward_post.m


ACTION_Forward;

end


• tForward2_pre.m

function [fire, transition] = tForward_pre(transition)

global global_info;


fire = b16.tokens;

• tForward2_post.m


ACTION_Forward;

end

• tForward3_pre.m

function [fire, transition] = tForward3_pre(transition)

global global_info;



fire = b20.tokens;

• tForward3_post.m

function [] = tFoward3_post(transition)

ACTION_Forward;

end

• tNoTarget_pre.m

function [fire, transition] = tNoTarget_pre(transition)


global global_info;




fire = 1;

else

fire = 0;

end

• tNoTarget_post.m

function [] = tNoTarget_post(transition)

NXT_PlaySoundFile('r2d2wst2', 0);

end

• tNoTarget2_pre.m

function [fire, transition] = tNoTarget2_pre(transition)

global global_info;




fire = 1;

else

fire = 0;

end


• tNoTarget2_post.m

function [] = tNoTarget2_post(transition)

NXT_PlaySoundFile('r2d2wst2', 0);

end

• tOpen_pre.m

function [fire, transition] = tOpen_pre(transition)


fire = b8.tokens;

• tOpen_post.m

function [] = tOpen_post(transition)

ACTION_OpenClaw;

end

• tReverse_pre.m

function [fire, transition] = tReverse_pre(transition)


fire = b9.tokens;

• tReverse_post.m

function [] = tReverse_post(transition)

ACTION_Reverse;

end


• tRot180_pre.m

function [fire, transition] = tRot180_pre(transition)


fire = b6.tokens;

• tRot180_post.m


ACTION_Rotate180;

end

7

• tRot1802_pre.m



fire = b10.tokens;

• tRot1802_post.m


ACTION_Rotate180;

end

• tRot1803_pre.m


global global_info;



fire = b19.tokens


• tRot1803_post.m


ACTION_rotate180;

end

• tScan1_pre.m

function [fire, transition] = tScan1_pre(transition)


fire = b1.tokens;

• tScan1_post.m


global global_info;

ACTION_scanDistance;

b2 = 1;

end

• tScan2_pre.m




fire = b13.tokens & b15.tokens < 3;

• tScan2_post.m


ACTION_ScanDistance2;

end


• tScan3_pre.m



fire = b21.tokens;

• tScan3_post.m


ACTION_ScanDistance;

end

• tStart_pre.m

function [fire, transition] = tStart_pre(transition)

global global_info;

OpenSwitch(global_info.portB);

button = GetSwitch(global_info.portB);

CloseSensor(global_info.portB);

if button == 1

fire = 1;

else

fire = 0;

end

• tStart_post.m

function [] = tStart_post(transition)

NXT_PlaySoundFile('R2D2', 0);

end


• tTarget_pre.m

function [fire, transition] = tTarget_pre(transition)

global global_info;



if ((b2.tokens & global_info.targetAcquired) == 1)

fire = 1;

else

fire = 0;

end

• tTarget_post.m

function [] = tTarget_post(transition)

end

• tTarget2_pre.m

function [fire, transition] = tTarget2_pre(transition)

global global_info;



display(global_info.targetAcquired);

if ((b14.tokens & global_info.targetAcquired) == 1)

fire = 1;

else

fire = 0;

end


• tTarget2_post.m

function [] = tTarget2_post(transition)

end

• tToTarg_pre.m

function [fire, transition] = tToTarg_pre(transition)


fire = b3.tokens;

• tToTarg_post.m

function [] = tToTarg_post(transition)


end

• tToTarg2_pre.m

function [fire, transition] = tToTarg2_pre(transition)


fire = b22.tokens;

• tToTarg2_post.m

function [] = tToTarg2_post(transition)


end

a petri net based lego for searching

Documents