McGill Department of Electrical & Computer Engineering

P a g e |1

ECSE-211: Design principles & methods

Team 18: Project Documentation

Team18

RoyBreidi AlexanderHughSam PayomMeshgin PaulSticea

April8,2011

P a g e |2

Table of Contents
1. Requirements 1.1.0 Capabilities 1.1.1 Purpose 1.1.2 Scope 1.1.3 Constraints 1.1.4 User Functions 1.1.5 Operating Environment 1.1.6 Performance 1.2.0 Compatibility 1.2.1 Component Reuse 1.2.2 Compatibility with third part products 2.Constraints 2.1 Environmental Issuer 2.2 Hardware Constraints 2.3 Software Constraints 2.4 Availability of Resources 2.5 Budget 3.Capabilities 3.1 Team Members 3.2 Capabilities 3.3 Possible Application Areas 3.4 Availability 4. System description 4.1 System Model 4.2 Hardware Available and Capabilities 4.3 Software Available and Capabilities 4.4 Compatibility 4.5 Reusability 4.6 Structures 4.7 Methodologies 4.8 Tools Appendix A: Gantt Charts Appendix B: Budget breakdown Appendix C: Mechanical and Physical Structure Appendix D: Software Development Appendix E: Testing Document Glossary of Terms References

P a g e |3

1. Requirements
1.1.0 CAPABILITIES 1.1.1 PURPOSE The purpose of this project is to design an autonomous machine capable of navigating within an enclosed maze. The maze will contain Styrofoam blocks that need to be gathered and stacked at a given position. There will also be obstacles that the robot needs to avoid while completing its task. By autonomous we mean that the robot should be able to localize itself inside the maze and navigate to wanted locations without assistance from the user. The robot is expected to circumvent obstacles and avoid collisions with the wall. The Styrofoam blocks should be piled into a single stable structure at a specific location. 1.1.2 SCOPE The size of the maze will be 12x12 feet and will be subdivided into squares of 30.48cm of length. The squares are separated by black lines of 7mm in thickness. The height of the walls around the maze is 7.625 inches. The size of one Styrofoam block is 2x2x4 inches. The size of one cinderblock is 7.625x7.625x15.625 inches. The competition will consist of 3 independent rounds. All rounds involve the same task of building the tallest stable structure possible. Rounds 1 and 2 will are similar in terms of the evaluation method while the evaluation in round 3 is based on a score calculated from the height of the structure and the time to build. Each attempt will have a maximum duration of 10 minutes. The final product is a oneshot operation. 1.1.3 CONSTRAINTS The final product must be composed of at most 3 Lego Mindstorm NXT Kits and any additional components should be approved in advance by the client. Also, The robot must be programmed using Java. The client has imposed a time deadline on the design, it should be completed by Wednesday April 6th 2011.The design process will be spread over a period of 6.5 weeks, over which no more than 234 manhours are allocated for the purpose of this project being a team of 4 people.

P a g e |4

There have been specifications on the size but none on the weight. The robot should be made in a way such that the center is located within the corner grid square. This means that the robots center should be at most 30 cm from its farthest point on the robot. The bricks are also powered by 6 AA batteries each. We must ensure that the robot is able to run for the 10 minutes required for the final competition without running out of battery. For more details on the constraints, please refer to section 2. 1.1.4 USER FUNCTIONS The user is allowed to make changes to the device at any time outside of a run. There will be an accessible menu on the NXT brick screen in order to start the robot and pair it up, using Bluetooth. However, the user is not allowed to interfere with the robots operation after it receives its destination from the main computer using Bluetooth. If the robot is using more than 1 NXT brick, they should be all started, and then programs running on them will connect to each other and take over futher operations. 1.1.5 OPERATING ENVIRONMENT The competition will be held on the second floor in the Lorne M. Trottier building. The robot will operate on a 12x12 foot flat bright wooden surface subdivided into gridlines of 30.48 cm apart. When the maze is setup, appending the 4x4 tiles might lead to cracks varying the gridline thickness. Also at some places, the color of the gridline is washed out which might affect the localization of the robot. The ambient light might change based on the time of day or the location of the maze which should be taken into account when implementing the light sensor. Also we should take into consideration the presence of spectators that could falsify the readings taken by the light sensors, because of their shadows. There is likely going to be a lot of sound at competition time but it is not expected to affect the operation of the robot. Temperature will be very close to room temperature since the competition is held indoors and thus there is no worry concerning having a different grip of the wheels than the one tested in the labs. . 1.1.6 PERFORMANCE The robot is supposed to operate for at least for the duration of 1 round (10min). It will have to travel inside the maze until it achieves its goal. The robot must react relatively fast to commands because of time constraints, it cannot go over 10 min per single round. (Also refer to section 1.1.2 and 1.1.3) 1.2.0 COMPATIBILITY 1.2.1 COMPONENT REUSE Component reuse from the labs is encouraged while reuse from external sources requires proof of authorization. All the software components that were programmed for basic tasks during the R&D labs such as filtering and odometry can be reused for this project.

P a g e |5

The system will have to interface with an IDE such as Eclipse. It will have to implement Bluetooth technology to communicate during both the design and the competition phase.

1.2.2 COMPATIBILITY WITH THIRD PART PRODUCTS

P a g e |6

2. Constraints
2.1 ENVIRONMENTAL ISSUES Refer to section 1.1.5 Operating Environment. 2.2 HARDWARE CONSTRAINTS The autonomous machine will be assembled using components from three mindstorm kits which is provided with 1 NXT Brick. Any other material must be approved by the client. The NXT brick is comprised of: 1 USB 2.0 port, to upload the software. 3 output ports, to connect the servo motors to the brick. 4 input ports, to connect the sensors to the brick. 4 sensors (touch, light, ultra sonic, sound) 3 interactive servo motors. Lego components come with predetermined shapes and lengths and it is sometimes hard if not impossible to implement any imagined design. One unit in lego is 9 mm (from hole to hole). And the included parts make angles of a minimum of 45 degrees, so it is also hard to make solid structures with angles less than 45 degrees. The provided axes (that fit inside the motors) are bendable and might bend under heavy weight. The NXT brick uses 6AA batteries, supplying power to the sensor and the servo motors which might have different behaviour relative to the remaining battery power. If we use more than one brick, and choose to communicate through an RJ12 cable, we should reserve port #4 on the NXTs for this action since it is the only capable of establishing an RS485 connection. This is a list of the hardware specifications of the NXT brick (taken from the lego website):

32bit ARM7 microcontroller 256 Kbytes FLASH, 64 Kbytes RAM 8bit AVR microcontroller 4 Kbytes FLASH, 512 Byte RAM Bluetooth wireless communication (Bluetooth Class II V2.0 compliant) USB full speed port (12 Mbit/s) 4 input ports, 6wire cable digital platform (One port includes a IEC 61158 Type 4/EN 50 170 compliant expansion port for future use) 3 output ports, 6wire cable digital platform 100 x 64 pixel LCD graphical display Loudspeaker 8 kHz sound quality. Sound channel with 8bit resolution and 216

P a g e |7

KHz sample rate. Power source: 6 AA batteries Three servo motors A touch sensor An ultrasound sensor A sound sensor A light sensor

2.3 SOFTWARE CONSTRAINTS Since we are using LeJOS (Lego Java Operating System), all code must be written in java using the classes that come with the Mindstorm kits and some already available java classes such as the Math class. The NXT brick features a powerful 32bit ARM7 microprocessor, a 256kbytes Flash memory and a 64kbytes RAM. It also has a support for Bluetooth and RS485. After receiving the position at which the structure must be built, the software should be completely autonomous, only input used being the one from the sensors.The software used allows us to program and control the different servo motors and the multiple sensors. Also, the number of threads should be kept smaller than a determined threshold so that it does not affect the performance of the robot. 2.4 AVAILABILITY OF RESOURCES There will be at least one weekly meeting each Wednesday from 9:30 to 11:30. Any other supplemental necessary meeting can be accommodated on Monday or Friday morning during the same time. Outside of the meeting times, each team member can work individually on different parts of the project or documentation assigned by the team manager. When different intersecting parts of the projects need to be connected or integrated into the design, all concerned team members should be present in order to quickly make their fixes or adaptations in case of failure. The main critical path task is having the structure of the robot ready in order to be able to integrate and test the software on it. Please refer to section 3.4 for more detailed information on team availability. 2.5 BUDGET Concerning the time budget, each team member being expected to work for an average of 9hrs/week, this will sum up to a maximum of 250 hours. This total time will be divided for the different tasks as specified in the gantt chart (Appendix A).The project will be completed by April 6th 2011, but we expect to have a functional robot by April 23rd 2011, so the last two weeks will be dedicated to testing and optimization of the software and hardware components. Other than the time budget, we expect to have spendings on batteries (max40$) and a color poster (max 40$). The funding for these items will come from the team members.

P a g e |8

3. Capabilities
3.1 TEAM MEMBERS
Name Roy Breidi Paul Sticea

McGill Email

roy.breidi

paul.sticea

Alexander Hugh Sam

Alexander.hughsam

Payom Meshgin

payom.meshgin

3.2 CAPABILITIES The following table underlines the team members capabilities as well as their interest in all of the different fields related to the project. (All values are over 10)

Roy

Paul

Alexander Payom

Experience Interest 4 5 4 5 9 9 5 4 8 8 5 4 5 6 8 10 6 5 6 6 3 5 4 8 5 5 3 6 4 5 4 5 3 5 6 6 4 2 4 4

P a g e |9

Electrical

Mechanical

Experience Interest

Software

Experience Interest

Documentation

Experience Interest

Management

Experience Interest

3.3 POSSIBLE APPLICATION AREAS We had a rough subdivision of tasks: Roy will be responsible for Localization, PC Communication and interbrick communication, Odometry with its correction. Payom will be responsible for Navigation, block detection and obstacle detection. Paul will be responsible for the overall strategy including the obstacle avoidance. Alex will be responsible for the physical structure of the robot and the mechanics. Since we are short staffed, we will all be working on parts of the documentation. 3.4 AVAILABILITY Weekly Availability: A weekly meeting will be held on Wednesdays from 9:00 am to 11:30am where all the team members will be present. This does not prevent other smaller sessions to occur during each week. Every two weeks, two of the members have an Electric Circuits quiz and may not be present on the meetings.

P a g e |10

P a g e |11

4.System Document
4.1 SYSTEM MODEL The robot should be able to perform some basic functions like the following: Localization: The robot will be placed in any orientation on any of the bottom corners. It will first be able to localize and align itself on the first grid intersection. Navigation: The robot should be able to navigate accurately inside the maze according to a certain stategy to find blocks and avoid obstacles. Object detection: The robot has to differentiate the blocks that should be picked up from the obstacles (bricks) so it doesnt crash into them. Objects Stacking: The robot must pick up the blocks and stack them correctly into our cage until it reaches the dropoff area. Object Delivery The robot should be able to get the pallets to the one by one foot dropoff area and drop them off correctly stacked within the 10 minutes constraint. Obstacle Avoidance: The robot should be able to accomplish the previous tasks while avoiding any obstacles on its path. Communication Receving the information from the server via Bluetooth. Using two NXTS they should be able to communicate with each other, one being the master and the other the slave. Below is a preliminary Class diagram summarizing the basic functions on each NXT:

P a g e |12

4.2 HARDWARE AVAILABLE AND CAPABILITIES Refer to 2.2 for the hardware constraints. The major electromechanical constraint that we have would be the limited power given by the batteries. This means that when the batteries have been used, the overall system performance will also degrade. The NXT Block is a 48 MHz processor and has a maximum of 256 KB of FLASH memory, and contains 64 KB of RAM. It also uses 32bit calculations, so every double will be converted to float. 4.3 SOFTWARE AVAILABLE AND CAPABILITIES Refer to 2.3 for the software constraints. Eclipse is one of the major tools that we use to program the robot. It is preferred to other similar software, since Eclipse has a capability to function with LEJOS, which is needed to actually realize this project. Eclipse also has a built in error detection, similar to Microsoft Words spelling & grammar detection, where it could detect our syntactical mistakes thus making the development process more fluid and efficient. Java is the programming language of choice, since we already use it in a pre requisite for this course, COMP202. We are already familiar with this language, so it is easier to adapt to all the different complications we could have when using the Lejos components.

P a g e |13

4.4 COMPATIBILITY The lego components we have in our kits have certain requirements, since you can only attach certain pieces in a certain way, and cannot put any piece you want however you want. We have to use a 32bit Java compiler, since mentioned above, the NXT brick processor works with 32bit codes only. Bluetooth will be a third party system that we will use to give our robot the coordinates to go to. During the first six weeks of class, we have developed a lot of different code that we will be using for this project, like the navigator class, the odometry class, the localization class and the Bluetooth class. These classes should work in any environment that we could possibly face during this project, so they do not bring any constraints to the making of our robot. We will not be using the mechanical designs we have used in our previous lab, since we will be using two NXT bricks, therefore we are going to design our own machine. 4.5 REUSABILITY Refer to section 1.2 4.6 STRUCTURES To make sure the Styrofoam blocks will be detected by the light sensor and will be gripped in the right direction by the gripping mechanism, we will use a Y shaped structure in front of the robot to serve as a funnel to place the block in a good position. We are going to use a cage structure to contain all the blocks that we will be picking up and it will also prevent from the stack of styrofoam blocks to fall. We have decided on this structure, since it will be easier, safer and faster than taking only one block at a time and piling them up at the drop zone. Furthermore, there will be a lift that will be performing two functions in our block manipulation. At first, we wanted to use a lift that will slide under the blocks and we would then proceed to lift the block up using a lifting mechanism, but we soon realized that sliding under the block is a very difficult task to do. Instead, we built a gripping mechanism that will hold the block in place, while the lifting mechanism, will lift it. For the lifting mechanism, we opted to use fish wire, since it is very solid and will be strong enough to lift the gripper and the Styrofoam block. The gripper will be put on a railing system, which will aid the fishing wire, which is attached to a motor, to lift it up consistently, and without any wobbling. Two NXT bricks will be used to compensate for the lack of input and output ports. They will be linked using a RJ12 wire to be able to communicate with each other and without using Bluetooth, since we expect the wireless connection to be unreliable. Our software structure will be only using TimerListener instead of Threads, since we learned from the labs that threads are less reliable when it comes to synchronization and timing. Every sensor will be polled inside its own thread (timerListener) so that measurements are taken at regular precise intervals.

P a g e |14

4.7 METHODOLOGIES Refer to the Structures paragraph above. 4.8 TOOLS Eclipse Advantages: Refer to section 3. Disadvantages: Large application size. Windows 7 Advantages: Availability in DPM lab and on team members laptops. Extensive documentation and support available on the web in case of malfunction. Disadvantages: Gantt Project Advantages: Makes schedule tracking and task division easier to visualize. Shows dependencies between tasks. Disadvantages: Doesnt focus on the relative sizes of the work elements LEGO Digital Designer Advantages: Gives a very realistic representation of the model. Disadvantages:Unintuitive user interface which makes the model design time consuming DropBox (file sharing) Advantages: Easy free intuitive sharing. Has a large capacity Disadvantages:Not reliable when tracking changes and versioning of source code. Google Groups (internal communication) Advantages: Easy to organize team discussions. Disadvantages: Cannot replace meetings. Winmerge: Advantages: Easy to compare and merge files Disadvantages: ObjectAid plugin for eclipse: Advantages: Automatically generates a class diagram from the existing code Disadvantage: Hard to customize sometimes. JautoDoc plugin for eclipse: Advantages: Automatically generates javadoc for the code Disadvantage: Sometimes overgenerates useless descriptions

P a g e |15

Appendix A: Gantt Charts

The following Gantt charts show the evolution of the development process over the project timespan: Gantt Chart for week 2:

Gantt Chart for week 4:

P a g e |16

Gantt Chart for week 6:

P a g e |17

Final Gantt Chart:

P a g e |18

Appendix B: Budget breakdown

Being 4 people in our team instead of 6, we had the budget of the other teams. Every team member had a budget of 9 hours per person per week. The project development had a timespan of 6 weeks plus 3 days of the 7th week which was considered as half a week budgetwise. So the total budget would sum up to 9 x 6.5 x 4 = 234 hours. Later in the development process, our team got very close to the budget limit and our robot required more testing. So we asked the client(Prof. Ferrie) for a budget increase and he willingly granted our team 30 additional manhours considering it as a good investment. Below is a table summarizing our time budget division over the span of the project:
Planning and Generating Physical Code Team Testing Total Documentation Design Implementation Meetings 4 1 1 0 0 6 4 1 2 0 0 7 4 0.5 0.5 0 0 5 4 0 0 0 0 4 2 2 1 3 1 9 1 3 5 9 1 0 10 0 0 11 1 0 2 4 0.5 7.5 1 1 3 4 2 11 1 1 5 2 9 1 0 9 0 0.5 10.5 2 0.5 3 6 1 12.5 1 1 1 3 2 8 1 0 3 3 1 8 1 3 3 0 0.5 7.5 1 0.5 3 2 2 8.5 1 1 1 2 4 9 1 2 4 3 10 1 6 1 0 0 8 0 0 0 5 5 10 1 1 1 3 5 11 1 1 0.5 4 4 10.5 1 7 0.5 0 0.5 9 1 0.5 0 4 5 10.5 0 0 0 0 1 0 9.5 0 0 0 0 0 2.5 3 0 4 9 10 1 9 12.5 13 10.5 13

Week 1 Feb 15 Week 2 Feb 28

Week 3 March 7 Week 4 March 14

Week 5 March 21: Week 6 March 28:

Roy Paul Alex Payom Roy Paul Alex Payom Roy Paul Alex Payom Roy Paul Alex Payom Roy Paul Alex Payom Roy Paul Alex Payom Roy Paul Alex Payom

Week 7 (3 days) April 4:

P a g e |19

The total number of hours used was 260.5 which represents 98.7% of our total budget Below is a graph generated from the above data (excluding week 7).

C1

C2

P a g e |20

Appendix C: Mechanical and Physical Structure

Knowing that we were handicapped and had two members less than the other teams, we knew that we should use the least amount of time possible and be as effective as we can be. With that said, this is why we went for a modular design, so that each component can be developed in parallel with each other and so more time can be saved. The gripping mechanism: Two different designs were initially proposed for the pickup block system: a wedge that would go under the block and would be lifted up or a clawlike mechanism, which would grab the block by its side and will then be liftedup. After our first presentation, we were told that no pins would be placed under the Styrofoam blocks. This news meant the end for the wedge and the start of the claw mechanism. The initial claw mechanism was very closely inspired by a product seen from the NXT program website (See figure C1). However, it was immediately modified since it was not strong enough to grip on the block. The second revision compromised us changing the claws for 2 pair of rails. This change demonstrated significant improvement. Using the NXJ console, we were able to see how well it was able to hold on to the blocks and it was a first success. Nonetheless, after a few more trials, we figured that it did not have enough friction on the Styrofoam blocks. The rubber pieces found in the NXT Minstorm kit were added to each rail to provide the needed friction and also maximize the surface area for better gripping. A flaw was eventually found, since the bottom rail would grip onto one block, while the upper rail would get the second block. This would lead to less pressure when gripping on the blocks. Another modification had to be made to compensate for this flaw. The end part of the upper rail was remove, so that only the lower part would be able to grip. Yet again, a new problem was to be found: there were cased where the gripping wasnt aligned correctly (the gripper was not straight along the frame). This revision introduced a movable end gripper (See figure C2) and the alignment problem was finally corrected.

P a g e |21

We soon found out that the upper rail had become unnecessary and added weight to our gripper, so we took it out in favour for a gripper which was lighter and had better manoeuvrability. The last revision happened at the very last week before the competition. We realised that sometimes, blocks could hit and get stuck under the cage. This problem was solved buy imputing an Lshaped block on the left rail of the gripper (See figure C3). This would make sure that no block will get stuck under the cage, and was also used to align the two blocks. The base: The initial design used for the base had no real thought put into it. The team decided to go with a similar structure to the Stronger US Patbot and just added another brick on top of it. Multiple problems have been observed, once the design was done. The major flaw of this base was that it had absolutely no place where it could put the gripping mechanism to effectively work. A second design was made a day later, but was quickly demolished, since it was as worst as the previous one, if not even worst since its structure was way more unstable.This design was very high, but used four wheels to travel (2 by motors and 2 that were installed in the back). The next design was thought of after seeing multiple teams using this structure. This time, the NXT bricks were on their side and had to be attached to their respective motor. The all was then attached to other pieces to solidify the structure. We found out that the wheels axes were bending and wanted to add something to prevent this from happening. The team thought it would be a good idea to modify the base to make it more stable to help the tires from not bending anymore. The new and final base design introduced a better structure to the whole robot, while also having a better railing system. This new design also introduces some added gear to prevent the tires from bending and a fixed rod from the tires, which are also used for the same purpose (See figure C4 and C 5). The cage:

P a g e |22

Even though we were at a two man disadvantage, we still aimed for the top, and it was no surprise that we needed a cage to do this. The cage helped us keep the blocks from falling when the stack was higher than two. The initial design had a cage that was really high and had a very tight space for the blocks to manoeuver (See figure C6). This led to some inconsistencies, which is not acceptable in this type of competition. Also, the cage was useless if we did not pickup more than three blocks, which started to become dangerous, since the stack of three could have falled. The next design was the opposite: the structure was very low and large. This also led to problems, since we could not pickup more than four blocks (which at the time thought it would be easy to accomplish) and the blocks had a high chances of falling due to the spacing inside the cage. Obviously, a new cage had to be made. This one was the best of both worlds. It was not too high, nor too short, and had the perfect amount of manoeuvrability, without giving the blocks so much space. After testing, we concluded that this would be the final design of the cage (See figure C7). The railing system: The railing system was one of the easiest mechanical parts of the whole robot to do. Inspired by another product from the NXT Programs website (See figure C7), team Maestro successfully installed a railing system which included the gripping mechanism. Unfortunately, it seemed a bit too fragile, and was solidified when the team rebuilt the base (See figure C8). The lifting mechanism: The lifting mechanism is the only part which went through very minor changes. For the lifting part itself, the team opted to go for a fishing wire string, since it is known to be very strong, which we need to be able to liftup the whole gripping mechanism plus a few blocks. From the initial design (see figure C9), only one gear and one rim wheel have been added to the lifter. These changes helped maintain the fishing wire in place (See figure C10). The door: Initially, the team wanted to use a sort of platform to keep the Styrofoam blocks in the cage, without falling out. The first design was too heavy to support the cage and it also interfered with the ascension of the gripper.

P a g e |23

The final design was made when we made the first cage: Instead of using a platform, the team opted to go with a door instead. This provided more stability than the platform and was more easily installed. We did not need a platform anymore, since we decided to lift the gripping mechanism during the whole time it had pickedup a block. The door was used to prevent the blocks from falling up front (see figure C11) The funnel: The funnel is the front part of the robot that serves to guide the block in position for grabbing. Initially, we made the funnel very long so it would have a very good reach on Styrofoam blocks (See figure C12). However, we found out it might not be a good idea to make it long, since we increased our chances into hitting a cinder block, which would harshly diminish our chances of getting meeting the requirements. Thus, we still kept our funnel and only made it shorter (See figure C13). In conclusion, many modifications have been made to finally have a winning robot, or so we thought. In the end, these multiple changes might have been our downfall, considering it took plenty of our testing time. However, the whole team was very happy with the final structure of the robot, since it was very solid and also very clean, compared to most of the other competing teams.

P a g e |24

NXTPort Allocation:

P a g e |25

Appendix D: Software Development

Overall strategy After doing the initial localisation and travelling to the center of the first square, our robot was moving across the field by travelling from the center of the current square to the center of another adjacent square. The class Strategy was responsible with finding a viable path for the robot to follow, using a modified version of lee algorithm, which will be described later. After each displacement the robot was doing a 180 degrees sweep (90 towards right and 90 towards left) in order to detect obstacles and foam blocks that it can pick up. The squares containing the position of the detected obstacles was recorded in a matrix. Also the position at which foam blocks were detected was recorded, and after detecting the surrounding obstacles, a decision was made weather it is safe for the robot to try picking the detected blocks. In order to pick a block the robot was advancing towards it until the light sensor detects it and starts the lifting mechanism or until a distance of 25 cm was covered. After picking up a block, the robot returned to the center of the square and continued its path. When the number of blocks was reaching a threshold, the robot was not looking for any foam block any more, but simply travel safely to the destination. In case an obstacle was detected on the way, the lee algorithm(see below) was asked to recalculate a new path. At the destination, the robot deposed the blocks, opened the cage door and backed up. Improved Lee algorithm The Lee Algorithm[1] finds the shortest path between two points in a 2dimensional matrix, by avoiding given obstacles. Our version of the algorithm was using 3 matrices: the first to store the obstacles, the second to store visited squares, the third to run the Lee algorithm. The Obstacle matrix was updated whenever an obstacle was detected, and the Visited matrix was updated every time the robot was done visiting a square. In case more than one path of minimal length existed, the lee() function was returning the one that minimizes the number of turns and chooses unvisited squares instead of visited ones. As a safety measure, all obstacles were erased from the obstacle matrix in case no path to the destination was found, then the robot was looking again for adjacent obstacles and recalculating the path. If the destination is reached with insufficient blocks, the algorithm was generating up to 4 additional paths that the robot can follow starting from the destination point.

P a g e |26

Below is the stepbystep procedures used in the lee algorithm:

1) Initialization - Select start point, mark with 1 - i := 1 2) Wave expansion - REPEAT - Mark all unlabeled neighbors of points marked with i with i+1 - i := i+1 UNTIL ((target reached) or (no points can be marked)) 3) Backtrace - go to the target point REPEAT - go to next node that has a lower mark than the actual node - add this node to path UNTIL (start point reached) 4) Clearance - Block the path for future wirings - Delete all marks

Graphical representation of the algorithm:

P a g e |27

Software Architecture: Below are representation of our class diagrams on both NXTS : Master:

Slave:

P a g e |28

Appendix E: Testing Document

Test 1: General tests with the ultrasonic sensor Date: March 7 to 10 Conditions: A test robot is placed on an open field in front of a foam block which is inclined at different angles from the robot and at different distances from the robot. The robot then moves towards the block at a constant speed while recording the raw distance values read from the ultrasonic sensor. Results: Block facing the robot (~0 degrees)

Block at 45 degrees with respect to the robot:

P a g e |29

Block at 15 degrees with repect to the robot:

Through these initial experiments, it was determined that the ultrasonic sensor is able to receive a ping from a block provided the block surface is facing the robot (to within 10 degrees). This information revealed that in many cases, the sensor is incapable a single value showing the existence of a block. Thus no filter can help the robot if its line of sight is not perpendicular to the surface of the block. On the other hand, if the line of sight of the sensor IS perpendicular to the surface of the block, then the values returned by the sensor are nearly flawless. TEST 1: Light sensorbased gridline detection When: March 5, 2011

P a g e |30

Conditions: The test robot is placed on an open field, with its centre of rotation on an intersection. It is programmed to rotate 360 degrees while continuously printing the value sent by the sensor after a simple differential filter is applied. Results:

The robot observes a line once the absolute value of the data from the differential filter is very high. Other comments: More tests were taken using this differential filter on the robot. The robot, for instance is set to drive over a set of lines (one of which is actually a crack between the 4x4 square tiles) at different speeds and releases a sound cue when the sensor detects a crossed line. The tests were very successful.

P a g e |31

TEST 2: Light sensor based gridline detection When: March 14, 2011 Conditions: The test robot is placed on an open field, with its centre of rotation on an intersection. It is programmed to rotate 360 degrees while continuously printing the raw value sent by the sensor to the computer console. Results:

As expected, as the sensor begins to sweep across a line, the value returned be the sensor increases significantly. Conversely, when the sensor sweeps out of a line, the value decreases considerably. Since the values returned were jittering as the robot was running, a running average filter was applied to the values. Furthermore, due to the unknown lighting conditions on the field during the competition, an additional differential filter was applied to the values.

P a g e |32

After some more testing, it was observed that the robot definitely crosses a line once the value returned from the average and differential filters surpasses 10. Other comments (after testing): We have implemented the filter above to our actual robot and have confirmed its effectiveness. We found that there was no noticeable change in the detection rate of the robot. Eventually, it was decided that the localizing sensor will operate with a differential filter and without a running average filter. TEST 3: Light sensor based block detection When: March 14, 2011 Conditions: The test robot is placed on an open field witth a foam block directly in front of it (i.e. the surface of the foam block is perpendicular to the line of sight of the light sensor). The robot is programmed to move forward at a constant speed while continuously printing the raw value sent by the sensor to the computer console. Once a block sucessfully contacts the sensor, the test ends. Another similar test is repeated, but the block is placed at a 45 degree angle such that the sensor never directly touches the sensor (which simulates a block getting stuck on the frame). Once a block contacts the robot, the test ends. Results:

P a g e |33

P a g e |34

The graph above shows the difference between the values read by the ultrasonic sensor when a block is successfully entering the frame of the robot and when a block gets stuck on the frame. As the approches the block, the light sensor returns a gradually increasing value. When the blocks surface completely covers the light sensor, the value returned by the sensor drops substancially. However, if the block gets stuck, the sensors reading does not decrease at all (until the block is removed from the frame). The progression of the values returned by the sensor reveals interesting things about the nature of the sensor. For one, it was determined that the maximum effective operating range of the sensor (the maximum distance from which the sensors returned value can change) was about 15 cm. Other comments: We have continued with more tests, covering cases such as when the block slides along the inner edge of the frame. Once blocks have successfully been detected in a consitent manner, we finalised the filtering of the light sensor

P a g e |35

Test 5: Ultrasonic obstacle detection with median filter Date: March 14, 2011 Conditions: The test robot is placed in the middle of the field and directly in front of two cinderblocks which is facing it. The robot is set to rotate while recording the distance read from the ultrasonic sensor. In addition, a median filter is applied to the raw values given by the sensor. Results:

P a g e |36

The following section will describe some general tests made on the robot: E1: Unit Tests
# Category Description Pass/Fail Comments The block will not get stuck, unless it follows a side of the funnel exactly, but in realtime, it is almost impossible to achieve. Even though, this will be corrected in the coding. This text demonstrated that we can only support 5 blocks without making the stack fall. Note: This is before we implemented the cage to support more blocks This text demonstrated that we can only support 5 blocks without making the stack fall. Note: This is before we implemented the cage to support more blocks The tile borders are detected successfully The Ultrasonic can only detect a block when the chirps bounce directly off it, 255 is returned

Front Funnel mechanism

Manually approach a Styrofoam block in different angles to see if the block goes into a position where it can be gripped.

Conditional

Gripping mechanism

Using the NXJcontrol found in the LejosNXT folder, we were able to control the motor of the the gripping mechanism, so it can actually take a styrofoam block. Then, we manually lift up the mechanism. We repeat the previous taks until the stack of styrofoam blocks fall.

Pass

Lifting mechanism

Using the NXJcontrol found in the LejosNXT folder, we were able to control the motor of the lifting mechanism and the gripping mechanism, so it can actually take a styrofoam block and lift it. We repeat the previous taks until the stack of styrofoam blocks fall.

Pass

Light Sensor Filtering (odometry correction) Ultrasonic Sensor (block detection)

Test sensor on usual black line; on worn out lines; on line separating two 4x4 tiles; with high ambient light; with low/no ambient light;

Pass

Test the ultrasonic sensors ability to pick up pings from a block oriented at different angles (0, 22.5, 45 degrees)

FAIL

P a g e |37
otherwise

6 7 8 9 10

Odometry Odometry Correction Navigation Interbrick Communication PCBrick Communication

Testing done using a test vehicle, before the robot construction was ready Sending statuses (integers) between two bricks using the RJ12 cables Control the robot using Bluetooth and receive data (ex: measurements from sensors)

Conditional

Needs calibration Need to define and identify the status codes Need to test with similar server as in lab5

Pass Pass

E2: Integration tests

Our demo went very well, we were able to make the robot move straight in line and pick up the robots that were in his way. It did pass the demo, though we still had some difficulties when they were more than 1 block to pick up. The block sometimes gets stuck on the bottom of the cage, if the block is somewhat crooked. Thus, the gripping and lifting mechanism stop working correctly. Note: We then added a piece on each side of the gripping mechanism to straighten out the blocks.

11

Integration Testing (Demo #1)

The purpose of the demo was to show that our mechanical build was able to pick up at least one styrofoam block. This demonstration integrates a basic code of the travel to method, the gripping mechanism and the lifting mechanism

Pass

12

Cage implementation

Using the gripping and lifting mechanisms, take 3 styrofoam blocks in a row and see if everything is smooth and the blocks do not get stuck somewhere.

Fail

P a g e |38
After we added the piece to straighten out the blocks, in every case, the gripper and the lifting mechanism did not get stuck The robot was not able to pick up a block by itself consistently without human assistance (i.e. manipulating the styrofoam block to put it in position for the Ultrasonic sensor will see it) This test was done on a matrix imitating a 12x12 maze. The robot successfully avoided the obstacles and find its way to the specified destination

* Using the gripping and lifting mechanisms, take 3 styrofoam blocks in a row and see if everything is smooth and the blocks do not get stuck somewhere. *After the piece was added to the gripper Using the robot tester, make the robot sweep from 90o to 90o. If the robot finds a block, make it advance half the distance it sees and make it sweep again. Then, advance and capture the block.

Pass

13`

Styrofoam block detection

Fail

14

Integration Testing (Demo #2)

The purpose of the demo was to demonstrate the styrofoam block detection of our robot and make it pick at least one of block up and the drop it at a specified location by the client. This demo integrates the Ultrasonic Sensor, the Light Sensor, the gripping mechanism and the lifting mechanism of our robot.

Fail

Ultrasonic Sensor Localization Light Sensor Localization Path Finding code

Implementation of the Falling Edge used in laboratory 4 on our mechanized robot Make the robot make a 360 turn. Using the light localizer, it should be able to correct the odometer. And the odometer should show exactly where the robot is. Lees algorithm was implemented in our robot and was tested to see if it successfully found the path to its destination. (Software Test)

Pass Pass

15

Pass

15

Path finding Integration

The robot was given hardcoded obstacles. It had to apply the Lee algorithm to find its way through the maze.

Pass

16

Styrofoam block detection Obstacle detection initial test Odometry correction with added heading

Using the main robot, make the robot sweep from 90o to 90o. If the robot finds a block, make it advance half the distance it sees and make it sweep again. Then, advance and capture the block. Putting the robot inside a maze with 2 obstacles. The robot should find its way to the destination

17

The robot was detecting more Conditional obstacles than Pass there actually was. Process was too long. Pass Need to try a 10 minute long path

18

A relatively long path was given for the robot to follow.


correction

P a g e |39

Lee's Algorithm implementation

19

20

Identifying obstacles position and storing it into a matrix

A test program was created to verify if the algorithm was implemented correctly, by inserting values manually for the obstacle matrix and then printing the matrix on which the lee was operating and the found path Robot was programed to move around the field and using the position at which obstacles were found, update the Obstacle matrix. Bluetooth was used to print each new obstacle onto the console, and the complete matrix each 5 seconds.

Pass

Many cases were tried, including ones in which all path were blocked, and had a few problems with running into infinite loops, but that was corrected Most difficulties were encountered when implementing formula that would give the position in the matrix of the obstacle, given the current robot orientation, position and distance read by sensor

Pass

E3: System Tests System Test #1: 4/03/2011 Test: Send via Bluetooth initial location 1 with destination x:3 y:3, no obstacles, 4 surrounding blocks. Result: The robot went to destination and was able to pickup 1 block on the way. It deposited at destination. Cage did not open. The robot followed and L shaped path. Comments: The block was picked up due to the robot bumping into it and not because of block detection. System Test #2: 4/03/2011 Test: Send via Bluetooth initial location 1 with destination x:4 y:4, one obstacle, 5 surrounding blocks. Result: The robot initially avoided the obstacle, but collided with it later while sweeping next to it. This set off the odometer and failed the test. Comments: The robot should be told to avoid a larger area around a block when navigating and sweeping. Probably add surrounding points to obstacle matrix.

P a g e |40

System Test #3: 4/04/2011 Test: Send via Bluetooth initial location 2 with destination x:5 y:4, two obstacles, 8 surrounding blocks. Result: The robot avoided both obstacles and they were accurately represented in the matrix. However, right before arriving to destination Slave went off. Comments: Slave went off most probably because of batteries System Test #4: 4/04/2011 Test: Send via Bluetooth initial location 1 with destination x:5 y:4, two obstacles, 8 surrounding blocks. Result: The robot pickup 2 blocks and deposited them at the destination, off by nearly 10 cm Comments: Odometry correction should be calibrated System Test #5: 4/05/2011 Test: Send via Bluetooth initial location 3 with destination x:4 y:4, two obstacles at an angle of 45 degrees, 8 surrounding blocks. Result: The robot avoided one of the obstacles but collided with the other one. No blocks picked. Comments: Hard to see obstacle at 45 degrees. Perhaps decrease sweep speed or improve filter

P a g e |41

Glossary of Terms
Blocks: Foam blocks ( should be stacked at the destination) they might also be referred to as pallets or objects. Obstacles: Cinder blocks(should be avoided) Brick: NXT Brick Square: a 1 foot square delimited by gridlines on the maze

References
[1] C. Y. Lee "An algorithm for path connections and its applications", IRE Trans. Electron. Comput., vol. EC10, pp. 346 1961. [2] Dave Parker Claw with game controller http://www.nxtprograms.com/claw_car/steps.html [3] Dave Parker Forklift http://www.nxtprograms.com/NXT2/forklift/index.html