A Design Portfolio in Introduction to Profession l | ECE 100, Exams of Electrical and Electronics Engineering

Download A Design Portfolio in Introduction to Profession l | ECE 100 and more Exams Electrical and Electronics Engineering in PDF only on Docsity!

HandyBug: A Design Portfolio

Michael S. Condei

ECE – 100

Introduction to the Professions

Table of Contents:

• List of Tables .......................................................................
• List of Figures ......................................................................
• Acknowledgements ..............................................................
• Executive Summary.............................................................
• Problem Statement ...............................................................
• Research/Investigation.........................................................
• Alternative Solutions ............................................................
• Optimal Solution..................................................................
• Construction/Implementation ............................................
• Analysis/Testing.................................................................
• Conclusion .........................................................................
• References ..........................................................................
• IC Code Appendix .............................................................
  • Turtle.c ...................................................................
  • Test.c ......................................................................
  • Timer.c ...................................................................
  • Mintmaze.c – Solution 1 ........................................
  • Round3.c – Solution 2............................................

Acknowledgements:

There are many people that deserve recognition in regards to the final competition. I would like to thank Dr. Flueck and Sean for their help in lab. I would like to thank my teammates (present and past) for having the opportunity to work with them and benefit form their advice and know-how. I would like to tha nk my mother for helping put me through college. And finally I would like to thank my girlfriend, Alana, for being a special part of my life.

Executive Summary:

The HandyBug is the latest innovation from ECE Labs. HandyBug is a versatile, mobile, intelligent machine that can perform almost any task. HandyBug is still in a process of testing and development and should be ready for commercial release within a short period of time, depending on whether sufficient funding is provided for further development.

The new HandyBug is going to revolutionize the American household. HandyBug is the first in a series of mini, program dependent, intelligent machines that will be unleashed onto the consumer market in the course of the next few years.

HandyBug is built on a modular plastic chassis that can be altered to suit the clients’ needs. This plastic is strong, yet economical to manufacture in large quantities. Each HandyBug will be marketed as a standard design and body. Almost all the components of the robot are plastic, therefore making them easier to replace. Additional components or accessories will be marketed along with the HandyBug. A sizeable percentage of the public will no doubt feel the urge to replace the motors or the sensors of the HandyBug with higher-end components. This can be compared to the boom in the number of customized import cars that are hitting our streets today. We look to the young adults as the prime market group for accessories and other components. Versatility is the key to selling these HandyBugs.

The HandyBug can be programmed to perform almost any kind of task. It can be programmed to aid small children in learning how to walk; implemented as part of a home or commercial security system, kind of a policeman walking the beat, using a light sensor to detect changes in the room; used in law enforcement as a small mobile video camera; used to find lost keys in the back yard; the only restriction that the HandyBug has is the user’s imagination.

HandyBug uses a simple programming language known as C. This language works best with the 68HC11 8-bit processor and will not occupy much memory. The standard HandyBug will come loaded with a simple obstacle avoidance program that should allow it to maneuver on any flat surface without becoming entrapped. The true power of its versatility is that it comes with the C compiler that will allow the user to program to his/her needs.

The HandyBug has so far been tested to perform various simple tasks: use touch sensors to navigate a maze, use light sensors to follow lines, and with a combination of both tasks, the HandyBug has competed in a game of Mint-Shuffle. HandyBug could revolutionize the way people run their lives and do their work. Despite HandyBug’s early development stage, the concept is very practical and has limitless potential. More time and funding are needed to continue testing and developing this prototype to adapt to various environments and perform certain tasks within those environments.

Research/Investigation:

An optimal performance solution should include the following:

Sturdy Construction:

The HandyBug chassis should be constructed according to the original schematic in the text 1. The design team should work together on separate parts of the chassis in order to make the construction process more efficient. For example, one team member would work on the drive train while another works on the front assembly and touch bumper, leaving the third team member to work with the Interactive C software and prepare/debug the code.

Motor Command Algorithm:

The turtle.c algorithm provided in the text is a reliable motor command algorithm^2. The turtle.c code provides the basic motor commands of forward, backward, left, right and stop. These functions are written to incorporate both motors in whatever process is required; for example, the right() function consists of activating the left motor forward and the right motor backwards.

Incorporating the Touch Sensors:

The touch sensors are digital input sensors that can be attached to the Handy Board. Therefore they will only return a value of zero (false) or one (true). These touch sensors can be incorporated to help the HandyBug maneuver by sensing its surrounding (i.e. walls). The touch sensors can be incorporated by a digital value from the touch sensor port in an if statement. Based on if the value were true or false, the HandyBug can be made to maneuver in a certain direction or stop altogether.

Incorporating the Light Sensors:

The light sensors are analog input sensors that can be attached to the Handy Board. These sensors, unlike the digital sensors, can return a range of values; thus light sensors would be ideal for detecting changes in light input. Like the touch sensors, light sensors can be incorporated in if statements that govern the HandyBug’s reaction to the light value inputs. The light inputs will have to be compared to a threshold value. The threshold value can be obtained by testing the light sensors. An easy way to test the light sensors is to print the readings to the Handy Board screen^3. In order for the light value readings to be used correctly, it is crucial that the threshold reading be obtained.

(^1) F. G. Martin, Robotic Explorations: A Hands -On Introduction to Engineering , Prentice -Hall, 2001, pp. 28 - 51. (^2) F. G. Martin, Robotic Explorations: A Hands -On Introduction to Engineering , Prentice -Hall, 2001, pp. 74 - 75. (^3) F. G. Martin, Robotic Explorations: A Hands -On Introduction to Engineering , Prentice -Hall, 2001, pp. 80 - 81.

Using the Timer Function:

The timer function is part of timer.c and is given in the text 4. The timer function is an algo rithm that returns the number of seconds that have passed since it was last reset. The reset function is also part of timer.c; reset allows a floating point variable to be reset to the system time.

Using the Start Button Function:

The use of the start button on the Handy Board must also be implemented^5. Because a constraint of the competition is that the HandyBug must not start unless the controller presses the start button, a loop could be implemented at the beginning of the code in order for the HandyBug to wait for input.

All of the above-mentioned parameters must be used in the coding and in the lab in order to achieve optimal performance and to obtain satisfactory results. Each of these is an import piece in making the HandyBug perform. All of these parameters have been individually tested during previous laboratory experimentation times. All team members should have a working knowledge of all of these parameters as well.

(^4) F. G. Martin, Robotic Explorations: A Hands -On Introduction to Engineering , Prentice -Hall, 2001, pp. 94. (^5) F. G. Martin, Robotic Explorations: A Hands -On Introduction to Engineering , Prentice -Hall, 2001, pp. 417.

Optimal Solution:

The optimal solution would be based on Solutio n 1 from the Alternative Solutions. Solution 1 works well because the pucks are placed in random positions along the lines of the playing field. If Solution 2 were used, there would be a possibility that the HandyBug would miss one or more pucks depending on where it crosses the lines (perpendicular to the center-line), because of the sleep statements. The following pictures display solution 1:

The first picture shows the HandyBug leaving the start box by turning right. Once light sensors detect that the white tapeline has been crossed, then it would turn a slight left. The second picture depicts the HandyBug using a tape following algorithm to push the puck toward the middle. And the last picture depicts the HandyBug pushing the puck past the middle line. After that point the HandyBug would backup because both light sensors would sense that they are on a tapeline and the HandyBug would backup. When the rear touch sensors would be activated after backing up, the whole process would begin again. This algorithm is shown is mintmaze.c. Shown below is a pseudo code version of the program:

While loop waits for the start button to be pressed;

While loop that is iterated as long as the timer is under 90 seconds { turn right; if (both light sensors cross white tape and it isn’t oriented) turn slight left; //orients the Handy Bug if (right sensor picks up tape) //path following turn right; else if (left sensor picks up tape) //path following turn left; if (both sensors pick up tape and the HandyBug is oriented) //tests for the center line backup; if (both either rear touch bumper has been hit) //tests for the end of the line stop; } stop;

Construction/Implementation:

Many times ideas and solutions that seem optimal and reliable fail in when actually used. This was the case of the Optimal Solution, this will be explained later.

Chassis/Hardware:

A prefabricated chassis was used in this competition. There were some modifications made to improve its performance in the competition. The prefabricated chassis didn’t have a front bumper therefore one was added. A front bumper would be much more efficient in retaining pucks as the HandyBug moves down the tapeline. The light sensors were added to the bottom of the front assembly close to the surface in order to detect the changes on the playing field. The light sensors were placed far enough apart that they would be straddling the tape line if the HandyBug were placed on that line. Touch bumpers were also added to the rear of the chassis; one touch bumper on each corner. Previous times in lab the team has spent an astonishing amount of time modifying the HandyBug in order to better hold the Handy Board and keep it from sliding off the top off the chassis as the HandyBug moved. A good solution was to keep the Handy Board from moving by tying a rubber band around the chassis and the Handy Board. Shown below is a picture of the competition ready HandyBug.

Coding:

The actual solution used in the competition was Solution 2 (round3.c). Solution 2 was used because it was found somewhat more reliable than Solution 1 in testing. Solution 2 relies on calls to sleep functions to produce delays between movements of the HandyBug. This solution seems adequate in theory. But many variables

Analysis/Testing:

Lab Testing:

During lab both solutions were tested. Solution 1, the Optimal Solution, was tested but had syntax errors. After the errors had been resolved, the team noticed that the HandyBug would not turn when it would cross the first white line. Different va lues for the threshold were obtained and tested without much improvement. Solution 2 was then used as a backup. Solution 2 failed to be properly debugged and was poorly tested by the time for the final competition. The table below shows what happened as both solution codes were tested in Lab.

Solution Syntax Errors

Logic Errors

Worked as Expected

Had to be Modified

Had Syntax Errors After Modification

Had Logic Errors After Modification

Worked as Expected After Modification

Was Used for the Final Competition

1 Yes Yes No Yes No Yes No No 2 Yes Yes No Yes No Yes No Yes

The team believes that the light sensor readings might have affected the performance of both solutions. The table on the left below shows the result of modified threshold values for both solutions and the table on the right shows the average light sensor readings when the HandyBug is positioned at various angles and locations on the mint-shuffle board.

Final Competition:

The final competition was devastating for the team. Not only had the team produced a strong, reliable chassis and an almost dependable code, but also this would be the culmination of each member’s hard work of the previous three months. However, the team was forced to enter the competition with faulty code that would not be able to make use of all of the features of the HandyBug’s construction. The coding provided made the HandyBug stop as soon as it reached the first white line; this occurred in every round of the competition. In the end the HandyBug had pushed zero pucks into their opponent’s playing field. The team thinks that this might be attributed to an ill placed stop function in the coding or a poor threshold value that would not be compared to the light sensor readings. Modifications were made in between competition rounds as well; they did not yield satisfactory results. Those might be some of the possible logic errors with the code, more testing could determine if there are more.

Threshold Value Affected Performance 128 – Solution 1 No 100 – Solution 1 No 128, 128 Solution 2 No 100, 100 Solution 2 No

Light Sensor Readings On Tape > Off Tape <

The picture above shows where the HandyBug would stop during competition rounds, marked by the X. The table above shows the results of the Final Competition.

Round Pucks Pushed In Where the HandyBug Stopped Working 1 0 First White Line 2 0 First White Line 3 0 First White Line 4 0 First White Line

References:

F. G. Martin, Robotic Explorations: A Hands-On Introduction to Engineering , Prentice-Hall, 2001