the report in ms word (.doc) (3mb)

MARVIN by Jordi, Arvind and Guido

1


Outline

<>

Introduction

The Team

Tools and Definitions

Task

Design process

Implementation

Evaluation

Appendix A

Introduction

<><>

“All programmers are playwrights and all robots are lousy actors.”

2

http://www.quotationspage.com/quote/221.html

http://www.quotationspage.com/quote/221.html


Guido Camps

Designing, building and programming a robot is an unusual experience; we have the LEGO blocks to build the robot, we have the creative ideas for the design, we have the programming skills to write the software to run the robot and yet...yet all those elements do not seem to guarantee a smooth and fast process for creating a robot.

Hours of testing, re-testing, swearing, praying, pleading and starting over again went into creating a vehicle that could perform the simplest of tasks. Apparently the synergy of above-mentioned elements is more unpredictable than we hoped and expected.

In this report we will explain the evolutionary process of the creation of our robot MARVIN in light of concurrent theories of robotics and the design choices we made.

The Team

<><><>

Our team consists of three members from the department of artificial intelligence at the University of Nijmegen.

Team se7en started this project as three friends that knew each other from

3


their programming classes; they are expected to end the project as twosworn enemies and an unfortunate LEGO accident.

The three members are, in no particular order (except for the fact that the third one is the coolest):

Arvind:Some people like ‘birds’, some people like ‘airplanes’, Arvind likes ‘walls’1; If the other members of the team would take their eyes of the LEGO kit for a second Arvind would have grabbed enough of the material and crawled to some corner to build a LEGO-wall out of the cubes. Supposedly these ‘walls’ add strength to the overall design. Sadly this theory had to be proven wrong 35 times2 before Arvind would admit that ‘they may not be super strong, but aesthetically they function superbly’. Arvind’s main project is building the Great Wall of Holland to keep out the Mongolians. Faced with the question: ‘But there aren’t any Mongolians here!’, Arvind snickers to himself: ‘See how it’s working…’ Jordi and Guido expect Arvind’s love for walls to be a psychological obsession implanted by the other teams to thwart se7en’s plans, unfortunately they were successful: MARVIN’s final design has walls.

1 This may explain the first emergent behavior our robot displayed, which earned him his name2 See above footnote

4


Jordi:

When all members received their grades for Mathematics for Artificial Intelligence during the Robotics course, Arvind and Guido were jumping around drunk with happiness over their 6’s, thereby passing the course. Jordi simple lifted his head an inch from the LEGO kit and grunted: ‘Obviously I scored a 10’. Because of this superhuman achievement Guido has long suspected Jordi himself to be a robot. Especially since Guido is Jordi’s sparring partner during boxing classes, and subsequently has had to type this report with his elbows.Fortunately Jordi has no obsession with walls, he is fond of small wheels however. His favorite wheels were so small MARVIN would either spontaneously break down or fall over during sharp turns. Jordi’s small wheels and Arvind’s walls are sure to make MARVIN propel himself into oblivion quickly.Luckily Guido hopes to prove Jordi to really be a robot just before the deadline, so that team se7en can enter Jordi as their robot instead. We have high hopes that Jordi will be able to collect eggs slightly faster than MARVIN.

Guido:

5


His impressive looks and natural charm are only surpassed by his quick, witty remarks and humor. Often Guido would keep the team from appending doom with his straight-to-the-point advice and help. His sarcasm would make Arvind and Jordi see their mistakes more clearly (such as letting him write this report).Guido is expected to become world-president any day now. He’ll also settle for a dictatorship.

Tools and Definitions

<><><><>

Here we will explain what the exact building blocks and tools were, that we had at our disposal for the creation of MARVIN.

In order to properly discuss robotics, MARVIN and the task, some definitions are in order.

Who is MARVIN:Marvin the Paranoid Android is a fictional character in The Hitchhiker's Guide to the Galaxy series by Douglas Adams.

6

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

http://en.wikipedia.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy

http://en.wikipedia.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy

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


Marvin is the ship's robot aboard the starship Heart of Gold. Severely depressed, Marvin was built as a prototype of Sirius Cybernetics Corporation's "Genuine People Personalities" technology. He has a "brain the size of a planet", but seldom gets the chance to use it. Instead, he continually whines about his troubles, irritating his crewmembers.3

Our robot was dubbed ‘Marvin’ because of his suicidal tendencies: other teams4 came with the suggestion after MARVIN had rammed himself in a wall for the 10th time, or spontaneously combusted into several parts during a trial. We stuck with it.

What is a robot:In practical usage, a robot is a mechanical device which performs automated physical tasks, either according to direct human supervision, a pre-defined program or, a set of general guidelines using artificial intelligence techniques. Robots are typically used to do the tasks that are too dirty, dangerous, difficult, repetitive or dull for humans.5

What is robotics:Robotics is the science or study of the technology associated with the design, fabrication, theory, and application of robots.6

How was MARVIN built:MARVIN was built using the LEGO MindStorms ROBOTICS INVENTION systems 2.07.MARVIN has a ‘brick’, which is his brain/heart and contains all sensor input modules, engine modules, and batteries. MARVIN has two touch sensors and one light/infrared sensor. MARVIN has only two engines which are used for propulsion, steering, catching and releasing eggs and everything else. That may sound impossible, but it is8.

3 Definition taken from: http://en.wikipedia.org/wiki/Marvin_the_Paranoid_Android4 Suck5 Definition taken from: http://en.wikipedia.org/wiki/Robot6 Definition taken from: http://en.wikipedia.org/wiki/Robot7 During the building and rebuilding almost all pieces from the LEGO kit were used. Only 3 pieces were lost in this process, we think Arvind may have eaten one of them.8 Thank you Mr. Vuurpijl & Mr. Haselager.

7

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

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

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

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

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

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

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

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

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

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

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


Where did MARVIN’s intelligence come from:He doesn’t have any. MARVIN’s faked intelligence stems from two sources:

Direct programmed functionality, which more represents our intelligence (read: we explicitly program smart things for MARVIN to do, such as exploding and slamming into walls).

Emergent behavior, ‘smart’ behavior which naturally emerges from ‘stupid’ primitive layers of behavior working together. An example of this is when MARVIN’s avoid and path following layer work together in automatically bringing him to the center of the nest, without this having been explicitly programmed.

In what language was MARVIN’s brain written:His program is written in NQC, which stands for Not Quite C, a very clever name for a language that is much like C, but not quite C. The complete code of MARVIN’s brain can be found under Appendix A.

Task specification

<><><><><>

MARVIN was created for a very important task, a quest so dangerous it could only be accomplished by a robot: to find and keep eggs. Basically MARVIN has the same objective as a child on Easter morning. MARVIN’s world is a plane with borders in which there can be obstacles. MARVIN’s world is white, MARVIN’s nest is black and the path to his nest is also black. Scattered throughout his world are eggs. As with all eggs, they belong in their nest.

MARVIN’s task is to bring as many eggs as possible to his nest.

8


MARVIN gains extra points if he follows the path and rides across the seesaw successfully. Finding and grabbing an egg gains MARVIN several points, additional points can be gotten by releasing the eggs over the nest. MARVIN needs to be completely autonomous and any tinkering during MARVIN’s run will be severely punished.

MARVIN will only care about his eggs, but we of team se7en also care about the grade that is received for the course. Therefore our goal is to catch and release all eggs in the nest and cross the seesaw.

Above is a digital rendering of a possible set-up of MARVIN’s world. Below a birds-eye-view of this same rendering can be found with corresponding names for all depicted objects.

9


Design Process

<><><><><><>

10


Though MARVIN’s design and appearance has changed dramatically through time because of various reasons, there was a general design created before we touched any blocks of LEGO9. The problem with the task as it lay before us is that there is a need to drive, steer, catch and release eggs with only two motors. Driving and steering require two motors: two wheels powered independently are used for forward, reverse and steering (by reversing one and forwarding the other MARVIN can turn in situ).

This led us to the conclusion that any ingenious egg catching contraptions were out of the question, as we could only use motor power which was directly drawn from the wheels. Thus, using the wheels as the means of transportation, we quickly decided to use the caterpillars (which could also be used for propulsion) as conveyer belts for our eggs. This led us to the following concepts as they are shown below.

These ideas where all dismissed as they lead to problems with feasibility, or simply made the robot to long or big for the delicate movements needed in the arena.9 With the exception of Arvind who felt like snacking.

11


Thus we decided to keep going with the conveyer belt idea, but to keep the robot small, and to create the least amount of problems ‘scooping’ the eggs we came up with the idea to place the conveyer belts underneath the robot, and let the eggs pass underneath as the robot ran in to them. This design has as added advantage that eggs are secured when ‘caught’ behind the moving the conveyer belt and their release can be controlled: only when MARVIN reverses for an extended period will the conveyer belt ‘shoot’ out the egg. Practically the robot rolls over the egg in such a manner that the egg remains perfectly still at the exact location were it should be released.

In order to feel obstacles and know when to avoid these we needed a bumper. We have chosen to use only one bump-sensor for this. Though two bump-sensors would yield much more information about the exact location of the obstacle, we felt that a bump-sensor used to detect the catching of an egg overall is more effective.

The design including bumper, conveyer belt and egg-guiding rims lead to the following concept sketches.

12


13


With these concepts and design choices we created MARVIN from the LEGO kit. Simultaneous with this ‘real-world’ creation we created a 3D model of MARVIN for simulations and cool pictures for this website.

The wire frame render as rendered below shows the conveyer belt

14


15


This model had loads of problems which forced us to renew the design and adapt to problems we had not foreseen.

Firstly the big wheels made MARVIN fast, but also had not enough traction to master the slope of the seesaw. On top of this the speed made MARVIN self-destructive as he ran into walls.

Additionally the single conveyer belt was very problematic. When driven by one of the wheel motors, the conveyer belt would run too slow, and the additional drag on the motor made the robot drive in circles. Hooking up the conveyer belt to both engines would not only drain so much power that MARVIN moved in slow-motion, it also was disastrous when MARVIN turned and motors were moving in opposite directions.

Lastly the design was unstable, as MARVIN frequently toppled over. We needed a more stable wheel base.

All these problems lead to a complete renewal of MARVIN and we ended up with the following modified design.

16


17


We gave MARVIN smaller wheels, which had more traction. On top of this they were in set in a lower gear. MARVIN gained power and stability by hooking up his latter two wheels to the front: four-wheel driving10. MARVIN in this form can take the seesaw without problems. The brick was moved up to add more room: we inserted and additional conveyer belt. The two caterpillars were hooked up to their corresponding motors to distribute stress evenly over the two motors.

Because MARVIN’s centre of gravity is slightly elevated to create a passage way for the eggs underneath, there is a slight chance that he tilts forward after coming down the seesaw. Because of this danger we added two counter-wheels which keep MARVIN upright. They also guide the eggs into MARVIN’s mouth and under his caterpillars.

10 MARVIN can now also go off-terrain and find golf balls on an actual golf-course

18


These views of MARVIN show his mouth opening, caterpillars and the wire frame for the insides.

Below are photos of the real life MARVIN. None of the fundamental parts have been changed outside of the descriptions above, however be aware of the fact that MARVIN looks different from these images as we added some of his features in the final stages before the presentation, such as hamsters and Jedi knights.

19


20


Software implementation

<><><><><><><>

21


The software that we have written for MARVIN consists out of layers of behavior which can be executed simultaneously and can influence each other.First we’ll explain the reactive paradigm under which the design and software of MARVIN falls. Secondly and explanation of the behavior as it should results from the code under appendix A will be given.

Reactive ParadigmFor the assignment, MARVIN was required to use the reactive paradigm. He was not supposed to keep track of a map of the world or something like that and he couldn't plan ahead. He had to react to his sensor input immediately. In order to do this, we first went through the steps of Marr's computational theory. Level 1 wonders if the task can actually be done. Not a lot of animals make a habit out of doing the exact same thing, but there are a lot of animals that collect food and bring it back to their home or another safe spot. Level 2 represents the decomposition of the task into inputs, outputs and transformations.

The inputs MARVIN will get, come from his three sensors. He will get the light values of the floor he is currently riding over and he will get information from both his touch sensors when he hits an obstacle or captures a ball. The output will hopefully be that he walks around aimlessly until he comes across a ball and then starts to find and follow a path. He should finally leave the ball in the safe haven. Level 3 won't be discussed here, because that will be the main focus of the rest of this report.

MARVIN will obviously use reflexive behaviours, because it seemed kind of hard to make him learn something about when to execute a certain behaviour (reactive) or to give him conscious thought. Reflexes will be used to trigger a new behaviour when something happens. For example, when MARVIN catches a ball, he will start to find a path. Taxes are also used, for example when MARVIN hits something and he tries to avoid it. Finally, MARVIN also utilizes fixed action patterns. An example of this is that he will turn a full round if he thinks he is on the safe haven and then reverse hard to release the ball.When two or more behaviours want to do things that don't really go well together, MARVIN uses dominance and one behaviour will win.

22


Perception serves to realease behaviours, but sometimes it also includes perceiving the information that is required to accomplish a behaviour. MARVIN will obviously use direct perception for these tasks.

MARVIN utilizes the subsumption architecture. He has some low-level behaviours that can be inhibited by smarter high-level ones. MARVIN does however keep track of some sort of internal state. He will keep track of whether he has a ball and if he is currently on a path.

In order to build MARVIN, a few standard steps where taken when designing him:1. Define the ecological niche1.1 What is the task?The robot has to collect as much balls as possible and then follow a path over a seesaw into a safe haven and release the balls there.1.2 What can MARVIN do?Obviously we will only know when MARVIN has been designed, but we already knew that he has two motors, two touch sensors and a light sensor. After building MARVIN we know that he can follow a wall, pick up balles, follow a path, cross the seesaw and release the ball in the correct spot.1.3 What does the environment look like?The environment is about two by two metres and has walls. The floor is mostly white, but there is a path to a black corner that is the safe haven. MARVIN will start in another corner and the balls will be in the two empty corners. There will also be obstacles.

2. Define the set of behavioursWander:- Wander around aimlessly.checkBumper:- Avoid obstacles.- Check for a safe haven when on the path.checkLight:- Update the black and white thresholds.- Start following a path when necessary.checkBall:- Change the internal state and start looking for a path if a ball is caught.followPath:

23


- Follow a path.recoverPath:- Refind the path.checkSafeHaven:- Check if MARVIN is in the safe haven and release the ball if so.releaseBall:- Release the ball, change internal state back and start over.

Steps 3, 4 and 5 have also been completed, but they are either discussed elsewhere or not interesting to discuss here.

Implementing the GoalsMARVIN's brain has four main goals:- He has to find as many eggs as possible- He has to follow the path- He has to recover the path when he loses it- He has to cross the seesaw- He has to survive

Finding the eggsBecause MARVIN has no way of seeing the balls, he will have to drive around at random until he stumbles upon one. MARVIN will start his quest in one corner of the arena. The safe haven is in another, and the eggs will probably be located somewhere near the last two corners. If this is the case, one way to increase our chance of succes is to let marvin wander around the edge of the arena. We will incorporate wall-following behaviour by letting MARVIN turn a little bit to the same side every time he hits an obstacle or wall. This will make sure that MARVIN will eventually more or less walk parallel to the wall or obstacle. Because we are not sure of the location of the eggs, pure wall-following will not be sufficient. A certain random wandering behaviour will also be incorporated.

If the gods favour Team Se7en and let MARVIN come across a ball, he will catch it and he will turn. If MARVIN was following a wall at the time, he will make a turn of about 150 degrees away from the wall, because that will likely make him cross the path in the middle of the arena.

When the ball is found, the default wandering behaviour is maintained, but any wall-following tasks will stop. MARVIN will then start trying to find a black surface and follow it, because the black path leads to the safehaven.

24


Ofcourse when balls have been placed in the safehaven, we do not want to catch them again, or knock them out of the way. To avoid this, we try to avoid all black surfaces during the wandering behaviour.

Following the pathFrom the beginning when his program started, MARVIN has been keeping track of the average values of black and white parts of the floor. This allows him to calculate certain thresholds that he can use. There is a threshold beneath which all values are considered white and one above which all values are considered black. There is a margin in between that will always be ignored. We felt this was necessary, because of the grey tape on the seesaw and other disturbing factors.

When MARVIN comes across a path, he will jump out of the wandering behaviour and start following the path. While doing this, he will limp a little to his left. This has two advantages.1. Because his sensor is to his left, this makes it likely that MARVIN will go

off the path on the left side. Knowing this makes it easier for us to find the path back when that happens. Unfortunately, this doesn’t really help when the path has a lot of sharp turns.

2. Another advantage of this setup is that MARVIN will stay closer to the middle of the path. If he would follow the right edge, the largest part of him would be beside the path most of the time. This could make him fall off the side of the seesaw.

Recovering the pathIf MARVIN trails off the path, he will try to recover it by first turning a little bit to his right, because if he left the path because of his limp, that is the side where he can find it back. After that he will turn the same amount to his left, then a little bit further to the right and so on.

While doing this, he sometimes also backs up a bit. Reversing obviously means that he will find the path back, because he lost it when he went forward. Reversing only happens at a certain angle however, so if MARVIN comes back at the exact same place where he left the path, he will at least go in a (slightly) different direction, so he won’t go off at the same place again. When MARVIN encounters a black floor, he will stop recovering the path and start following it again. MARVIN will give up on finding the path if he

25


has turned 180 degrees, because it’s no use turning any further (he would have tried both sides by then). If this happens, MARVIN will go back to his wandering behaviour while looking out for a path.

Crossing the seesawMoving along the seesaw is in essence the same as following a black path. When the seesaw goes down however, this can give MARVIN quite a bump, especially since his center of gravity is not very low. In an attempt to avoid a fatal landing, we move at a slower rate during path following than we do during wandering. This also helps MARVIN keep track of the path near difficult corners.

Finding the safehavenIf MARVIN bumps into something while following the path, there are two possibilities: He either hit an obstacle that was close to the path, or he hit a wall and he is in the black corner a.k.a. the safe haven. To test this, he will reverse a little bit to make room for turning, and start to do a full 360 degree turn.

If he encounters any white during this turn, that means that the black spot near the obstacle/wall wasn’t very big and thus probably not the safehaven. In that case, MARVIN will turn to his right, because he is likely to be on the left of the path and will thus try to avoid the obstacle.

If he was at the safe haven, however, he will reverse full throttle and leave the ball in the nest. He will then stop following the path and start wandering, in search of a new ball. Also see the code and comments for more information.

26


27


Evaluation

<><><><><><><><>

We have aimed high during the design and construction of MARVIN; under perfect conditions MARVIN would able to catch, bring back and release all balls during his trial.

Strong pointsMARVIN’s strong points are that he is able to release a ball at all, and do it very precisely. He also has a specific egg-sensor, which makes his behaviour radically change when he has actually caught an egg. This is much more effective than simply wandering about hoping to come across the safe haven after stumbling onto an egg. Lastly, MARVIN’s 4-wheel drive gives him the extra traction for difficult slopes, and makes his steering very quick and direct.

Weak pointsWe are also realistic and see that MARVIN, how well-built he may be, has qualities which could affect his resulting performance.

Tumbling over First of all, the heavy brick is placed fairly high in the construction. The reason for this was to make certain eggs can pass underneath him. His high centre of gravity means that he can tumble over fairly easily. The added some wheels on the front counter the biggest hits MARVIN is expected to take going down the seesaw. There is a possibility that he may fall over or at least lose his egg during the flip, the chance of this happening is minimal though.

Chances and probabilitiesAnother concern we have has to do with the randomness of MARVIN’s behaviour. He will wander around hoping he comes across a ball at such an angle that he will actually capture it. There is always the possibility that with a limited amount of time11 he simply does not stumble into a ball.

11 If his trial was infinite then MARVIN would have covered every point from every angle in his environment.

28


Light sensorWe are also concerned with the light sensor, because the sensor reads no great difference between black and white. Also shadows and random inconsistencies (such as the seams where two parts of the environment tables meet) on the floor may interfere with MARVIN’s path following skills. We hope to have ruled this out as much as possible by updating our thresholds regularly In a worst case scenario, the thresholds will get so close together that MARVIN becomes ‘blind’. It will also be hard to think of a solution for the problem that occurs when the sun starts to shine bright and the light values on some parts of the floor drastically chance.

No respect for the nestLastly MARVIN has utter respect for his eggs when he’s bringing them back, but he cannot actually take notice of eggs he has already brought back to the nest. This means he may bump them out of his nest when bringing back another egg.

ConclusionAll in all we are very confident however that MARVIN will perform well during the demonstration. It simply is not possible with the limited amount of sensors, motors and variables NQC can handle to cover all scenarios that may present themselves during the trial. We simply hope the reactive nature of the programming nature of MARVIN will make him deal with any problems he faces during the trial.

29


Appendix A

NQC program

/********************** * Sensors and Motors * **********************/#define CATCH SENSOR_1#define LIGHT SENSOR_2#define BUMP SENSOR_3#define LEFT OUT_C#define RIGHT OUT_A

/********************** * Constants * **********************/#define BOTH LEFT+RIGHT#define SENSOR_SIDE LEFT#define OTHER_SIDE RIGHT#define TPCM 10 // time per centimeter#define TPD 19 // time per 10 degree#define POWER OUT_FULL

/********************** * Global variables * **********************/int HasBall = 0;int OnPath = 0;int White = LIGHT;int Black = 780;int WhiteThreshold, BlackThreshold, Speed;

/********************** * Motor functions * **********************/

30


task run (){ while (true) { OnFor(BOTH, Speed*10); Wait(10-Speed); }}#define forward(cm, speed) stop run; Speed = speed; Fwd(BOTH); start run; Wait(cm*TPCM*(9/10+1/speed)); stop run; Float(BOTH);#define reverse(cm, speed) stop run; Speed = speed; Rev(BOTH); start run; Wait(cm*TPCM*(9/10+1/speed)); stop run; Float(BOTH);#define turn(dir, d) stop run; Rev(dir); Fwd(BOTH-dir); On(BOTH); Wait(d*TPD/10); Float(BOTH);

/********************** * Main task - will be called automatically. **********************/task main(){ init(); start checkBall; start checkLight; start checkBumper; start wander;}

/********************** * Initializes the sensors and the power of the engines. **********************/sub init(){ // The light sensor is set to RAW mode, because that way we will get a // greater variety of values. SetSensorType(LIGHT, SENSOR_TYPE_LIGHT); SetSensorMode(LIGHT, SENSOR_MODE_RAW);

// The sensor that will detect whether we have a ball or not. BOOL mode // probably suffice. SetSensorType(CATCH, SENSOR_TYPE_TOUCH); SetSensorMode(CATCH, SENSOR_MODE_BOOL);

// The touch/bump sensor can be set to BOOL mode, because we don't really // care how much it is pressed and because the events we are interested in // (collisions) will be hard enough to detect in BOOL mode. SetSensorType(BUMP, SENSOR_TYPE_TOUCH); SetSensorMode(BUMP, SENSOR_MODE_BOOL);

SetPower(BOTH, POWER); // Initialize the motors to perform at a set power. CreateDatalog(100);}

/********************** * Makes MARVIN wander around the arena aimlessly **********************/task wander (){ start checkBumper; while (true) { forward(Random(5)*10, 10); // Moves 0/10/.../40/50 cm

// A chance of 1/10 that MARVIN will move left and a similar chance for right. if (Random(9) == 0) { turn(LEFT, Random(100)+50); } else if (Random(8) == 0) { turn (RIGHT, Random(100)+50); } }}

/********************** * This task checks if a ball is caught and will make MARVIN * act accordingly. **********************/task checkBall (){ until (CATCH); stop wander;

31


Off(BOTH); HasBall = 1; turn(LEFT, 150); // high chance of going to the path. start wander;}

/********************** * Makes MARVIN react to obstacles. **********************/task checkBumper (){ while (true) { if (BUMP) { if (OnPath == 0) { stop wander; stop run; reverse(8, 4); // turn to right to make the sensor stay near the middle // when following a wall. turn(OTHER_SIDE, (Random(2)+1)*15); // 15/30/45 degrees start wander; } // MARVIN either hit a wall (which means that he is probably in the safe haven) // or he hit an obstacle that was near the path. else { stop run; reverse(7, 4); checkSafeHaven(); // if MARVIN is in fact on the safe haven, the task will be restarted here. // It was an obstacle and MARVIN should avoid it to his none-sensorside, // because that is the most likely direction that will keep him on the // path and away from the obstacle. turn(OTHER_SIDE, 45); Speed = 5; Fwd(BOTH); start run; } } }}

/********************** * Here MARVIN checks if he is on the safe haven. **********************/sub checkSafeHaven (){ int i = 0; // Makes MARVIN turn a full circle. If he encountered any white, // the black spot he's standing on is not very big and apparantly // not the safe haven. while (LIGHT > WhiteThreshold && i < 36) { turn (SENSOR_SIDE, 10); i++; } Off(BOTH); // If the loop is terminated because of the counter, MARVIN is in // the safe haven. He will now release his ball and try to find // some more. if (i >= 36) { releaseBall(); }}

/********************** * Makes MARVIN release his ball and start over. **********************/void releaseBall (){ reverse(40, OUT_FULL); HasBall = 0; turn(LEFT, 170); stop followPath; stop checkBumper; OnPath = 0;

32


start checkBall; start wander;}

/********************** * This task continuously collects the average light values * of the world and updates the thresholds for black and white. * It will also trigger MARVIN's followPath behaviour when * certain conditions are met. * * The averages and thresholds will be calculated out of the * latest ten readings for that floor color. This way, new values * will always have an impact on their averages. **********************/task checkLight (){ while (true) { // We are either entering or leaving a sunny area. This means // that our previous values are useless now, so we have to make // new ones. if (LIGHT < WhiteThreshold-150 || LIGHT > BlackThreshold+150) { if (OnPath == 0) { White = LIGHT; WhiteThreshold = White + 30; Black = White + 80; BlackThreshold = Black - 30; } else { Black = LIGHT; BlackThreshold = Black - 30; White = Black - 80; BlackThreshold = White + 30; } } // This if-statement will make sure that light values // will go into the right variable. else if (LIGHT < WhiteThreshold || (OnPath == 0 && LIGHT < BlackThreshold)) { White = (White*9+LIGHT)/10; WhiteThreshold = White + (Black-White)/3; AddToDatalog(WhiteThreshold); } else { Black = (Black*9+LIGHT)/10; BlackThreshold = Black - (Black-White)/3; AddToDatalog(BlackThreshold); // If MARVIN has a ball, he should be searching // for a path if he isn't already on one. If we're // in this branch of the conditional, we are on a // black field, so the path is apparently found. if (HasBall == 1 && OnPath == 0) { start followPath; } } }}

/********************** * Makes MARVIN follow a dark path. **********************/task followPath (){ stop wander; stop run; Off(BOTH); OnPath = 1;

Speed = 5; Fwd(BOTH); start run; // makes MARVIN run at speed 5.

while (LIGHT > WhiteThreshold) // While the floor is not white { // Limp // Makes MARVIN slower at the sensorside so that he will most likely go off the path // at the left side. This keeps MARVIN at the middle of the path (in general) and // makes avoiding obstacles easier. if (Random(8) == 0) {

33


Float(SENSOR_SIDE); Wait(10); On(SENSOR_SIDE); } } stop run; Off(BOTH);

recoverPath();}

/********************** * MARVIN went off the path and has to recover it. **********************/sub recoverPath (){ int i = 1; // This will make MARVIN turn to his left and right further // and further until he finds the path back or almost makes an // 180 degree turn, meaning he didn't really find the path back. until (LIGHT > BlackThreshold || i >= 35) { // Go a little bit back on occasion, because that makes finding // the path slightly easier. if (i % 5 == 0) { reverse(2, 4); } // Start by turning to the none-sensorside, because due to // the limping, it has a better chance. if (i % 2 == 1) { turn(OTHER_SIDE, i*10); } else { turn(SENSOR_SIDE, i*10); } i++; } // The loop was terminated because the counter reached 35 and not // because the path was found, so MARVIN should go back to wandering // until he finds the path back. if (i >= 35) { OnPath = 0; // We're off the path. start wander; } // The loop was terminated because MARVIN refound the path and he // should now continue to follow it. else { start followPath; }}

34

the report in ms word (.doc) (3mb)

Documents

robot marvin

small marvin

creation of marvin

suspected jordi

working jordi

jordi simple

arvind snickers

ships robot