a petri net based approach for creating line-following, route-measuring and object-avoiding...

UNIVERSITY OF STAVANGER

Department of Electrical and Computer Engineering

A Petri Net Based Approach for CreatingLine-Following, Route-Measuring and Object-Avoiding

Functionalities in a LEGO Robot

Project in MID280 Discrete Simulation

By Peter Bergesen Kolstø and Shahed Farid

May 14, 2012

Abstract

A line-following, route-measuring and object-avoiding robot was developed using Petrinet theory. Our main goal is to create a Petri net model of these functionalities, andthen use it to program the robot. We will also highlight difficulties when implementinga theoretical model in hardware. Petri net theory is not normally used for this purpose.Hence we keep the model simple, just to see whether Petri net theory and GPenSIM aresuitable for this purpose. From the start we expected some problems during this project;they are explained in this report.

We would like to direct a special thanks to Reggie Davidrajuh for his supervision and in-spiration during this project, Ståle Freyer for borrowing us the necessary equipment andEinar Holven for printing the tracks. We would also like to thank our fellow students,Jonathan Brian Tamson Alcoriza and Vegard Kleppe Torkelsen, for inspiring discus-sions.

Contents1 Introduction 2

1.1 Line-Following Functionality . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Route-Measuring Functionality . . . . . . . . . . . . . . . . . . . . . . . 41.3 Object-Avoiding Functionality . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Model 72.1 Model Overview of Intended Design . . . . . . . . . . . . . . . . . . . . . 72.2 Line-Following Functionality . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Route-Measuring Functionality . . . . . . . . . . . . . . . . . . . . . . . 82.4 Object-Avoiding Functionality . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Petri Net of the Intended Route-Measuring and Object-Avoiding Function-

alities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Final Petri Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Implementation 163.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Connection Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.3 Hardware Limitations . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.1 MATLAB and GPenSIM . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Main Simulation File (MSF) . . . . . . . . . . . . . . . . . . . . . 213.2.3 Petri net Definition File (PDF) . . . . . . . . . . . . . . . . . . . 223.2.4 Transition Definition File (TDF) . . . . . . . . . . . . . . . . . . 223.2.5 Bluetooth Configuration File . . . . . . . . . . . . . . . . . . . . . 253.2.6 Software Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Analysis 264.1 Petri Net Used for Non-Cyclic Functionalities . . . . . . . . . . . . . . . 264.2 Co-tree Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Siphon Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4 Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Discussion 285.1 General Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2 Using Petri Net in Connection with Hardware . . . . . . . . . . . . . . . 285.3 Comment on Analysis of the Petri Net . . . . . . . . . . . . . . . . . . . 295.4 Suggestions for Further Studies . . . . . . . . . . . . . . . . . . . . . . . 29

A Complete Code 31A.1 Main Simulation File (MSF) . . . . . . . . . . . . . . . . . . . . . . . . . 31A.2 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32A.3 Petri Net Definition File (PDF) . . . . . . . . . . . . . . . . . . . . . . . 34A.4 Transition Definition Files (TDFs) . . . . . . . . . . . . . . . . . . . . . . 36A.5 Reading of Sensor Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3

A.6 Sounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

B Installation Guide 53

C User Manual 53

D Building Instructions 53

E Track 96

1

1 Introduction

We intended to program the LEGO robot so that it followed a black line on the floor.Should the robot encounter an object hindering its path, the robot will detect it, andsearch for the shortest distance around the object. The robot will then drive around theobject, until it again detects the black line, where it retrieves it‘s previous line-followingfunctionality.

The different functionalities of the robot were intended to be contained, as much aspossible, in different modules. Doing so, we would be able to have the program terminateits previous functionality before moving on to a new. It also makes for easy reuse, and acomprehensible code.

In addition to modules containing the different functionalities we have also made mirror-functionalities where we have two identical, but mirrored functionalities. To have therobot move back on line from either left or right, or to drive around the object hinderingits path on either side, produces mirrored functionalities.

From the very start of the idea to program the robot, we have taken into account thedelay through the system. The system delay causes the robot to not act instantaneouslyto external inputs. This might seem as a disadvantage at first, but through careful designit can be somewhat advantageous.

Figure 1: Simplified state diagram

Figure 1 shows the basic flow chart of the robot‘s functionalities as it encounters an objectalong its path, moves around it and returns to its path.

2

1.1 Line-Following Functionality

The basic idea behind the line-following functionality, is to have two light sensors detecta predetermined line along the floor made in a different color than the floor itself. As asensors move off the path it will register a change in it‘s received light brightness value.These signals are then used to govern the motion of the robot.

The line-following functionality is intended to have the motor on the same side as thesensor moving off the path, increase it‘s speed to make the robot perform a turn to moveback on its path. If this should not be sufficient, and the second sensor moves off the pathas well, the same motor will further increase it‘s speed for an even sharper turn.

As the robot (hopefully) moves back on its path, it will start moving forward againimmediately, in the case where only one sensor has been beyond the path, as soon as thelight sensor that has been registering a different value now registers its initial value. Ifboth sensors has been beyond the path, the robot will attempt to wheel back on courseas the first sensor moves back on to the path, before it starts moving forward as the lastsensor comes back on.

Other similar work can be found at [10, 9].

Figure 2: Line Following Method

Figure 2 shows how the robot is intended to follow a given line by sending signals fromthe light sensors to the motors to increase or decrease power, as the sensors move onand off the line. Red dots are light sensors, so that the line has to be black on a whitebackground. Arrows indicates relative motor power of the given motor.

3

1.2 Route-Measuring Functionality

Initially, we wanted the robot to be able to measure the shortest route around an objecthindering it‘s path. To achieve this we have used a turret mounted distance sensor capableof rotating.

As the robot encounters an object, it will terminate its line-following functionality, andcome to a halt. Then the turret moves first to the left, and as the distance sensor nolonger detects any object, it moves right until it again no longer detects the object. (Notethat it is possible to ignore the event that the distance sensor starts detecting the objectagain). The offset angles (Φ−LEFT and Φ−RIGHT ) from the turret‘s starting positionto the position of the distance sensor when it registered the edges of the object, are storedin an external computer. These values are compared in order to decide which way therobot should move around the object.

d <

21

cm

1 2 3

Ф-LEFT

Ф-RIGHT

Figure 3: Route Measurement Method

Figure 3 shows how the robot is intended to detect an object hindering its path, andmeasure the angle from the distance sensor‘s starting position to the edge of the objectto both left and right, and then compare these values to determine the shortest distancearound an object.

The dark blue arrow indicates in which direction the turret moves. The circles inside theblue rectangle are the light sensors. Red means that they are active, and black meansthat they are inactive. While this sequence executes the light sensors are inactive.

We have not managed to find other similar work we can cite to.

4

1.3 Object-Avoiding Functionality

When the shortest distance around the object has been calculated, the turret is intendedto position itself where it registered the edge with the largest offset value. The robot willthen turn in the opposite direction of the turret to steer away from the object, until thesensor again registers the object. (Note that the robot will not stop immediately as thesensor registers the edge of the object because of delay through the system, but at aroundthe center of the object). The robot will then move forward until the distance sensor nolonger detects the object. The robot will then turn in opposite direction of its first turn,until the sensor again registers the object, which will initialize the robot to start movingforward again. This will then continue in order to move the robot in a semicircular motionuntil both light sensors registers the black line. This will terminate the object-avoidancefunctionality, and initialize the robot‘s previous line-following functionality.

The figure on the next page shows how the robot is supposed to use the distance sensorto guide it around the object, in order return to its previous path. The light blue arrowindicates in which direction the robot moves. The dark blue arrow indicates in whichdirection the turret moves.

Other similar work can be found at [8]

5

1 2 3

4 5 6

7 8 9

10 12

This loop (steps 4-6)executes until the robotreturns to the pre-determined line, whereit retrieves it`s previousline-followingfunctionality

11

2 Model

2.1 Model Overview of Intended Design

To help illustrate how we wanted to achieve the functionalities, we first drew state di-agrams. To achieve a Petri net from a state diagram we added transitions to the statediagram, and changed the names to fit the Petri net conventions.

In the conversion from state diagram to Petri net, the dynamics of the program weremoved from the places and arcs in the state diagram to the transitions in the Petri net.To have the marker move around the Petri net serves to make the program rememberwhere in the state diagram robot currently is, and the arcs show which new states areaccessible from the current state. The transitions in the Petri net also serves to simulatean if-structure, by only allowing the marker to pass only if certain criteria‘s for firing thetransitions are met.

2.2 Line-Following Functionality

The program is designed to always start in the same state every time it starts up. Thestarting place is contained within the line-following module. The starting position of themarker implies no actions to the robot, it only serves to have the program started, butwaiting. In the first design we intended for the user to push a button on the robot tohave the marker move from its starting position to where the program initializes actualmovements in the robot. This was changed to have the program start moving the robotwithout any external input. Instead the program now terminates, and returns to itsstarting position, when the button is pushed. We have placed the button on the robot‘svan so that it will be pushed if the robot moves into an object. This is done as a extrameasure of security, should the robot fail to detect an object along its path, and moveinto it.

We designed the Petri net module for the line-following functionality so that the markercould return to its starting position, pLF_START, from either pLF_LEFT_SOFT, pLF_FORWARDand pLF_RIGHT_SOFT. These places are used in the case when the robot has one sensoroutside the path. If the button should be pushed while the robot is in any state whereboth light sensors are outside the path, the program will not terminate until it returnsto one of the places mentioned above.

We could have connected all the places in the line-following module to transitions capableof draining the places should the button be pushed. We have chosen not to becauseit would give a code hard to comprehended, and a confusing Petri net. In addition,we designed the Petri net governing the robots line-following functionality so that theprogram had to move to a state where only one sensor is outside the path before movingto a state where both sensors are outside. This is done so that the case where only onesensor is outside the path is included both when the robot is on a path heading a littleoutside and a lot outside its predetermined line. Had we chosen to split the hard-turn

7

and soft-turn sub-functionalities of the robot into two completely different modules, thiswould not be the case.

The line-following module contains a left- and a right turn part, which are mirrors of eachother connected through the common places pLF_START, tLF_START and pLF_FORWARD.We considered drawing these in two separate modules, but chose not to because it wouldcreate to many small modules to give a unified picture of the code.

In both the left and right line-following functionalities there are two routes for the markerto follow. At the place pLF_LEFT_SOFT in the left functionality, and pLF_RIGHT_SOFT inthe right functionality the marker may move on to either pLF_FORWARD, if the robotreturns back on path, or to tLF_LEFT_HARD or tLF_RIGHT_HARD, if the second sensor alsomoves beyond the line. This makes for two separate routes within the left- and rightsub-functionality in the line-following module. These could also have been contained inseparate modules, but for reasons mentioned above we have chosen not to.

2.3 Route-Measuring Functionality

As the ultrasonic distance sensor detects an object, transitions connected to pLF_LEFT_SOFT,pLF_FORWARD and pLF_RIGHT_SOFT are enabled. These transitions was intended to firethe marker out of the line-following module, and into the route-measuring module shouldthe robot encounter an object.

The route-measuring module was first intended to make the turret sweep back and forthbetween the edges of the object in one fluid movement, but the ultrasonic distance sensorhad problems registering the precise moment when it passed the edge, so we redesignedthe program. The new design of the route-measuring functionality introduced a loop-structure in our Petri net. We made the marker move in a loop in the module, allowingthe turret to move only a few degrees for each loop as long as the object is detected.When the ultrasonic distance sensor no longer registers the object, the marker will moveout of the loop.

As with the line-following functionality, the route-measuring functionality contains mir-rored sub-functionalities. The turret first move to one side, as the marker moves into aloop governing the turrets motion towards that side. Then as the edge of the object isreached, transitions connected to the places in the loop are enabled, and the marker isfired into a mirrored Petri net governing the turrets motion towards the other side.

Even after we altered the original design, and introduced a loop structure to reduce theeffect of inaccuracy in the hardware, we could not make the robot behave as we intended.Though it sometimes worked as intended, the route-measuring module caused too manyproblems, and was abandoned in the final implementation.

8

2.4 Object-Avoiding Functionality

The object-avoidance functionality was first intended to be achieved by using a loop-structure governed by inputs from the distance sensor. As the marker has been fired intoeither the left- or right sub-functionality of the object-avoidance module, the transitionthe marker passes through will signal that the turret should be moved to a positionopposite of the way the robot intends to pass the object, and that the robot shouldturn in the opposite direction of the turret. From this position the marker was intendedto move in a loop as the sensor detects and ceases to detect the object, as the robotalternates moving forward and turning towards the object. This will continue until therobot had moved around the object, and returned to its path. The light sensors wouldthen give signal to enable transitions draining the object-avoidance module, and movethe marker back to the line-following module.

For much the same reasons as with the loop-structure in the route-measuring module,we abandoned the initial design of the object-avoidance module. Having first abandonedthe route-measuring functionality, the option of having the robot move either left orright were rendered irrelevant. Then to be able to overcome the difficulties working withhardware we had to further simplify the functionalities. In the end we were left witha functionality that would make the robot detect, and move around an object in onlyone predetermined direction, and with the turret and robot turning in 90 degrees anglesonly.

Figure 4 shows how the simplified object-avoidance functionality works.

d <

21

cm

1 2 3 4

5 6 7 8

Figure 4: Object-Avoidance Method

9

While the robot is following the black line, the distance sensor is measuring the distancein front of it. If it detects an object in front of it, the following sequence is executed:

• The robot stops

• The robot turns 90 degrees to the right

• The turret turns 90 degrees to the left

• The robot drives forward until the distance sensor no longer detects the object,then stops

• The robot turns 90 degrees to the left

• The robot drives forward until the distance sensor no longer detects the object,then stops

• The robot turns 90 degrees to the left

• The turret turns 90 degrees to the right

• The robot drives forward until both light sensors registers black color, then stops

• The robot turns 90 degrees to the right

• The robot retrieves it‘s line-following functionality

10

2.5 Petri Net of the Intended Route-Measuring and Object-AvoidingFunctionalities

The original design of the Petri net governing the robots route-measuring and line-following functionalities where abandoned because of the difficulties of implementing itinto the actual hardware. Nevertheless we include the original Petri net of these function-alities, to illustrate how the functionalities could have been achieved given more accuratehardware.

The route-measuring module is enabled as the distance sensor detects an object. Themarker is then moved from the line-following module and into the route-measuring mod-ule, as explained in section 2.6. The route-measuring module contains two loops wherethe turret seeks the edge of the object hindering its path. The loops allow for the turretto move only a few degrees for each cycle. This is intended to give the system time tocheck whether or not the edge of the object has been reached before moving further on.As the edge has been reached the transition contained in the loop is no longer enabled,and the transition moving the marker out of the loop is enabled. This renders the use ofsemaphores to open and close transitions unnecessary.

To make for less problems as the external computer communicates with the robot, weincluded more transitions than strictly necessary according to Petri net theory. This wasdone to ensure that each transition only has one function. For example, we could havehad one transition give the program the command to both stop and reset the turret toits starting position, but this caused problems.

As the turret reaches the edges of the object, the values of the offset angles betweenthe turrets starting position and where the the distance sensor registered the edges arestored in an external computer. When this cycle has been completed for each direction,the values are compared in order to decide which way the robot should pass around theobject.

The robots sub-functionalities of moving around the object on either the left or right sideare mirrored. Hence only one explanation is required to understand them both. Theonly exception to this is that, should the left route be the shortest the turret moves backto the position where it found the edge on the right side. This is in contrast to thescenario where the right route is found to be the shortest, where the turret then stays inplace.

After the turret has been placed in it‘s proper position, the robot first turn in the oppositedirection of the turret. From this position of the robots and the turrets facing the robotis ready to move around the object in a semi-circular motion. The semi-circular motion isgoverned by a loop that moves the robot forward, as the distance sensor detects the object,and turns the robot, as it do not detect the object. This continues until both light sensorsdetects the black line on the other side of the object. As the line is detected transitionsconnected to the places in the loop mentioned above are enabled, and a semaphore issent to the other transitions in the loop. This drains the object-avoidance of the marker,and moves it back into the line-following module, enabling that functionality.

11

Table 1 explains the notations used in the description of the firing conditions for thetransitions in the Petri nets.

Name Sensor Type Value MeaningSW Switch Sensor True/False Pressed/Not pressedLSR Light Sensor Right B/W Black/WhiteLSL Light Sensor Left B/W Black/WhiteLSRL Light Sensors Right and Left B/W Black/WhiteUS Ultrasonic Distance Sensor OD/NOD Object Detected/No Object Detected

Table 1: Notations used in the Petri nets

The Petri net is shown in the page below. We have drawn all of our Petri nets in aprogram called Petri LLD [5].

12

Original route-measuring module

Original obstacle-avoiding module

2.6 Final Petri Net

The Petri net governing the robots functionalities will at any time contain only onemarker. The place currently containing the marker indicates the robots state. All firingtime is set to the same value. The final Petri net contains only two modules with anadditional layer of transitions between them. Our final Petri net is based on basic the-ory only, with the exception of the extensive pre- and post files in connection with thetransitions.

The line-following module contains to mirrored sub-functionalities, as the robot may moveback on the predetermined line from either the left or right side of the path. In additionit contains the starting position of the initial marker. Each of the sub-functionalitiesconsists of two alternative routes for the marker to follow. One route for soft turns,should only one sensor have been beyond the path, and one route should a sharper turnbe required, as both sensors have been moving outside.

In this final Petri net we have connected the line-following module to the object-avoidancemodule through a layer of transitions able to drain the line-following of the marker, shouldthe distance sensor detect an object. The marker will in this case be moved into theobject-avoidance module.

The final, simplified object-avoidance module contains no loops, or alternate routes forthe marker to follow. The marker simply move from place to place as the transitions areenabled by external inputs. As the object avoidance functionality has been completed,the marker moves back to the place, pLF_FORWARD, in the line-following module to againinitialize this functionality.

The next page contains the final Petri net, which we were able to implement.

14

Line follower

Transition between line followingand object avoidance

Object avoidance

3 Implementation

The implementation is done using a LEGO NXT system in interaction with MATLABand GPenSIM.

3.1 Hardware

3.1.1 Equipment

The LEGO NXT system offers a range of hardware that can be built into flexible LEGOrobots [4]. The system is operated by connecting sensors and actuators to a microcon-troller built into the actual robot. The microcontroller may run on a small programstored locally, or as in our case, run remotely by an external computer.

NXT Microcontroller

This is the brain of the robot system. The microcontroller has three input ports, threeoutput ports, one USB 2.0 port and supports Bluetooth. A wide range of sensors andactuators can be connected to the microcontroller. We have chosen only to present theones used in the design of our robot.

NXT Ultrasonic Distance Sensor

The ultrasonic distance sensor can measure the distance to an object. It does so bysending out and receiving sound waves that bounces back from the object. It calculatesthe distance by measuring the time between these two events [7]. This sensor gives outreadings in cm.

NXT Light Sensor

The light sensor measures light brightness levels. It can operate in two modes, one whereit uses an built-in red LED-light to illuminate an object and detects reflected light fromit. In the other mode it can detect ambient light. In our design we have used these sensorsin the first mode (also called active mode). This sensor gives out readings in range from0-1023.

NXT Switch Sensor

The switch sensor returns a logic ’1’ if pressed and a logic ’0’ if not pressed.

NXT Servo Motor

These servo motors have built-in gears and have encoders that can send their position (ro-tation in degrees) back to the microcontroller. The servo motor can either be programmedto run continuously, or to move a number of degrees given by the program.

16

Images of the NXT hardware is shown below [4].

Figure 5: NXT microcontroller

Figure 6: NXT ultrasonic distance sensor

17

Figure 7: NXT light sensor

Figure 8: NXT servo motor

Figure 9: NXT switch sensor

18

3.1.2 Connection Diagram

Figure 10 contains the hardware connection diagram for the robot. It shows how thesensors and actuators are connected to the NXT microcontroller. The arrows also showsthe signal paths.

Figure 10: Connection diagram

The two light sensors are connected to the sensors ports 1 and 2. The ultrasonic distancesensor is connected to sensor port 3, and the switch sensor is connected to sensor port 4.The left motor is connected to motor port A, the motor on the right hand side is connectedto motor port B, and the turret motor (on top of the robot, where the distance sensorstands) is connected to motor port C. Note that the arrows between the microcontrollerand the motors are bidirectional, that is because the motors can be given commands toturn, as well as send their position back to the microcontroller.

19

3.1.3 Hardware Limitations

Transmission Delay

The commands are sent line by line from the computer to the NXT microcontroller overa Bluetooth connection. In our application it is required that sensor values are read andsent to the computer, and then processed before the commands are sent to the actuators.This connection is very slow, so the sequences takes some time. The delay cause problemslike that sensor values can be sent to the computer at the wrong times.

Some of the delay time could have been reduced, if we instead of using Bluetooth hadused a USB connection, but it would have been very unpractical to have a USB cablefrom the computer to the robot as it drives around. The best solution with regard totransmission delay would have been to have the ability to run the software locally on theNXT microcontroller, or to use a better wireless connection.

Ultrasonic Distance Sensor

The distance sensor gave inaccurate readings when measuring in an angle. When mea-suring in an angle, and e.g. the wave hits the edge of the object, the wave gets diffracted,and it can happen that the sensor receives multiple copies at different times, thus givinginaccurate readings. We tested with rounder objects, as well as squared ones, and foundthat the sensor gave better readings with rounder objects, but still, it was too inaccuratefor what we were planning to do with those sensor readings.

Transmission Delay Effecting Ultrasonic Distance Sensor Readings

The relative long transmission delay can cause the turret to overshoot the edges of theobject. Hence we could not make the robot drive accurately around the object in asemicircular motion, as we intended.

Ultrasonic Distance Sensor

The light sensor gives a reading that is a measurement of light reflected by the objectit faces (in our case the black and white track). It takes readings over a small area(scans the area) and returns the average value of the scan. By testing we observed thatif even if the robot stood still, the light sensor values had slight differences. This causesinaccuracy.

Transmission Delay Effecting Light Sensor Readings

Because of the delays in the transmissions mentioned above, it takes a considerablyamount of time to transmit the light values to MATLAB, this makes for an inaccuratebehavior in the robot. E.g. if the robot is driving very fast around a corner, MATLABcan get light values out of time, and thus the program will not be able to give the correctmotor commands, and are sometimes unable to turn the robot accurately around a corner.To reduce the problem we decreased the speed of the robot, to give the system more timeto react precisely.

20

3.2 Software

3.2.1 MATLAB and GPenSIM

This section describes the implementation of the Petri net in MATLAB and GPenSIM.The different elements (MSF, PDF and pre- and post-files) are explained. Complete codecan be found in Appendix A.

3.2.2 Main Simulation File (MSF)

In GPenSIM, global_info is used to pass values between different files [2]. The programis set to run for 10 minutes, as the real-time run is enabled. Next, the program governingthe robot is initialized. To keep the code clean, all the code needed for the initialization ofthe robot is put in a separate m-file (init_NXT.m). This file is chronologically explainedbelow.

1. The communication channel with the robot is created. Either Bluetooth or USBcan be used. We have used Bluetooth for this purpose. A Bluetooth configurationfile that we created seperatly is called in the code (bluetooth.ini). More aboutthis configuration file is described in section 3.2.5

2. The sensors are declared by defining which ports they are connected to on the NXTmicrocontroller.

3. The threshold value for the light sensors are set; this value determines whetherthe sensors registers white or black. The threshold value was chosen by takingthe average of the value given when registering black and when registering white.Also the distance from which the robot will stop and start the object-avoidingfunctionality are set. These values were chosen by experimenting.

4. To operate the motors, motor objects are created. These are instances of the classNXTMotor, which is included in the NXT Toolbox, enabling motor control. Withthese objects, commands can be sent to the motors from MATLAB, and values canalso be read from the motors in to MATLAB [6].

Motor objects for all the required motor actions are created (line following motor ac-tions and object avoidance motor actions). These are created by telling them whichmotor to drive, and with which speed. For the object avoidance motor objects, thedistance the motors should turn, in degrees, is given in addition (tacholimit).

Different power constants are made for the different motor actions in the differentstages in the program.

5. A startup tone is played, indicating that the initialization is completed.

Next, the Petri net definition file is loaded. More information about this file is given insection 3.2.3.

The initial markings are set. As shown in section 2.6 there is only one initial markingplaced at the place pLF_START.

21

The simulation (or in this case, a real time run) is started.

3.2.3 Petri net Definition File (PDF)

The PDF is created in accordance with the Petri net in section 2.6. All the places,transitions and arcs are defined.

3.2.4 Transition Definition File (TDF)

Pre- and post-files for sensor and actuator handling

Figure 11 shows how the sensor readings and motor commands are interacting with thePetri net model in GPenSIM.

Figure 11: TDF handling

In GPenSIM, before a transition is fired, the pre-file (if any) for the transition is checked.If the transition is enabled, it fires and then executes any commands in a post-file (ifany) [2]. In our implementation, the sensors are read in the pre-files, and the transitionfires if the right conditions are met. After the transition has fired, the post-files executes,thus sending commands to the motors. One example is in the transition between theline-following module and the object-avoidance module: The pre-file has a check thattests if the distance from the robot to the object is less than 21 cm. If this check returntrue, the transition is enabled, and it fires. After that, the post-file is executed, whichbegins the steps to move the robot around the object.

We could have either a common pre- and a common post file, or have separate pre- andpost files for every transition. The first choice gives a very clean code, but tests showedthat it took too long to go through the entire common files, so we chose to have separatepre- and post files. We will not describe every separate pre- and post file in detail here,because there are too many of them, and many of them are more or less the same. Theycan be categorized into two groups:

1. The transitions that are always enabled. They will fire if there is a token in theplace connected to it. It does not wait for any particular external input.

2. The transitions that checks for some particular external input. If this check returntrue, and there is also a token in the place connected to it, it fires.

22

The following examples shows how transition-files are implemented. These examplesconcerns the transitions tLF_TO_OA_FORWARD and tOA_STOP_DRIVE. The first transitionis fired if there is a token in the place pLF_FORWARD, and the distance to an object isequal to or less than 21 cm. The other transition fires if there is a token in the placepOA_START. These two describes the case when the robot is following the black line, andthe distance sensor detects an object and stops.

Pre-file for tLF_TO_OA_FORWARD:

function [fire, transition] = tLF_TO_OA_FORWARD_pre(transition)

global global_info;

openUltrasonic;

if(DISTANCE < OBJECT_DISTANCE)fire = 1;

elsefire = 0;

end

end

openUltrasonic activates the distance sensor, reads the value from it and saves it inthe variable DISTANCE. The read distance is checked with an if-statement against thethreshold value, which is stored in the variable OBJECT_DISTANCE (21 cm). If this testreturns true, the transition fires.

Post-file for tLF_TO_OA_FORWARD:

function [] = tLF_TO_OA_FORWARD_post(transition)

beepOA;

end

After the transition has fired, a sound is played to indicate that an object is detected.

23

Pre-file for tOA_STOP_DRIVE:

function [fire, transition] = tOA_STOP_DRIVE_pre(transition)

fire = 1;

end

This transition fires if there is a token at the place connected to it. It does not wait fora sensor input.

Post-file for tOA_STOP_DRIVE:

function [] = tOA_STOP_DRIVE_post(transition)

global global_info;

global_info.LF_DRIVE_FORWARD.Stop(’off’);NXT_PlayTone(880, 100);

end

The motors stops and a sound is played.

24

The complete code for the TDF-files are given in Appendix A.4.

3.2.5 Bluetooth Configuration File

MATLAB must have a Bluetooth configuration file to be able to connect to the robot.It must know which port it shall use to communicate. This port name is different fromcomputer to computer. In our test computer, a MacBook Pro, the port was called/dev/tty.NXT-DevB .

[Bluetooth]

SerialPort=/dev/tty.NXT-DevB

SendSendPause=10SendReceivePause=30

Timeout=2

The file must be saved with the file type .ini. We called our file bluetooth.ini.

3.2.6 Software Limitations

The best solution would have been to be able to download, and run the software locallyon the NXT microcontroller in a format the microcontroller is optimized for. After sometests it became clear that GPenSIM is not optimal for our application.

25

4 Analysis

4.1 Petri Net Used for Non-Cyclic Functionalities

Most commonly Petri nets are used to simulate discrete processes that run continuouslywithout explicit need of external influence, and then look for deadlocks and opportunitiesto enhance the process. In the case of programming a robot with a degree of autonomyusing Petri net, we can consider it a use of Petri net for non-cyclic functionalities. Meaningthat most transitions in the Petri net are not enabled unless by some external input,leaving the marker in place until that time. This makes for an unusual analysis.

4.2 Co-tree Analysis

The final Petri net contains over 50 transitions, and the original intended idea containedeven more. This caused GPenSIM to fail to create a comprehensible co-tree. Nevertheless,should GPenSIM have managed to create a comprehensible co-tree we would still haveto take into account that the transitions are only enabled by external input, and thusthe co-tree would in any case give an incomplete picture of the analysis. Regardless ofthe GPenSIM‘s failure to draw a comprehensible co-tree, the program was able to returninformation regarding the Petri net‘s liveness and class. GPenSIM showed that our Petrinet is live, as no terminal states where found, and that its class is binary state machine.Meaning that all arcs have weight one, and that all transitions have only one input andoutput.

4.3 Siphon Analysis

The siphon analysis is conducted using GPenSIM to look for the possibility that anytransition in a given area of the Petri net will not be able to fire, and thus cause adeadlock situation, given that the program runs for a considerable time. Siphon did findan area in the final Petri net that might end up in a deadlock situation. We have notfound the reason for this. The area is:

[ pLF_FORWARD - pLF_LEFT_HARD - pLF_LEFT_SOFT - pLF_LEFT_SOFT_2 -- pLF_RIGHT_HARD - pLF_RIGHT_SOFT - pLF_RIGHT_SOFT_2 -- pLF_START - pOA_FORWARD - pOA_FORWARD_2 - pOA_FORWARD_3- pOA_START - pOA_STOP_DRIVE - pOA_STOP_DRIVE_2 - pOA_STOP_DRIVE_3 -- pOA_STOP_DRIVE_4 - pOA_TURN_LEFT_90 - pOA_TURN_LEFT_90_2 -- pOA_TURN_RIGHT_90 - pOA_TURN_RIGHT_90_2 -pOA_TURRET_LEFT_90 -- pOA_TURRET_RIGHT_90 ]

26

4.4 Experimentation

To test the robot we first used a track shown in figure 12. It turned out that the cornerswere too sharp, causing the robot drive off the track. We then made a second simplifiedtrack, shown in figure 13.

Original track:

Figure 12: Original track

New, simplified track:

Figure 13: New simplified track

First, we gave the motors too much power so the robot did not manage to get around thenew track. We then reduced the motor speed so that the robot managed to get aroundthe whole track without falling off.

We then tested the object-avoiding functionality by placing different shaped object onthe track. After some testing we found that boxed-shaped object gave the best results.At the end of the track we placed a solid box where the button on the front would bepressed causing the robot to stop. This worked as expected. The solid box must be solow that the distance sensor is unable to detect it, but high enough so that the switchsensor can be pressed.

27

5 Discussion

5.1 General Discussion

The original idea, was that we could more or less program the robot directly from thestate diagram, and that this would be easy and give ample opportunity for analysis. Itturned out to be more of a challenge than we thought, so that we had to simplify theintended functionalities of the robot considerably. This took most of out time, and wewere left with little opportunity to explore the possibilities given in more advanced Petrinet theory. We also faced the fact that basic Petri net theory and GPenSIM were notinvented for our purpose, and that it resulted in a code that was long and difficult toalter.

5.2 Using Petri Net in Connection with Hardware

We used very simple Petri net theory to overcome all the difficulties in connection toworking with hardware. In the end we had to conclude that there would have beeneasier, more conventional methods to give the robot its functionalities. Nevertheless,working with Petri nets in connection with hardware have a potential that might befurther explored. It is easy to illustrate when a program makes a loop when drawing itin the Petri net. The Petri net also offers a comprehensible way to give a view of whatwill happen in the program as the marker moves around.

We had expected that the delay time through the system would be a major problem whenworking with relatively cheap and inaccurate hardware. It turned out that, even if it waschallenging, the delay time could be taken account for in the design, and to some degreebe used to our advantage. For instance as the robot moves around an object hindering itspath, it is better to have the robot turn some time after its distance sensor has registereda new value than right away, to make for fewer turns and a more fluid movement. Wecould have done this by adjusting the firing time of the transitions, but as it turned outthe delay through the system was sufficient to achieve this.

Using Petri net to achieve functionalities has a further advantage as it resembles a statediagram. As with a state diagram the Petri net allows access to only some new statesfrom a current state. This allows us to ignore events that happen to the robot whenprogramming, simply by not having a transition enabled by that event. An example ofthis is when the turret moves back and forth between the edges of an object hindering therobot‘s path. The event that the ultrasonic sensor starts registering the object after it hasmoved off the edge after the first turn, and starts seeking the other edge, can be ignoredbecause from the place containing the marker as this event occurs is not connected to atransition enabled by a reading of the ultrasonic distance sensor initial value.

28

5.3 Comment on Analysis of the Petri Net

In the end, GPenSIM was not able to give use the clear analysis of our Petri net thatwe had hoped for. Neither the co-tree nor the siphon analysis contained information wecould use to further improve our design of the robots functionalities.

It would have been possible to perform a more throughout manual analysis of the Petrinet, with more weight on commenting the effect of the programs dynamics given in thetransitions pre- and post files. This would have taken us too long time, and we havechosen not to go into further details on the analysis of the robots functionalities.

We presume that the reason for GPenSIM‘s failure to be able to perform a proper analysiswas because the large number of transitions in our Petri net. This might have beenovercome by performing separate analyses for each of the modules. Nevertheless we havechosen not to do this because of our time limitation.

5.4 Suggestions for Further Studies

If anyone should follow in our footsteps, and want to use Petri net theory to programrobots with a degree of autonomy, we would suggest using more modules to make reuseof functionalities easier, and for a clean picture of the program.

The idea that colored Petri net may render the use of mirrored sub-functionalities un-necessary have occurred to us, but we have not explored more advanced Petri net theoryin this project, fearing that it might cause us not to be able to finish the project intime.

We have not explored the possibility of adjusting firing times to manipulate the robot‘sbehavior. This could have been further used in our design of the robot‘s functionality,to take further advantage of the possibilities offered by the delay time between transi-tions.

Instead of a button mounted on the robots van, we could instead have installed a colorsensor. The color sensor would then have been able to differ between different kindof hinders along the predetermined line. This could have enabled the robot to detectwhether an object should be avoided, in the case of a wall, or driven through, in case ofa gate, or moved into, in case of and end station.

29

References

[1] Bluetooth Installation. www.eng.buffalo.edu/~colinlea/Bluetooth_With_NXT.pdf. Accessed: April 25, 2012.

[2] GPenSIM: A Tool for Modeling and Simulation of Discrete-event Systems. http://www.davidrajuh.net/gpensim/. Accessed: April 21, 2012.

[3] MATLAB. http://www.mathworks.se/products/matlab/. Accessed: April 25,2012.

[4] NXT System. http://mindstorms.lego.com/en-us/whatisnxt/default.aspx.Accessed: May 13, 2012.

[5] Petri-LLD. http://sourceforge.net/projects/petrilld/. Accessed: May 14,2012.

[6] RWTH NXT Mindstorms Toolbox. http://www.mindstorms.rwth-aachen.de/.Accessed: April 25, 2012.

[7] Ultrasonic Acoustic Sensing. http://www.emant.com/index.php?tid=100011. Ac-cessed: May 13, 2012.

[8] J. Borenstein and Y. Koren. Obstacle avoidance with ultrasonic sensors. Roboticsand Automation, IEEE Journal of, 4(2):213 –218, apr 1988.

[9] Cao Quoc Huy. Line Follower Robot. http://robotic.iaun.ac.ir/files/robotic_9.pdf. Accessed: May 8, 2012.

[10] M. Pakdaman and M.M. Sanaatiyan. Design and implementation of line followerrobot. In Computer and Electrical Engineering, 2009. ICCEE ’09. Second Interna-tional Conference on, volume 2, pages 585 –590, dec. 2009.

30

A Complete Code

A.1 Main Simulation File (MSF)

% Main Simulat ion F i l e (MSF)

clear a l l ; close a l l ; clc

global g loba l_ in fo ;

% Real−Time run :g loba l_ in fo .REAL.TIME = 1 ;

% Stop run a f t e r 10 minutes :g loba l_ in fo .STOP_AT = current_clock (3 ) + [ 0 10 0 ] ;

init_NXT ( ) ; % I n i t i a l i z e s the robot ( sensors , motors e t c . )

png = pet r ine tg raph ( ’ robot_def ’ ) ; % Loads the Pe t r i net model

dynamicpart . i n i t i a l_mark ing s = { ’pLF_START’ , 1} ; % Sets i n i t i a l marking

sim = gpensim (png , dynamicpart ) ; % Runs the model

31

A.2 Initializationfunction [ ] = init_NXT ()

global g loba l_ in fo ; % Used to pass data between d i f f e r e n t% f i l e s in the GPenSIM environment

%% Communication se tup

% Setup o f the communication channel between the computer and the robot% v ia Bluetooth . Checks f i r s t f o r any open channels . I f one i s found ,% i t i s c losed , and a new one i s crea ted . The con f i gu ra t i on from the% Bluetooth con f i gu ra t i on f i l e i s read by the NXT so f tware .

% Close prev ious connect ions ( i f any ) :COM_CloseNXT a l l

% Use Bluetooth and open a new connect ion . Se t s the NXT−handle to d e f a u l t .% By doing so , there i s no need to s p e c i f y which mic rocon t ro l l e r to% communicate with in the r e s t o f the code .

hNXT = COM_OpenNXT( ’ b luetooth . i n i ’ ) ;COM_SetDefaultNXT(hNXT) ;g l oba l_ in fo . NXT_handle = hNXT;

%% Sensors and ac tua tor s :

% In t h i s b lock , the sensors ( switch , l i g h t and d i s t ance ) are i n i t i a l i z e d .% Also , the motors are i n i t i a l i z e d . The i n i t i a l i z a t i o n i s done by s p e c i f i y n g% which phy s i c a l por t s o f the mic rocon t ro l l e r the equipment i s connected to .% The t h r e s ho l d f o r the l i g h t sens ing i s s e t ( b l a c k and whi te t h r e s ho l d ) .%% Di f f e r en t motor o b j e c t s are crea ted . Constants f o r speed and ro t a t i on i s% de f ined .

% Sensor por t s :g loba l_ in fo .LIGHT_LEFT = SENSOR_1;g loba l_ in fo .LIGHT_RIGHT = SENSOR_2;g loba l_ in fo .ULTRASONIC = SENSOR_3;g loba l_ in fo .BUTTON = SENSOR_4;

% Light sensor t h r e s ho l d :g loba l_ in fo .THRESHOLD = 430 ;

% Object d i s t ance t h r e s ho l d :g loba l_ in fo .OBJECT_DISTANCE = 21 ;

% Motor Objec t s f o r l i n e f o l l ow e r :g loba l_ in fo .LF_FORWARD_POWER = 24 ;g l oba l_ in fo .LF_TURNING_POWER_SOFT = 26 ;g l oba l_ in fo .LF_TURNING_POWER_HARD = 30 ;g l oba l_ in fo .LF_MOTOR_LEFT = MOTOR_A;g loba l_ in fo .LF_MOTOR_RIGHT = MOTOR_B;

% For forward motion , syncron i za t i on i s recomended . I f not used , one wheel% w i l l s t a r t to r o t a t e be f o r e the other . Syncroniza t ion i s done by pu t t i n g% the l e f t and r i g h t motors in an array . This makes f o r a new syncronized% ob j e c t . This i s done fo r the o b j e c t s LF_DRIVE_FORWARD and OA_DRIVE_FORWARD.

% Motor o b j e c t s f o r l i n e f o l l ow e r :g loba l_ in fo .LF_MOTOR_BOTH = [ g loba l_ in fo .LF_MOTOR_LEFT; . . .

g l oba l_ in fo .LF_MOTOR_RIGHT] ;

32

g loba l_ in fo .LF_DRIVE_FORWARD = NXTMotor( g l oba l_ in fo .LF_MOTOR_BOTH, . . .’ Power ’ , g l oba l_ in fo .LF_FORWARD_POWER) ;

g l oba l_ in fo .LF_TURN_LEFT_SOFT = NXTMotor( g l oba l_ in fo .LF_MOTOR_RIGHT, . . .’ Power ’ , g l oba l_ in fo .LF_TURNING_POWER_SOFT) ;

g l oba l_ in fo .LF_TURN_LEFT_HARD = NXTMotor( g l oba l_ in fo .LF_MOTOR_RIGHT, . . .’ Power ’ , g l oba l_ in fo .LF_TURNING_POWER_HARD) ;

g l oba l_ in fo .LF_TURN_RIGHT_SOFT = NXTMotor( g l oba l_ in fo .LF_MOTOR_LEFT, . . .’ Power ’ , g l oba l_ in fo .LF_TURNING_POWER_SOFT) ;

g l oba l_ in fo .LF_TURN_RIGHT_HARD = NXTMotor( g l oba l_ in fo .LF_MOTOR_LEFT, . . .’ Power ’ , g l oba l_ in fo .LF_TURNING_POWER_HARD) ;

% Motor o b j e c t s f o r o b j e c t avoidance :g loba l_ in fo .OA_FORWARD_POWER = 35 ;g l oba l_ in fo .OA_TURNING_POWER = 20 ;g l oba l_ in fo .OA_TURRET_POWER = 10 ;g l oba l_ in fo .OA_VEHICLE_TACHOLIMIT = 500 ;g l oba l_ in fo .OA_TURRET_TACHOLIMIT = 90 ;g l oba l_ in fo .OA_MOTOR_LEFT = MOTOR_A;g loba l_ in fo .OA_MOTOR_RIGHT = MOTOR_B;g loba l_ in fo .OA_MOTOR_TURRET = MOTOR_C;g loba l_ in fo .OA_MOTOR_BOTH = [ g loba l_ in fo .OA_MOTOR_LEFT; . . .

g l oba l_ in fo .OA_MOTOR_RIGHT] ;

g l oba l_ in fo .OA_DRIVE_FORWARD = NXTMotor( g l oba l_ in fo .OA_MOTOR_BOTH, . . .’ Power ’ , g l oba l_ in fo .OA_FORWARD_POWER) ;

g l oba l_ in fo .OA_TURN_RIGHT_90 = NXTMotor( g l oba l_ in fo .OA_MOTOR_LEFT, . . .’ Power ’ , g l oba l_ in fo .OA_TURNING_POWER, . . .’ TachoLimit ’ , g l oba l_ in fo .OA_VEHICLE_TACHOLIMIT) ;

g l oba l_ in fo .OA_TURN_LEFT_90 = NXTMotor( g l oba l_ in fo .OA_MOTOR_RIGHT, . . .’ Power ’ , g l oba l_ in fo .OA_TURNING_POWER, . . .’ TachoLimit ’ , g l oba l_ in fo .OA_VEHICLE_TACHOLIMIT) ;

g l oba l_ in fo .OA_TURN_TURRET_LEFT_90 = NXTMotor( g l oba l_ in fo .OA_MOTOR_TURRET, . . .’ Power ’ , −g loba l_ in fo .OA_TURRET_POWER, . . .’ TachoLimit ’ , g l oba l_ in fo .OA_TURRET_TACHOLIMIT) ;

g l oba l_ in fo .OA_TURN_TURRET_RIGHT_90 = NXTMotor( g l oba l_ in fo .OA_MOTOR_TURRET, . . .’ Power ’ , g l oba l_ in fo .OA_TURRET_POWER, . . .’ TachoLimit ’ , g l oba l_ in fo .OA_TURRET_TACHOLIMIT) ;

%% Startup soundNXT_PlayTone(440 , 500 ) ;

%% Clear d i s p l a yclc

end

33

A.3 Petri Net Definition File (PDF)

% Petr i Net De f i n i t i on F i l e (PDF)

function [ png ] = robot_def ( )

png .PN_name = ’LEGO␣Robot ’ ;

png . set_of_Ps = { ’pLF_START’ , ’pLF_FORWARD’ , . . .’pLF_LEFT_SOFT’ , ’pLF_LEFT_HARD’ , ’pLF_LEFT_SOFT_2 ’ , . . .’pLF_RIGHT_SOFT’ , ’pLF_RIGHT_HARD’ , ’pLF_RIGHT_SOFT_2 ’ , . . .. . .’pOA_START’ , ’pOA_STOP_DRIVE’ , ’pOA_TURN_RIGHT_90 ’ , . . .’pOA_TURRET_LEFT_90 ’ , ’pOA_FORWARD’ , ’pOA_STOP_DRIVE_2 ’ , . . .’pOA_TURN_LEFT_90 ’ , ’pOA_FORWARD_2’ , ’pOA_STOP_DRIVE_3 ’ , . . .’pOA_TURRET_RIGHT_90 ’ , . . .’pOA_TURN_LEFT_90_2 ’ , ’pOA_FORWARD_3’ , ’pOA_STOP_DRIVE_4 ’ , . . .’pOA_TURN_RIGHT_90_2 ’ , . . .} ;

png . set_of_Ts = { ’tLF_START ’ , . . .’tLF_LEFT_SOFT ’ , ’tLF_FORWARD_1’ , ’tLF_LEFT_HARD’ , . . .’tLF_LEFT_SOFT_2 ’ , ’tLF_FORWARD_2’ , . . .. . .’tLF_RIGHT_SOFT ’ , ’tLF_FORWARD_4’ , ’tLF_RIGHT_HARD’ , . . .’tLF_RIGHT_SOFT_2 ’ , ’tLF_FORWARD_3’ , . . .. . .’tLF_TO_OA_FORWARD’ , ’tLF_TO_OA_LEFT’ , ’tOA_TO_LF’ , . . .’tLF_TO_OA_RIGHT’ , . . .. . .’tOA_STOP_DRIVE’ , ’tOA_TURN_RIGHT_90 ’ , ’tOA_TURRET_LEFT_90 ’ , . . .’tOA_FORWARD’ , ’tOA_STOP_DRIVE_2 ’ , ’tOA_TURN_LEFT_90 ’ , . . .’tOA_FORWARD_2’ , ’tOA_STOP_DRIVE_3 ’ , ’tOA_TURRET_RIGHT_90 ’ , . . .’tOA_TURN_LEFT_90_2 ’ , ’tOA_FORWARD_3’ , ’tOA_STOP_DRIVE_4 ’ , . . .’tOA_TURN_RIGHT_90_2 ’ , ’tLF_END_TRACK_LEFT’ , . . .’tLF_END_TRACK_RIGHT’ , ’tLF_END_TRACK_FORWARD’ , . . .} ;

png . set_of_As = { ’pLF_START’ , ’tLF_START ’ , 1 , . . .’tLF_START ’ , ’pLF_FORWARD’ , 1 , . . .. . .’pLF_FORWARD’ , ’tLF_LEFT_SOFT ’ , 1 , . . .’tLF_LEFT_SOFT ’ , ’pLF_LEFT_SOFT’ , 1 , . . .’pLF_LEFT_SOFT’ , ’tLF_FORWARD_1’ , 1 , . . .’tLF_FORWARD_1’ , ’pLF_FORWARD’ , 1 , . . .. . .’pLF_LEFT_SOFT’ , ’tLF_LEFT_HARD’ , 1 , . . .’tLF_LEFT_HARD’ , ’pLF_LEFT_HARD’ , 1 , . . .’pLF_LEFT_HARD’ , ’tLF_LEFT_SOFT_2 ’ , 1 , . . .’tLF_LEFT_SOFT_2 ’ , ’pLF_LEFT_SOFT_2 ’ , 1 , . . .’pLF_LEFT_SOFT_2 ’ , ’tLF_FORWARD_2’ , 1 , . . .’tLF_FORWARD_2’ , ’pLF_FORWARD’ , 1 , . . .. . .’pLF_FORWARD’ , ’tLF_RIGHT_SOFT ’ , 1 , . . .’tLF_RIGHT_SOFT ’ , ’pLF_RIGHT_SOFT’ , 1 , . . .’pLF_RIGHT_SOFT’ , ’tLF_FORWARD_4’ , 1 , . . .’tLF_FORWARD_4’ , ’pLF_FORWARD’ , 1 , . . .. . .’pLF_RIGHT_SOFT’ , ’tLF_RIGHT_HARD’ , 1 , . . .’tLF_RIGHT_HARD’ , ’pLF_RIGHT_HARD’ , 1 , . . .’pLF_RIGHT_HARD’ , ’tLF_RIGHT_SOFT_2 ’ , 1 , . . .’tLF_RIGHT_SOFT_2 ’ , ’pLF_RIGHT_SOFT_2 ’ , 1 , . . .’pLF_RIGHT_SOFT_2 ’ , ’tLF_FORWARD_3’ , 1 , . . .’tLF_FORWARD_3’ , ’pLF_FORWARD’ , 1 , . . .. . .’pLF_FORWARD’ , ’tLF_TO_OA_FORWARD’ , 1 , . . .

34

’tLF_TO_OA_FORWARD’ , ’pOA_START’ , 1 , . . .. . .’pOA_START’ , ’tOA_STOP_DRIVE ’ , 1 , . . .’tOA_STOP_DRIVE’ , ’pOA_STOP_DRIVE’ , 1 , . . .’pOA_STOP_DRIVE’ , ’tOA_TURN_RIGHT_90 ’ , 1 , . . .’tOA_TURN_RIGHT_90 ’ , ’pOA_TURN_RIGHT_90 ’ , 1 , . . .’pOA_TURN_RIGHT_90 ’ , ’tOA_TURRET_LEFT_90 ’ , 1 , . . .’tOA_TURRET_LEFT_90 ’ , ’pOA_TURRET_LEFT_90 ’ , 1 , . . .’pOA_TURRET_LEFT_90 ’ , ’tOA_FORWARD’ , 1 , . . .’tOA_FORWARD’ , ’pOA_FORWARD’ , 1 , . . .’pOA_FORWARD’ , ’tOA_STOP_DRIVE_2 ’ , 1 , . . .’tOA_STOP_DRIVE_2 ’ , ’pOA_STOP_DRIVE_2 ’ , 1 , . . .. . .’pOA_STOP_DRIVE_2 ’ , ’tOA_TURN_LEFT_90 ’ , 1 , . . .’tOA_TURN_LEFT_90 ’ , ’pOA_TURN_LEFT_90 ’ , 1 , . . .’pOA_TURN_LEFT_90 ’ , ’tOA_FORWARD_2’ , 1 , . . .’tOA_FORWARD_2’ , ’pOA_FORWARD_2’ , 1 , . . .’pOA_FORWARD_2’ , ’tOA_STOP_DRIVE_3 ’ , 1 , . . .’tOA_STOP_DRIVE_3 ’ , ’pOA_STOP_DRIVE_3 ’ , 1 , . . .’pOA_STOP_DRIVE_3 ’ , ’tOA_TURRET_RIGHT_90 ’ , 1 , . . .’tOA_TURRET_RIGHT_90 ’ , ’pOA_TURRET_RIGHT_90 ’ , 1 , . . .. . .’pOA_TURRET_RIGHT_90 ’ , ’tOA_TURN_LEFT_90_2 ’ , 1 , . . .’tOA_TURN_LEFT_90_2 ’ , ’pOA_TURN_LEFT_90_2 ’ , 1 , . . .’pOA_TURN_LEFT_90_2 ’ , ’tOA_FORWARD_3’ , 1 , . . .’tOA_FORWARD_3’ , ’pOA_FORWARD_3’ , 1 , . . .’pOA_FORWARD_3’ , ’tOA_STOP_DRIVE_4 ’ , 1 , . . .’tOA_STOP_DRIVE_4 ’ , ’pOA_STOP_DRIVE_4 ’ , 1 , . . .’pOA_STOP_DRIVE_4 ’ , ’tOA_TURN_RIGHT_90_2 ’ , 1 , . . .’tOA_TURN_RIGHT_90_2 ’ , ’pOA_TURN_RIGHT_90_2 ’ , 1 , . . .’pOA_TURN_RIGHT_90_2 ’ , ’tOA_TO_LF’ , 1 , . . .. . .’tOA_TO_LF’ , ’pLF_FORWARD’ , 1 , . . .. . .’pLF_FORWARD’ , ’tLF_END_TRACK_FORWARD’ , 1 , . . .’tLF_END_TRACK_FORWARD’ , ’pLF_START’ , 1 , . . .’pLF_LEFT_SOFT’ , ’tLF_END_TRACK_LEFT’ , 1 , . . .’tLF_END_TRACK_LEFT’ , ’pLF_START’ , 1 , . . .’pLF_RIGHT_SOFT’ , ’tLF_END_TRACK_RIGHT’ , 1 , . . .’tLF_END_TRACK_RIGHT’ , ’pLF_START’ , 1 , . . .. . .’pLF_LEFT_SOFT’ , ’tLF_TO_OA_LEFT’ , 1 , . . .’pLF_RIGHT_SOFT’ , ’tLF_TO_OA_RIGHT’ , 1 , . . .’tLF_TO_OA_LEFT’ , ’pOA_START’ , 1 , . . .’tLF_TO_OA_RIGHT’ , ’pOA_START’ , 1 , . . .} ;

end

35

A.4 Transition Definition Files (TDFs)

The pre and post files are given below (each function is a separate file).function [ f i r e , t r a n s i t i o n ] = tLF_END_TRACK_FORWARD_pre( t r a n s i t i o n )


openSwitch ;

i f (SWITCH_VALUE == true )f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tLF_END_TRACK_FORWARD_post( t r a n s i t i o n )


beepEND ;g loba l_ in fo .LF_DRIVE_FORWARD. Stop ( ’ o f f ’ ) ;

end

function [ f i r e , t r a n s i t i o n ] = tLF_END_TRACK_LEFT_pre( t r a n s i t i o n )


openSwitch ;


elsef i r e = 0 ;

end

end

function [ ] = tLF_END_TRACK_LEFT_post( t r a n s i t i o n )


beepEND ;g loba l_ in fo .LF_TURN_LEFT_SOFT. Stop ( ’ o f f ’ ) ;g l oba l_ in fo .LF_DRIVE_FORWARD. Stop ( ’ o f f ’ ) ;

end

36

function [ f i r e , t r a n s i t i o n ] = tLF_END_TRACK_RIGHT_pre( t r a n s i t i o n )


openSwitch ;


elsef i r e = 0 ;

end

end

function [ ] = tLF_END_TRACK_RIGHT_post( t r a n s i t i o n )


beepEND ;g loba l_ in fo .LF_TURN_RIGHT_SOFT. Stop ( ’ o f f ’ ) ;g l oba l_ in fo .LF_DRIVE_FORWARD. Stop ( ’ o f f ’ ) ;

end

function [ f i r e , t r a n s i t i o n ] = tLF_FORWARD_1_pre( t r a n s i t i o n )


openRightLight ;

i f (RIGHT_LIGHT_VALUE < THRESH)f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tLF_FORWARD_1_post( t r a n s i t i o n )


g l oba l_ in fo .LF_DRIVE_FORWARD.SendToNXT ( ) ;

end

37



openRightLight ;


elsef i r e = 0 ;

end

end




end



openLeftLight ;

i f (LEFT_LIGHT_VALUE < THRESH)f i r e = 1 ;

elsef i r e = 0 ;

end

end




end

38



openLeftLight ;


elsef i r e = 0 ;

end

end




end

function [ f i r e , t r a n s i t i o n ] = tLF_LEFT_HARD_pre( t r a n s i t i o n )


openLeftLight ;

i f (LEFT_LIGHT_VALUE > THRESH)f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tLF_LEFT_HARD_post( t r a n s i t i o n )


g l oba l_ in fo .LF_TURN_LEFT_HARD.SendToNXT ( ) ;

end

39

function [ f i r e , t r a n s i t i o n ] = tLF_LEFT_SOFT_2_pre( t r a n s i t i o n )


openLeftLight ;


elsef i r e = 0 ;

end

end

function [ ] = tLF_LEFT_SOFT_2_post( t r a n s i t i o n )


g l oba l_ in fo .LF_TURN_LEFT_SOFT.SendToNXT ( ) ;

end

function [ f i r e , t r a n s i t i o n ] = tLF_LEFT_SOFT_pre( t r a n s i t i o n )


openRightLight ;

i f (RIGHT_LIGHT_VALUE > THRESH)f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tLF_LEFT_SOFT_post( t r a n s i t i o n )


g l oba l_ in fo .LF_TURN_LEFT_SOFT.SendToNXT ( ) ;

end

40

function [ f i r e , t r a n s i t i o n ] = tLF_RIGHT_HARD_pre( t r a n s i t i o n )


openRightLight ;

i f (RIGHT_LIGHT_VALUE > THRESH)f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tLF_RIGHT_HARD_post( t r a n s i t i o n )


g l oba l_ in fo .LF_TURN_RIGHT_HARD.SendToNXT ( ) ;

end

function [ f i r e , t r a n s i t i o n ] = tLF_RIGHT_SOFT_2_pre( t r a n s i t i o n )


openRightLight ;


elsef i r e = 0 ;

end

end

function [ ] = tLF_RIGHT_SOFT_2_post( t r a n s i t i o n )


g l oba l_ in fo .LF_TURN_RIGHT_SOFT.SendToNXT ( ) ;

end

41

function [ f i r e , t r a n s i t i o n ] = tLF_RIGHT_SOFT_pre( t r a n s i t i o n )


openLeftLight ;

i f (LEFT_LIGHT_VALUE > THRESH)f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tLF_RIGHT_SOFT_post( t r a n s i t i o n )


g l oba l_ in fo .LF_TURN_RIGHT_SOFT.SendToNXT ( ) ;

end

function [ f i r e , t r a n s i t i o n ] = tLF_START_pre( t r a n s i t i o n )


openSwitch ;

i f (SWITCH_VALUE == f a l s e )f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tLF_START_post( t r a n s i t i o n )


beepLF ;g loba l_ in fo .LF_DRIVE_FORWARD.SendToNXT ( ) ;

end

42

function [ f i r e , t r a n s i t i o n ] = tLF_TO_OA_FORWARD_pre( t r a n s i t i o n )


openUlt rason ic ;

i f (DISTANCE < globa l_ in fo .OBJECT_DISTANCE)f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tLF_TO_OA_FORWARD_post( t r a n s i t i o n )

beepOA ;

end

function [ f i r e , t r a n s i t i o n ] = tLF_TO_OA_LEFT_pre( t r a n s i t i o n )


openUlt rason ic ;


elsef i r e = 0 ;

end

end

function [ ] = tLF_TO_OA_LEFT_post( t r a n s i t i o n )

beepOA ;

end

43

function [ f i r e , t r a n s i t i o n ] = tLF_TO_OA_RIGHT_pre( t r a n s i t i o n )


openUlt rason ic ;


elsef i r e = 0 ;

end

end

function [ ] = tLF_TO_OA_RIGHT_post( t r a n s i t i o n )

beepOA ;

end

function [ f i r e , t r a n s i t i o n ] = tOA_FORWARD_2_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_FORWARD_2_post( t r a n s i t i o n )


g l oba l_ in fo .OA_DRIVE_FORWARD.SendToNXT ( ) ;

end

44

function [ f i r e , t r a n s i t i o n ] = tOA_FORWARD_3_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_FORWARD_3_post( t r a n s i t i o n )



end

function [ f i r e , t r a n s i t i o n ] = tOA_FORWARD_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_FORWARD_post( t r a n s i t i o n )



end

45

function [ f i r e , t r a n s i t i o n ] = tOA_STOP_DRIVE_2_pre( t r a n s i t i o n )


openUlt rason ic ;

i f (DISTANCE > 30)f i r e = 1 ;

elsef i r e = 0 ;

end

end

function [ ] = tOA_STOP_DRIVE_2_post( t r a n s i t i o n )


g l oba l_ in fo .OA_DRIVE_FORWARD. Stop ( ’ o f f ’ ) ;

end



openUlt rason ic ;

i f (DISTANCE > 30)f i r e = 1 ;

elsef i r e = 0 ;

end

end




end

46



openLeftLight ;openRightLight ;

i f (RIGHT_LIGHT_VALUE < THRESH && LEFT_LIGHT_VALUE < THRESH)f i r e = 1 ;

elsef i r e = 0 ;

end

end




end

function [ f i r e , t r a n s i t i o n ] = tOA_STOP_DRIVE_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_STOP_DRIVE_post( t r a n s i t i o n )


g l oba l_ in fo .LF_DRIVE_FORWARD. Stop ( ’ o f f ’ ) ;NXT_PlayTone(880 , 100 ) ;

end

47

function [ f i r e , t r a n s i t i o n ] = tOA_TO_LF_pre( t r a n s i t i o n )


f i r e = 1 ;

end

function [ f i r e , t r a n s i t i o n ] = tOA_TO_LF_post( t r a n s i t i o n )


beepLF ;g loba l_ in fo .LF_DRIVE_FORWARD.SendToNXT ( ) ;

end

function [ f i r e , t r a n s i t i o n ] = tOA_TURN_LEFT_90_2_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_TURN_LEFT_90_2_post( t r a n s i t i o n )


g l oba l_ in fo .OA_TURN_LEFT_90.SendToNXT ( ) ;g l oba l_ in fo .OA_TURN_LEFT_90. WaitFor ( ) ;g l oba l_ in fo .OA_TURN_LEFT_90. Stop ( ’ o f f ’ ) ;

end

48

function [ f i r e , t r a n s i t i o n ] = tOA_TURN_LEFT_90_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_TURN_LEFT_90_post( t r a n s i t i o n )


g l oba l_ in fo .OA_TURN_LEFT_90.SendToNXT ( ) ;g l oba l_ in fo .OA_TURN_LEFT_90. WaitFor ( ) ;g l oba l_ in fo .OA_TURN_LEFT_90. Stop ( ’ o f f ’ ) ;

end

function [ f i r e , t r a n s i t i o n ] = tOA_TURN_RIGHT_90_2_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_TURN_RIGHT_90_2_post( t r a n s i t i o n )


g l oba l_ in fo .OA_TURN_RIGHT_90.SendToNXT ( ) ;g l oba l_ in fo .OA_TURN_RIGHT_90. WaitFor ( ) ;g l oba l_ in fo .OA_TURN_RIGHT_90. Stop ( ’ o f f ’ ) ;

end

49

function [ f i r e , t r a n s i t i o n ] = tOA_TURN_RIGHT_90_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_TURN_RIGHT_90_post( t r a n s i t i o n )


g l oba l_ in fo .OA_TURN_RIGHT_90.SendToNXT ( ) ;g l oba l_ in fo .OA_TURN_RIGHT_90. WaitFor ( ) ;g l oba l_ in fo .OA_TURN_RIGHT_90. Stop ( ’ o f f ’ ) ;

end

function [ f i r e , t r a n s i t i o n ] = tOA_TURRET_LEFT_90_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_TURRET_LEFT_90_post( t r a n s i t i o n )


g l oba l_ in fo .OA_TURN_TURRET_LEFT_90.SendToNXT ( ) ;g l oba l_ in fo .OA_TURN_TURRET_LEFT_90. WaitFor ( ) ;g l oba l_ in fo .OA_TURN_TURRET_LEFT_90. Stop ( ’ brake ’ ) ;g l oba l_ in fo .OA_TURN_TURRET_LEFT_90. Stop ( ’ o f f ’ ) ;

end

50

function [ f i r e , t r a n s i t i o n ] = tOA_TURRET_RIGHT_90_pre( t r a n s i t i o n )

f i r e = 1 ;

end

function [ ] = tOA_TURRET_RIGHT_90_post( t r a n s i t i o n )


g l oba l_ in fo .OA_TURN_TURRET_RIGHT_90.SendToNXT ( ) ;g l oba l_ in fo .OA_TURN_TURRET_RIGHT_90. WaitFor ( ) ;g l oba l_ in fo .OA_TURN_TURRET_RIGHT_90. Stop ( ’ brake ’ ) ;g l oba l_ in fo .OA_TURN_TURRET_RIGHT_90. Stop ( ’ o f f ’ ) ;

end

51

A.5 Reading of Sensor Values

% Opens the l e f t l i g h t sensor ( in a c t i v e mode) and g e t s the va lue from i t .% Also , the t h r e s ho l d va lue i s loaded .

LEFT_LIGHT = globa l_ in fo .LIGHT_LEFT;THRESH = globa l_ in fo .THRESHOLD;

OpenLight (LEFT_LIGHT, ’ACTIVE ’ ) ;LEFT_LIGHT_VALUE = GetLight (LEFT_LIGHT) ;

% Opens the r i g h t l i g h t sensor ( in a c t i v e mode) and g e t s the va lue from i t .% Also , the t h r e s ho l d va lue i s loaded .

RIGHT_LIGHT = globa l_ in fo .LIGHT_RIGHT;THRESH = globa l_ in fo .THRESHOLD;

OpenLight (RIGHT_LIGHT, ’ACTIVE ’ ) ;RIGHT_LIGHT_VALUE = GetLight (RIGHT_LIGHT) ;

% Opens the swi tch sensor ( in a c t i v e mode) and g e t s the va lue from i t .

SWITCH = globa l_ in fo .BUTTON;OpenSwitch (SWITCH) ;SWITCH_VALUE = GetSwitch (SWITCH) ;

% Opens the u l t r a s on i c d i s t ance sensor and g e t s the va lue from i t .

ULTRASONIC_SENSOR = globa l_ in fo .ULTRASONIC;OpenUltrasonic (ULTRASONIC_SENSOR) ;DISTANCE = GetUlt rason ic (ULTRASONIC_SENSOR) ;

A.6 Sounds

NXT_PlayTone(220 , 1000 ) ;

NXT_PlayTone(880 , 1000 ) ;

NXT_PlayTone(1760 , 1000 ) ;

52

B Installation Guide

1. Install MATLAB, version 7.7 (R2008b) or higher [3].

2. Install the GPenSIM toolbox [2].

3. Install the RWTH Mindstorms NXT toolbox [6].

4. Install a Bluetooth 2.0 adapter (or use a built-in if your computer has one). Fol-low these instructions to correctly set up a Bluetooth connection with the NXTmicrocontroller [1].

C User Manual

1. Complete the steps in Appendix B.

2. Build the robot (instructions in Appendix D). Connect the sensors and actuatorsas shown in the hardware connection diagram in figure 10. Turn on the NXTmicrocontroller and connect with your computer with Bluetooth.

3. Open the folder named LEGO_Robot in MATLAB.

4. Run the file named robot.m. This is the main simulation file (MSF). This will startthe connection with the robot and a startup sound will be played indicating thatthe robot is ready to start. Now the robot will start its operation.

5. To stop, press the gray button below the big yellow button on the microcontrollerand press CTRL+C in the MATLAB command window.

D Building Instructions

Building instructions for the robot are shown in the following pages.

53

LEGO Robot Building Instructions

3 x

Step 1 of 39

1 x

Step 2 of 39

1 x

1 x

Step 3 of 39

1 x

3 x

Step 4 of 39

1 x

3 x

Step 5 of 39

1 x

3 x

Step 6 of 39

1 x

1 x

2 x

Step 7 of 39

1 x

3 x

Step 8 of 39

1 x

2 x

Step 9 of 39

1 x

1 x

1 x

1 x

Step 10 of 39

1 x

1 x

1 x

Step 11 of 39

1 x

1 x

1 x

1 x

Step 12 of 39

2 x

1 x

1 x

Step 13 of 39

2 x

2 x

Step 14 of 39

1 x

2 x

1 x

Step 15 of 39

1 x

1 x

1 x

Step 16 of 39

Step 17 of 39

1 x

2 x

1 x

Step 18 of 39

1 x

1 x

1 x

1 x

Step 19 of 39

4 x

Step 20 of 39

Step 21 of 39

1 x

1 x

1 x

Step 22 of 39

1 x

1 x

1 x

1 x

Step 23 of 39

2 x

Step 24 of 39

1 x

1 x

2 x

Step 25 of 39

1 x

2 x

Step 26 of 39

1 x

1 x

1 x

1 x

Step 27 of 39

1 x

1 x

2 x

Step 28 of 39

1 x

1 x

1 x

1 x

Step 29 of 39

1 x

3 x

Step 30 of 39

1 x

1 x

Step 31 of 39

1 x

2 x

1 x

Step 32 of 39

1 x

1 x

2 x

Step 33 of 39

1 x

1 x

2 x

Step 34 of 39

1 x

3 x

Step 35 of 39

1 x

1 x

Step 36 of 39

1 x

1 x

1 x

1 x

Step 37 of 39

1 x

1 x

2 x

Step 38 of 39

Step 39 of 39

2 x 4297210 RIM WIDE W.CROSS 30x20- Medium Stone Grey 2 x 4184286 TYRE NORMAL WIDE

Ø43,2 X 22 - Black 2 x 4296917

Lightsensor - White,BrightOrange,Medium StoneGrey,Dark Stone Grey,LightStone Grey

1 x 4296929

Push sensor - BrightOrange,Medium StoneGrey,Dark Stone Grey,LightStone Grey

1 x 4297174

Ultrasound sensor - BrightOrange,Medium StoneGrey,Dark Stone Grey,LightStone Grey

3 x 4297008Tacho Motor - BrightOrange,Dark StoneGrey,Light Stone Grey

1 x 4520887

NXT - Black,BrightOrange,SandGreen,Medium StoneGrey,Dark Stone Grey,LightStone Grey,Cool silver, drumlacq

1 x 4210751 TECHNIC 3M BEAM - DarkStone Grey 3 x 4211651 TECHNIC 5M BEAM -

Medium Stone Grey

3 x 4297199 TECHNIC 7M BEAM - LightStone Grey 2 x 4210667 TECHNIC ANG. BEAM 4X2

90 DEG - Dark Stone Grey

6 x 4297202 TECHNIC 9M BEAM - LightStone Grey 2 x 4297200 TECHNIC 11M BEAM - Light

Stone Grey 3 x 4297197 TECHNIC 15M BEAM -Light Stone Grey

5 x 4210753 TECHNIC ANG. BEAM 3X590 DEG. - Dark Stone Grey 4 x 4210668 DOUBLE ANGULAR BEAM

3X7 45° - Dark Stone Grey 47 x 4121715 CONNECTOR PEG W.FRICTION - Black

2 x 4186017 CONNECTOR PEG/CROSSAXLE - Brick Yellow 5 x 4206482

CONN.BUSHW.FRIC./CROSSALE -Bright Blue

2 x 370526 CROSS AXLE 4M - Black

9 x 4514553 CONNECTOR PEG W.FRICTION 3M - Bright Blue 4 x 4211639 CROSS AXLE 5M - Medium

Stone Grey 5 x 4211775 CROSS BLOCK 90° -Medium Stone Grey

2 x 370626 CROSS AXLE 6M - Black 6 x 4121667 DOUBLE CROSS BLOCK -Black 4 x 4296059 Angular beam 90degr. w.4

snaps - Medium Stone Grey

E Track

Next page contains the track. This can be printed out (A0 is the full size).

96

a petri net based approach for creating line-following, route-measuring and object-avoiding...

Documents

petri net model

petri net theory

final petri net

petri net denition file

dierent functionalities

previous line

black line

lego robot project