Project Report. Monsters, Inc. (#11) Antonina Gorshenina Jihad El Sheikh Rabab Haider. Submission date: Friday, April 10 th, 2015

Transcription

1 AER201: Engineering Design Monsters, Inc. (#11) Antonina Gorshenina Jihad El Sheikh Rabab Haider Submission date: Friday, April 10 th, 2015 Instructors: Cameron Robertson Todd Reichert Victor Ragusila Teaching Assistant: Nikhil Sharma

2 Table of Contents Acknowledgements The Star Symbols and Abbreviations Executive Summary Design Process Introduction Summary of Design Process Requirements and Constraints Team Values Team goals Background Summary of design research Summary of motors Summary of visualization components Summary of Localization methods Conceptualization Technical Description System Level Overview of full functionality Pre-flight check list Post-fight check list Electromechanical Sub-system Primary locomotion Navigation Hopper alignment aids Turning aid Handling the ball Mounting and organization Circuits Sub-system... 16

3 Protoboards H-Bridge Circuit IR Reflectance Sensors LCD Screen Pushbuttons Switches On-board power Microcontroller Sub-system Global variables Setup Loop Navigation Hoppers Location Reset Implementation Primary Locomotion: Implementation of DC Motors Navigation: Line Detection Navigation: Failure of the Ultrasonic Sensors Electromechanical Testing Circuit Testing Microcontroller Testing Alignment: Approaching the Hoppers Electromechanical improvements Circuits/Microcontroller Improvements Alignment: Interference with the Gameboard Ball Retrieval: Developing the Gripper Release System: Developing the Arm Release System: Developing the Release Ramp Debugging Environment Using the LCD General Process for Circuits Powering the Arduino Implementation of Circuits... 33

4 Organization of Components Electromechanical Sub-system Circuit Sub-system Microcontroller Sub-system Gameplay strategy Project Management Project Schedule Electromechanical sub-system Electrical sub-system Microcontroller sub-system Division of Labour Budget Conclusion Works Cited Appendix A: The Final Design: Pluto Appendix B: Sections of the code... 43

5 Acknowledgements This project has been a rather stressful experience due to its challenging elements and constricted timelines. This is why, upon finishing it, we would like to take this opportunity to acknowledge the efforts of those who have helped Monsters, Inc. throughout the project and made it possible for us to get this far. First of all, we would like to thank Professors Victor Ragusila, Todd Reichert and Cameron Robertson for their guidance and feedback throughout the project. Secondly, we would like to give thanks to our teaching assistant, Nikhil Sharma, for following up with us every step of the way, for his frequent discussions that pushed us to look for solutions we hadn t considered before, and for his genuine enthusiasm for our project. We would also like to give special thanks to Costa for helping us with machine work and sharing his experience in regards to electromechanical structures. Lastly, we would like to thank all the teams who have made this project perhaps the most memorable experience in our lives by building worthy opponents for our Pluto and helping us to get back on our feet every time he didn't listen to us. 1 - The Star Monsters, Inc. was founded with the goal of bringing to creation a robot. It doesn t seem like anything special, but to Monsters, Inc., it was embarking on a journey of which they knew nothing about. A simple goal of building a robot that can walk, that can sense its environment, and most importantly, play connect 4. A goal that revolves around Pluto. The team consisted of three highly motivated individuals. The three founders are Antonina Gorshenina who can spring electrons into action with fearless glare, Rabab Haider who has the ability to build anything out of thin air, and Jihad El Sheikh, who has never-resting neurons that can turn the wildest dreams into realities. Together they believed in a goal, and worked tirelessly, driven by their passion, to bring Pluto into existence. Pluto might not be a planet. but he is a star in our eyes Dale Gottlieb (1T7) Figure 1: Monsters, Inc. with Pluto, full of pride after their success 1

6 2 - Symbols and Abbreviations Global playing field - The entire gameplay area consisting of both playing fields of opposing robots, connected together on a mutual board. The global playing field is divided into the two playing fields by a wooden barrier, to separate the two robots and their respective areas of play. Playing field - The half of the global playing field to which each robot will be confined during the connect four competition. The playing field is a grid of 8 by 9 squares, each 20 cm in length. Gameboard - location where balls (connect four game pieces) are deposited and put into play. Gameboard is located in the center of the global playing field on the wooden barrier, equal distances from the two sides, and accessible to opposing robots on their respective playing fields. Hoppers - localized structures made of PVC tubing which contain the ping pong balls. The central hoppers consist of three opaque plastic legs connected to a central support along the top, with a central leg of transparent plastic which holds the balls. Two of these hoppers are located within a central grid on the playing field, and can have varying position and orientation. The corner hoppers have a similar structure; they are simply missing the third support leg as they are supported by the edges of the board. Two of these hoppers are located in the back corners of the playing field. Connect four game - the traditional connect four game consists of two players taking turns putting coloured chips (black for player A, red for player B) into a common gameboard with the objective of connecting 4 of their coloured chips in a row (adjacent or diagonal). The player with the most connect 4 s wins, so naturally one would try to keep one's opponent from connecting 4 chips. The modified connect 4 game is non-turn based, where autonomous robots play for 7- minute games and try to maximize the number of balls played and connect 4 s made. Game pieces or balls - the adaptation of the traditional connect four game pieces are standard matte black and white ping pong balls, of 4±1cm diameter. These are located in the four hoppers on the playing field, from which the robots must retrieve them. Center-line rule - Robots are not allowed to interfere with one another at the gameboard, and so no part of the robot may cross the centerline of the global playing field or be positioned in such a way that a ball cannot be easily deposited into any column of the gameboard by a human hand. Please refer to page 12 of AER201 Engineering Design Course Manual, version 1.1 for further information. Note that violation of the center-line rule no longer results in disqualification, but does result in a gameplay penalty. Pre-game window - the three minute period before each 7-minute game during which communication with the robots are allowed. Re-programming the arduino during this time is not allowed; if required, this will be considered breaking of a game rule and appropriate gameplay penalties will be applied. Hopper locations can be inputted during this time, and any necessary gameplay strategy communication can be completed. 2

7 Gameplay penalty - If a design constraint or a game rule is broken (example: center-line rule), the final score of the round played will be multiplied by 0.5. If more than one rule is broken, the score will be multiplied by A set of design constraints can be found in section 4.3. Line detection - a modified line following system, where the robot does not follow a line by blindly straddling it (and thus slowly zigzagging along it), but by realigning itself at perpendicular grid lines to correct its forward-moving direction. Further details and technical descriptions of line detection is included in this document. Calibration turn - A 180 turn completed during the pre-game window to determine the time taken to make a turn. The robot first aligns itself at a perpendicular line, then proceeds to turn in place until both IR sensors have detected the line again. This time is stored in memory and used for modified odometry of turns and alignment. Further details and technical descriptions of the calibration turn is included in this document. Pluto - It is the name of the robot. The name has two pieces of significance. First, it is the name of the yellow dog owned by Mickey Mouse. He is both smart and lovable, just like the robot. Second, it is the name of the beautiful dwarf planet, that is a planet no more. Monsters, Inc. grieves upon the decision to striking it off the official list of the planets orbiting our sun. Thereof, Pluto is named in its honour. Henceforth, all mentions of the robot in this document will be using its name, Pluto. 3 - Executive Summary This project report will guide the reader through the design process of Monsters, Inc. in developing a fully autonomous robot to compete in the annual AER201 Engineering Design Competition for The challenge addressed is the design and construction of a robot that is capable of playing a modified version of Connect Four. Through careful analysis of the game rules, familiarization with the field of play, and rigorous testing, Monsters, Inc. developed a reliable and winning robot: meet Pluto, the second place finisher for the 2015 competition. This document will proceed in chronological order, discussing the project requirements, goals and initial steps. This includes any considerations on dimensional, weight and cost restraints, and the development of team goals with appropriate metrics to assess them. The design of the robot adhered to all team values which were determined through analysis of the challenge. These were updated through the course of the project and the final details are included in this report. Extensive background research was conducted to get an idea of possible designs, and a better understanding of components and materials. This includes both hobbyist and industrial robots with emphasis placed on techniques used and problems faced (as well as their solutions). Following this information, the report will describe the final design of Pluto, both at a high level system and low level sub-system detailed description. All appropriate figures and images are 3

8 included to describe the various components and features of the design. This is a complete technical summary of the electromechanical and circuit sub-systems as well as any strategies, algorithms and design associated with the microcontroller sub-system. The final design consisted of a 2-wheel and 1 ball caster chassis. The differential steering is implemented with two DC motors and an H-bridge circuit. A set of servo motors were used to control the gripper a hockey stick shaped component in charge of retrieving the ball, and the arm an aluminum trapezoidal channel which raises the captured ball. The ball is then deposited into the gameboard via a ramp. The robot is fully capable of navigating the playing field, by implementing a line detection algorithm which uses two IR reflectance sensors to detect grid lines. As with any design project, there were many changes made to the initial proposed design. Some of these addressed technical challenges faced along the way while other improvements or additions to the design came as a result of testing the robot during mock games. Of these, a key challenge was the failure of the ultrasonic sensors initially used for global navigation. This as well as other challenges are discussed in full detail, and essentially describe the entire project timeline. Finally, an administrative analysis of the project is included as a personal assessment of adherence to the project timeline, organized via a Gantt chart. Additionally, this reflection is essential for displaying the work load distribution amongst the members of Monsters, Inc.. A cumulative budget is also included to verify that the robot does not exceed the cost constraint. 4 - Design Process Introduction The AER201 Design Project was focused on the design and development of an autonomous robot capable of playing a modified version of connect four. Specifically, the game was non-turn based, and robots played against one another on a playing field, where each robot was confined to its respective half of the playing field. The game balls were located in 4 hoppers: 4 balls in each of the two corner hoppers and 7 balls in each of the two central hoppers which have variable location and orientation. Each game lasted for 7 minute intervals, during which the robot must navigate to hoppers, retrieve balls, navigate to the gameboard and play the ball in its possession. Robots were not allowed to interfere with their opponents, could only be in intentional contact with one ball at a time and could only play one ball per approach of the gameboard Summary of Design Process With a basic understanding of the design challenge, the first round of rapid brainstorming was carried out. This allowed for the development of divergent and creative solution paths not limited by tight constraints. This process took into account basic design requirements (see section 4.3) and was essential in better understanding the project and hypothesizing future challenges. 4

9 Once completed, the design challenge was appropriately framed, taking into account team goals and game rules. A set of values (see section 4.4) and goals were developed to provide a framework to guide the direction of the design. A preliminary set of metrics and constraints were developed and are included in the Monsters Inc. Project Proposal. As of submission date January 30 th, 2015, these set of metrics have since been updated to include more accurate measures of success for the changing expectations. For example, rigorous testing of the robot made it clear that accuracy and robustness in ball retrieval, transport and disposal was more important than the speed of the robot. To meet this change, the constraint for number of balls played was lowered (a faster robot means more balls can be played), and the constraint for hopper navigation and alignment was added. A complete list of metrics can be found in section 4.5. Next, research was conducted on various robotic devices and designs, for both industrial robots and hobbyist designs. These two categories provided unique insight on the field of robotics including applications, possible solutions and manufacturer/product information. This is further discussed in section 4.6. Finally, various designs were developed and prototypes were made to test concepts. Using the information gathered from conducting additional research, technical analysis and prototyping, a final design was developed. The preliminary design can be found in the Monsters Inc. Project Proposal. As with the metrics, the design was modified and improved throughout the project timeline. A summary of this process can be found in section 4.7, and further discussion regarding changes made and challenges faced is in section Requirements and Constraints Autonomous operation with no external inputs once game is initiated Must have on-board power Cannot exceed a 40cmx40cmx40cm envelope prior to game start Cannot exceed a weight of 3kg Cannot exceed a budget cap of $250CAD, including all components, materials and services utilized in the fabrication of the robot Cannot contain any breadboards Must have a safely accessible mechanism that ceases robot operation immediately (stop button or switch) Cannot damage playing balls, deface or permanently modify game board Team Values Reliability and Consistency: Through repeated testing and improvements, theoretically all possible situations should be tested. Robot behaviour should also be consistent amongst various test runs, and should behave as expected for all trials completed. Modularity and Reparability: Designed using functional decomposition, the systems associated with each task should be relatively easy to swap out with alternative designs. 5

10 All components should be easily accessible for repair purposes, and should not cause damage to adjacent components. Maneuverability: Robot should be able to move around the playing field easily. It should be able to avoid obstacles and access hoppers and the game board without having to reapproach targets if needed (i.e. rotation or reorientation in place) Simplicity: The robot need not be complex. Rather, the easiest solutions are preferred: easy to design, construct and implement. For example, complex navigation systems that leave room for error are to be avoided. Completing the job is more important than creativity. Robustness: All components of the robot, including the chassis, actuators, sensors and microcontroller, should be able to withstand environmental aggressions and accidental interference from oppositions Team goals The goals of Monsters Inc. in this design project were to produce a fully functional and autonomous robot capable of the following: (metric: number of tasks accomplished) Be aware of obstacles and be able to map (and follow) a route from one position to another (metric: number of obstacles hit. constraint: no collisions) Successfully navigate to corner and central hoppers, and move into a position for successful ball retrieval (metric: number of unsuccessful attempts to navigate to and align with a hopper during final test run. constraint: less than 2 hoppers) Accurately retrieve balls from approached hoppers, assuming perfect alignment with hoppers (metric: number of unsuccessful ball retrievals in final test run. constraint: less than 1) Navigate to the gameboard and successfully play balls without violating the center-line rule. (metric: number of unsuccessful deposits (i.e. ball does not go into a gameboard column); number of times robot violates the rule. constraint: no unsuccessful deposits; no violations) Play all balls from the corner hoppers, and some from central hoppers during the 7- minute game period (metric: number of balls played. constraint: 8 balls played) Justification for changes from the proposal: Change made Navigation to and alignment with hoppers Number of balls played: changed from 22 to 8 Justification for change Changes in initial proposed design of the chassis resulted in hopper alignment to be an important area. The system of line detection constrained Pluto s speed - if it moved too fast, the IR sensors wouldn t be able to accurately detect the lines. Speed was sacrificed for accuracy and overall performance; as such, fewer balls could realistically be played 6

11 Got rid of rule regarding placement of ball in already filled column Compliance with gameboard center-line rule during game time. Sensing of the gameboard was not implemented (see discussion in section As such, the rule can no longer apply. From early test runs, violation of the rule was a recurring issue. As such, it was important to address it Background Summary of design research DC motors or continuous stepper motors for primary locomotion Differential steering with a caster or 4-wheeled front-wheel drive Motors with internal gearbox to control output torque or motor RPM Larger gears should not be driven by smaller ones to avoid damage to internal gearbox of motors DC motors or servo motors to actuate components such as arms or grabbers Chassis of aluminum rails: high strength to weight ratios Use screws, nuts and bolts to secure connections for easy modifications Components should be housed and sheltered for robust designs Summary of motors Motor DC motor (Continuous) Servo motor Bi-polar stepper motor Uni-polar stepper motor Research and Testing notes Connects easily to components such as wheels and gears. Involves simple circuitry, including an H-bridge circuit to enable bi-directional capabilities. Motor speed depends on voltage applied; potentiometer or voltage regulators can be used to control voltage being applied. Optical encoders can be used to determine number of shaft rotations. Involves simple circuitry and provides more control over rotation - can specify number of degrees of rotation. Variety of servo arms allow for range of component designs and are easy to connect to thin sheet metal and actuate components made of light wood or plastic. Requires an H-bridge to operate and can run continuously like a DC motor. Generally large and heavy. Requires a transistor array chip to operate and can run continuously like a DC motor. Generally large and heavy Summary of visualization components Component IR reflective sensor IR proximity sensor Research and Testing notes Detects percentage of light reflected from a surface (darker surfaces reflect less than lighter). Can only distinguish between dark and light surfaces, but reliable and easy to mount. Can be tested easily to determine ideal operation range; sensors work well even if not perfectly parallel to the surface. Very reliable. Uses triangulation to determine distance to an object using detection of reflected pulses. Can be used for object detection but readings vary based on object shape, size, material or colour. Operational range varies. 7

12 Ultrasonic sensor Camera Determines distance to object by measuring time between emission and detection of sonar sound wave. Can be used for object detection, though cannot distinguish between walls and corners, or between objects that are close together. Easy to mount, though noise interference is an issue when using multiple sensors in close proximity. Can capture the state of the gameboard or playing field to help robot avoid obstacles or make intelligent plays. Resolution of camera must balance the cost. Time consuming to test; works best with Python code on the Raspberry Pi microcontroller Summary of Localization methods Method Relative positioning Global positioning Notes Uses odometry to determine where the robot is relative to its starting point. Not a reliable system if the wheels slip, and error accumulation is a big issue. Use of odometry should be minimized, but it is very useful for alignment with hoppers and small precise movements, given that the wheels and motors operate well. Relies on detecting landmarks to determine location. Triangulation is one such system that can be implemented. Another is the uses of ultrasonic sensors to determine distances from playing field boundaries Conceptualization A detailed record of the conceptual designs and data summary charts can be found in the Monsters Inc. Project Proposal. Only an overview of the conceptualization phase will be discussed below, including notes on design development, convergence of designs and formal strategies used. Functional decomposition was used to break the robot into smaller subsystems, each addressing a specific task. This meets the modular design goal and makes the overall design challenge easier to handle. By designing each component individually, the design becomes more robust as component interdependence is eliminated. This also promotes extensive testing, as components are integrated together in a step-wise fashion. It also makes it easier to identify when a specific component is not working. Brainstorming techniques were used to develop various concept designs for each subsystem, with model designs from the background research being used as a starting point. Concepts were first tested against requirements and constraints to eliminate some designs. Remaining concepts were prototyped and tests were carried out to determine ease of implementation and reliability of design. Data and observations from prototyping was taken and formalized into a summary charts. These charts were then analysed and the final designs were chosen. The ability to implement the design as conceptualized was prioritized over theoretical efficiencies, as the prototyping stage clearly showed some of the possible challenges concerning electromechanical components. Simplicity was valued over creativity, and reliability of the prototypes was essential. The overall final design can be found in section 7 of the Monsters Inc. Project Proposal. Since submission date January 30th, 2015, this design was modified or updated in response to problems 8

13 faced throughout the project timeline. The final design is detailed in section 5 and the implementation process is discussed in section Technical Description Figure 2: SolidWorks CAD rendering of Pluto - includes all major components and features, to scale System Level The design and construction of Pluto was completed in a modular fashion, where functional decomposition was a primary tool in addressing the project requirements. The main tasks were broken down as follows: 1. Primary locomotion and navigation around the playing field 2. Hopper approach and alignment 3. Turning aid 4. Ball retrieval 9

14 5. Ball disposal 6. Overall gameplay strategy Development of each of these functions involved integration of the three sub-systems, which are detailed in sections 5.2 to 5.4. The following description is a high level overview of the entire robot Overview of full functionality Pluto has two plastic wheels each driven by a DC motor and a ball caster, organized in a triangular arrangement on the small 20cm by 15cm chassis. An H-bridge circuit controls the voltages being applied to each motor independently, thus allowing for two wheel differential steering. Equipped with two IR reflectance sensors, navigation around the playing field is driven largely by line detection, a simpler and more efficient method of line following. Instead of detecting a line and essentially zig-zagging along it (traditional line following), Pluto reorients itself by aligning to each perpendicular line it approaches, based on when the black grid lines are detected by the IR sensors. Thus, Pluto is not constrained to following the specific grid lines, but can navigate between them as well. Before gameplay, Pluto does a calibration turn (see section II in 5.4.4) by turning 180 and storing the time it took to do the turn. It uses this time to adjust its movement when it s off the grid. The use of an LCD display and pushbuttons provides an interface for communication, through which hopper locations can be inputted. With this information, the location of obstacles and/or targets is mapped, and used later when approaching and aligning with the hoppers. It also receives input indicating whether it is the start of the game, or coming back from a reset, and apply the appropriate strategy to each. When gameplay begins, Pluto moves towards the right corner hopper to capture a ball, then navigates to the gameboard to play the ball in its possession. Once complete, Pluto returns to the same hopper to capture the remaining three balls, depositing each into the gameboard. Next, Pluto navigates to the left corner hopper to capture the four balls, putting them into play one at a time. The remaining gameplay time is used to navigate to the central hoppers, to capture and play additional balls. In the event of a reset, Pluto grabs one ball from the right corner hopper, then goes directly to the left corner hopper. Line detection is the primary navigation system, though when in close proximity to hoppers and the gameboard, odometry is used for alignment. Unlike traditional odometry, wheel encoders are not used; rather, the timing from the calibration turn is used to control all turns, approach targets, and move away from them. Pluto is equipped with a servo actuated plastic gripper in the shape of a hockey stick. Once properly aligned with the hopper, the gripper closes around the ball to push it into the base of the aluminum sheet metal arm. With the ball captured, Pluto moves away from the hoppers, raises 10

15 the arm slightly to prevent the arm from interfering with Pluto s movement, and moves towards the gameboard. Once in position, the arm is raised and the ball slides down the chute of the arm, onto the release ramp where it is redirected onto the side-release and into the gameboard column. Further details of each function is broken down into sub-system components, and are appropriately described below Pre-flight check list Before starting a game, some items are checked off to make sure Pluto is ready to go The flip switches controlling the arm and wheels are off Batteries are connected to the motors The voltage of the battery is within the required range (12V-13V) Battery pack is connected and the power LEDs on the Arduino board are on The wheels are tight around the D-shafts The LCD screen is not flickering The base of the arm is below the gripper level Within the 3 min window, other items are executed Turn the flip switches on Reset the Arduino to perform the calibration turn Place Pluto in the starting square, facing to the right, and straddling a black line Input positions and orientation of the hoppers Input the decision to go to the right hopper Wait for the 7-min mark to start moving Post-fight check list After a game, some items are checked off to store Pluto until the next round Turn off the flip switches Unplug the battery pack powering the Arduino Lower the arm Close the gripper Store Pluto somewhere safe and stay on guard Electromechanical Sub-system Each of the different functional components outlined above are detailed below for the electromechanical sub-system. This includes notes on the design and construction of the final systems, with a focus on key features Primary locomotion Pluto uses two DC motors with an operating range of 12-24V and a D-shaft connection to the wheels. They are connected to a universal wheel hub, which is screwed into the 60mm diameter, 11

16 8 mm thick wheels using #4-40 screws. The wheels are made of plastic and have a rubber treaded surface to increase friction for controlled locomotion. The motors are mounted onto aluminum brackets which are screwed onto the base using threaded wood screws and washers. After testing Pluto on the playing field, it was found the wheels were angled and at times did not turn on the ground: the motors were too heavy for the screws in the bracket to properly support. Cable ties Rubber treading on wheels to aid with locomotion Universal hub connecting the D-shaft of the DC motor to the wheels Metal ball caster to support motion of the robot without additional Figure 3: Mechanical components for primary locomotion - Pluto uses two wheels and a caster to fully support the chassis were used to fix the motors to the base, reducing some of the load on the bracket. Pluto implements two-wheel differential steering, with a ¾ diameter ball caster located at the back of the chassis. The locomotive components can be seen in Figure Navigation The two IR sensors are mounted on a custom aluminum bracket, close to the wheels and raised approximately 5mm off of the ground. By being kept close to the wheels, they relay the most accurate information about the positioning of the chassis during pivoting on the wheels (see Figure 4). This helps in aligning the wheels for forward or backward motion, and minimizes time spent during realignment. The distance off of the ground was determined through careful testing to determine the optimal range of operation (5-8mm above the surface). The bracket is angled slightly to achieve this distance and small cardboard sheets were used to ensure the sensors were parallel to the ground (so the angle does not influence sensor readings). By placing the sensors on the top surface of the bracket, it protects the sensors from accidental collisions. Further details regarding the IR sensors and navigation are included in the circuit and microcontroller subsystem descriptions. 12

17 QRE1113 IR Reflectance sensors used for line detection: can distinguish between light and dark surfaces Cable ties used to secure motors onto their brackets Aluminum mounting bracket for IR sensors allows for variable placement of sensors; optimal position determined through testing Protoboard for IR sensors, wires not depicted (see section for circuit details) Figure 4: Bottom view of Pluto, showing all main components including sensors for navigation, locomotive components and applicable circuit organization Hopper alignment aids Pluto is fitted with hopper alignment aids, which are triangular pieces of basswood fastened onto the front of the base. They extend approximately 2.7cm out from the front of the base, and 4cm out from the side, to allow Pluto to wedge itself in between the hopper legs upon approach for ball retrieval. By hitting the hopper legs, Pluto s forward motion is restricted, preventing the chassis from moving too far forward, thus mechanically correcting misalignment. Refer to Figure 5. Figure 5: Hopper alignment aids on the chassis. This image shows the optimal position of the chassis with reference to the hopper legs. Hopper legs shown for reference 13

18 Turning aid When Pluto is near the gameboard, it comes in close contact with the walls when it is turning. To ensure that the sharp edge of the base from the rear doesn t get stuck at the wall, a gear was fitted onto basswood supports and mounted onto the right back corner of Pluto (see Figure 6). It acts to extend the base outward in when turning towards the gameboard. Once the gear comes into contact with the side wall and/or barrier, it rotates with Pluto and prevents the chassis from getting stuck. Figure 6: Gameboard alignment feature was a gear whose purpose was to slide along the gameboard Handling the ball The ball retrieval and deposit system is broken down into the gripper, the arm, and the release ramp. These three systems are designed very similarly, and operate together to achieve the required tasks. Servo motors are used to actuate the motion of each of these devices, as servos allow for precise movements and controls, while meeting the torque requirements of the components. Ball retrieval: The gripper is constructed of 6 mm Plexiglas, in the shape of a hockey stick. The gripper extends outward to curl around the ball and drag it into the base of the arm. The gripper is controlled by a 4.8-6V micro servo motor. The servo arm is screwed onto the servo with the hardware provided, and is connected to the gripper using paperclip wires extending from the holes in the gripper and through drilled holes in the Plexiglas (see Figure 7). The connection is secured by folding the wires upward, and fastened by taping the ends of the wires. Once connected to the circuits, the gripper was tested with the hoppers to determine the optimal open and close positions, whereby the ball was most consistently retrieved and the closed gripper enclosed the ball in the arm without damaging the arm. The gripper is mounted to the base using custom basswood housing to hold the servo motor in place. Since it is stationary, the gripper can operate independently of the arm, and does not rotate upward during ball disposal. Figure 7: Gripper assembly after mounting the servo motor and into the housing. 14

19 Ball lifting: The arm is made of inch thick aluminum sheet metal, with a 2.5cm channel with a trapezoidal cross-section. The base of the arm has a barrier of glue which keeps the ball from rolling out when the gripper is opened. A 5V servo motor actuates the arm, providing the required torque and control. The servo arm is connected to the servo motor using the screws supplied with the motor, while simultaneously fastening the custom sheet metal servo mount to the motor arm. Bent paper clip wires secure the connection of the servo arm to the metal housing, which is fastened onto the arm using glue. The arm is mounted onto the base using a 21.5cm tall support made of basswood. See Figure 8 for the assembly. The support has a motor housing area which both holds the motor in place and raises the arm to the required height. The support is fastened onto the base using metal brackets, M3 machine screws and nuts, and wood screws. Added barrier to keep ball from moving out Glue barrier to keep the ball from falling out Figure 8: Assembly of arm. Each component is easy to replace if needed through modular design. Note the assembly of the above two components in Figure 9. This is a critical region in terms, both in terms of the fundamental task of retrieving the ball, and the way the different components which were designed independently at first, come together. The gripper must close around the ball, pushing it into the base of the arm without interference from the arm. The arm barrier must not interfere with the arm when it is raised and lowered. The position of the housing determines how the gripper closes around the ball. Finally, this view shows the hopper alignment aids, which guide the robot into position to pick up the ball. Figure 9: The assembly of the gripper, arm and chassis. 15

20 Release ramp: The final component in this system, the release ramp is constructed of thin Plexiglas, providing a smooth, low friction surface for the balls to roll down. Once the arm is raised, the ball rolls down the chute, straight onto the release ramp, and then is redirected by the basswood gate onto the siderelease ramp (see Figure 10). By being redirecting, the ball is slowed down and so is delivered into the gameboard column with more control. Additionally, the side ramp allows for easy navigation from the corner hoppers, as fewer turns of Pluto are necessary than with the back-release ramp design. Figure 10: Plexiglas ramp including the servo controlled gate. Ball path is indicated by the dashed line on the diagram Mounting and organization The mounting and organization of electrical components, protoboards and the Arduino on the chassis remains consistent with design priorities: modularity, robustness and flexibility in design and repair. Each sub-circuit was soldered onto a separate protoboard, which were all mounted using machine screws and nuts. This system allowed circuits to be made or repaired progressively, while Pluto could still be tested with the remaining systems. Additionally, the easy ability to mount and dismount the boards minimized damage done to the circuits, and allowed for easily repair where necessary. The Arduino was mounted flat onto the chassis where it is safe and easily accessible for powering it and accessing its pins Circuits Sub-system To meet design priorities of ease of organization and simplicity of the design, all major circuitry components were assigned individual protoboards. Power and ground wires from these individual boards were linked to one of two main protoboards (central boards A and B), and the input/output wires were connected directly into the Arduino. These major sub-circuits are for the H-Bridge, IR sensors, LCD screen and the push buttons, all of which are discussed in full detail below Protoboards In total, 5 printed bakelite protoboards were used [1], as well as one high performance double sided glass fiber protoboard [2]. Two common protoboards were used on Pluto and each had 16

21 shared 5V power from the Arduino as well as the common ground since the microcontroller only had a limited number of pins (3) assigned to each power and ground. Central board A This protoboard housed the H-Bridge circuit, 2 IR sensors, 2 switches and the connection to the 12V battery pack (see Figure 11). Central board B This protoboard housed the LCD screen, 2 pushbuttons and the servo motor for the arm. Figure 11 To the left Central Board A, to the right Central Board B H-Bridge Circuit The H-Bridge circuit was the primary circuit required to drive 2 gearhead DC motors with an operating voltage of 12-24V. The H-Bridge used was a L293D Texas Instruments product. It was required to apply voltages across the motors in either direction, providing driving currents of up to 600mA and ensuring bidirectional motor capabilities [3]. Figure 12 below represents the structure of the H-bridge with all its pins as well as the table that provides a summary of the inputs required from the microcontroller to obtain specified motor movements, which was used to program the function of the motors. Pins labeled 1-4 (with arrows) were connected to the input pins from the Arduino microcontroller (digital pins respectively). Pins labeled M, the outputs to the motors, had wires from the motors soldered to these pins. Pins 1, 9 (enable inputs) were connected to PWM pins 5 and 4 on the microcontroller respectively. Pins 4-5 and were connected to ground, pin16 (power to the chip) was connected to 5V supplied by the microcontroller and pin 8 was connected to an external power supply for the motors, in this case a battery pack supplying 12-13V that consists of 9 AA batteries. All of these last 3 connections were made through central board A. 17

22 Figure 12 Left - Diagram of an H-bridge with all pins labelled, Right: Table summarizing motor behaviour through controlling an H-bridge IR Reflectance Sensors IR reflectance sensors were the only tools for navigation around the playing field, and were used to detect black perpendicular lines and align the chassis to be perpendicular to them. For this purpose 2 analog versions of QRE1113 reflective sensors were mounted to a custom bracket approximately 5mm above the floor level to obtain consistent readings. Each sensor has three pins: input power, ground and output. All pins from both sensors were connected to the same protoboard, which was attached to the bottom of Pluto. This reduced the number of wires used in the circuit implementation from 6 to 4: 1 power, 1 ground and 2 output wires. The power and ground wires were connected to central board A, while the two output wires were connected to the microcontroller to analog pins 1 and 2. The sensor returns a signal of varying voltage (0-5V) that represents the amount of IR light that has been reflected by the surface it is directed at. This is read by the analog pins and translated to a value between to be used in the code LCD Screen The LCD screen was an important framework for debugging purposes as it was programmed to display readings from the sensors and push-button entries. Its primary function was to provide an interface for communication with Pluto, by showing the entries made for the hopper locations. The photo below shows the LCD circuit with 6 output wires that were connected to digital pins on the Arduino, and the ground and input power wires that were connected to central board B. This was done to ensure that the length and the location of the wires does not interfere with other mechanical components and does not impact on their overall performance. 18

23 Figure 13: Implementation of the LCD screen circuit on the protoboard Pushbuttons Pushbuttons were mounted to a separate protoboard for ease of use. They were used for debugging and mainly assisted with inputting the location of the central hoppers. The left pushbutton was used as the Select option (see left button of Figure 14), while the right one was the Enter button, and were connected to the digital pins 36 and 37 respectively. The power and ground were both connected to the protoboard shared with the LCD screen, central board B. The system for inputting hopper location and orientation is further described in the Microcontroller sub-system. Figure 14: The pushbuttons used in to interface with the LCD screen 19

24 Switches To meet the requirement of a safely accessible STOP feature that ceases the operation of Pluto immediately, two flip switches were introduced into the design (see Figure 15). The switches were connected to central boards A and B to control appropriate circuitry components. One of the switches stops the functionality of the motors immediately by breaking the connection between the H-bridge and the battery pack on central board A, while the second switch cuts power to the rotating arm on central board B. These two components (the wheels and the arm) where chosen because they re the moving components that can cause damage if something wrong happened with the circuits or with the code. Figure 15: Illustration of the switch used as a STOP feature on Pluto On-board power Two separate battery packs were used on Pluto. One was intended to supply the voltage of 12-13V to the H-bridge circuit to drive the motors. Another external battery pack, the Insignia NS 2600mAh Portable Battery, was used to supply 5V to the Arduino. The H-bridge battery pack was connected to central board A via a battery cap and was connected to the circuit with the on/off switch to ensure that the movement of the wheels can be stopped at any point in time. Figure 16: Illustration of the on-board power used to drive the wheels 20

25 Figure 17: The final layout of the Arduino Mega with all used pins labelled Microcontroller Sub-system The major, and only, component used for this subsystem is the Arduino Mega It has 253,952 bytes of program storage space and 8,192 bytes of storage space for global variables. It has 54 digital pins of which 15 can be used as PWM (pulse-width modulation) and 16 analog pins. It can power components with a 5V output port or a 3.3V output port [4]. The final program used in the design competition used 29,146 bytes of program storage and 3,337 bytes of storage for global variables. The main feature of the coding structure is simplicity. The entire program is written in one file, which is separated into different functions. Many of the variables used in the program are global variables so they can be accessed and changed easily by multiple functions. The main variables are outlined below Global variables All the pins used with the Arduino. This includes the pins responsible for moving the wheels, controlling the servo motors, reading the sensors, reading the pushbuttons, and displaying information to the LCD screen. The direction that Pluto is facing at all times The direction of motion of the each wheel and general direction of motion of Pluto The current positions of both IR reflectance sensors The state in which the program is in The time to complete a 90 turn The position of the hoppers The plan that Pluto should follow The positions Pluto should be in before aligning to the hoppers or the gameboard 21

26 The current movement plan of Pluto to complete a mission The positions where the servo motors are needed to be The program, like any default Arduino sketch, is split into two functions; setup and loop. The main purpose of each is explained below Setup This function runs once at the beginning of the program. It assigns the pins that are to be used within the program, and in case of the servo motors, it assigns their default positions. It also assigns the first state that the program goes into, which is the calibration turn Loop This function keeps repeating itself throughout the entirety of the program. It is further divided into states. Each state has a specific function, for example, setting the direction of motion, updating the position of Pluto, or picking up the ball. The program determines which state it is in, then executes the appropriate commands. Once complete, the program decides whether to remain in the current state, or move to a different state. See Appendix B for some snippets of the code. The states and their functions are outlined in Figure 18. Some of the states are described below. State A: Increments the mission plan in place, then proceeds to state B for more calculations State B: It calculates the route that Pluto should take, depending on its current position and the destination. The route consists of an array of movements, either driving the motors forward or backward, or doing a 90 turn. If it needs to drive forward or backward, it goes to state D. If it needs to turn, it goes to state G. State C: Goes through the array of movements for one mission. If it needs to drive forward or backward, it goes to state D. If it needs to turn, it goes to state G. State D: It calculates the direction that Pluto should follow, depending on its current position and the intended destination. It goes to state E next. State E: It decides on the direction of the wheels, forward motion or backward motion, depending on the direction Pluto is facing and the direction of its destination. It goes to state F. State F: It applies line detection algorithm while advancing to the intended destination. Upon crossing each black gridline, it updates the positions of the sensors. When the sensors reach the required destination, it goes to state C. State G: It performs a 90 turn, then proceeds to state C. State H: It performs the calibration turn, and saves the time it took. It proceeds to state I after. State I: It reads the arrangement of the center hoppers and store it. It also reads whether Pluto is starting the 7-min game or coming back from a reset. 22

27 Figure 18: State diagram of the full program Navigation Navigation is split into three different components: line detection, 90 turn, and odometry. Pluto uses line detection to navigate through the playing field. Once it comes close to the hoppers or the gameboard, it switches to a form of odometry in order to align with them. After retrieving the ball, it backs away from the hopper using odometry, then switches back to line detection. These sections are explained in detail below. 23

28 I - Line detection Pluto s line detection uses two IR sensors to detect the grid lines on the floor, each of which are associated with a wheel. Pluto starts off facing the right side of the playing field, while straddling a black line. Then, as it moves forward, the sensors, which are mounted close to the wheels, detect the perpendicular black grid lines. If one sensor reaches the line before the other, it stops its respective wheel until the other sensor reaches the line. With both sensors on the line, Pluto begins moving forward again. This system ensures that Pluto corrects its orientation whenever it crosses a perpendicular black line. This algorithm was used in place of the following a line because it s faster and it is simpler, since following a line would need to be turned off every time it comes to an intersection. Whenever Pluto needs to change direction, it makes 90 turns using the time it calculated from the calibration turn, then aligns itself with the perpendicular set of grid lines. This allows Pluto to remain perpendicular to a set of grid lines throughout the game. The program divides the playing field into squares numbered from 1 to 72. The initial position of Pluto and the sensors are manually inputted into the program. Upon crossing a set of black lines, the program updates the position of the sensors, thus being aware of Pluto s position at all times. II - Calibration turn and 90 turn The motors driving the wheels are DC motors, and are not equipped with optical encoders for the wheels. Therefore, there is no feedback from the wheels on how much Pluto has turned. The amount of rotation the shaft undergoes solely depends on the voltage supplied to it and the duration during which it is supplied. Since the voltage coming from the batteries can fluctuate, consistent turning without encoders is difficult to achieve. To compensate for this, Pluto calibrates itself during the pre-game window. Pluto first orients itself at a perpendicular black line using the IR sensors, then it turns in place, by moving both wheels in opposite directions, until both IR sensors have detected the line again, thus performing 180 turn. The time take to make this turn is multiplied by 0.55, which was determined experimentally, then is stored in the program memory, and used to make all other turns. The drop in voltage output from the batteries during 7 minutes (the time for one game) is insignificant and therefore doesn t affect turning performance. III - Odometry As mentioned above, Pluto uses a form of odometry when aligning with the hoppers and the gameboard. First it follows the line detection strategy until it comes as close to a hopper or the gameboard as possible. After which, it drives the motors by a specified amount of time in order to align with the hopper or the gameboard. In order to avoid the problem of voltage fluctuation as described in section II of 5.4.4, the program uses fractions of the variable that stores the time calculated during the calibration turn. 24

29 Hoppers Location After executing the calibration turn, the LCD prompts the user for the location of the center hoppers. The location is entered using pushbuttons during the 3-min window. The user enters 3 digits, each of which is described below. 1st digit: It accepts a value from 1-3, and represents the scenario of both hoppers. There are 3 possible scenarios. The accumulative distance between each hopper and the gameboard has to be the same. Therefore, the left hopper can be on line 1, while the right hopper on line 3 (scenario 1, see Figure 19), or both hoppers can be on line 2 (scenario 2), or the left hopper can be on line 3, while the right hopper on line 1 (scenario 3). Figure 19: Scenario 1 with the hoppers Line 1 Line 2 Line 3 2nd and 3rd digit: It accepts a value from 1-4. Each hopper has four orientations. Orientations 1 and 2 have one leg facing to the gameboard, and two legs facing the back wall. 3 and 4 have two legs facing the gameboard, and one leg facing the back wall. Orientations 1 and 3 are on the left side, while orientations 2 and 4 are on the right side. The orientations can be seen in Figure 20. The 2nd digit corresponds to the left hopper, while the 3rd digit corresponds to the right hopper Figure 20: Possible orientations for a single hopper Reset After inputting the hopper locations, the LCD prompts the user to choose the right hopper or the left one. Upon choosing the right hopper, Pluto goes to it four times, emptying all the balls, before going to the left hopper. If the user chooses the left hopper, Pluto would go to the right hopper only once, then advance to the left hopper. This option was put in place to be executed after coming back from a reset so Pluto doesn t waste time going to the right hopper four times if there are not enough balls there. 25

30 6 - Implementation When integrating components together and testing Pluto, there were many iterations of each prototype and implementation on the robot. After each modification or change, the design was tested rigorously, observations were made, and design improved. When a problem was faced, it was important to find which sub-system it was associated with. Various testing procedures were used to determine the root source and cause of the problem, depending on the nature of the problem. These are all discussed below. Due to the interdependence of all the systems and components, the following section will not be organized like section 5, where a cumulative overview was followed by detailed sub-system analysis. Instead, each item, task and component will be discussed, with high level and subsystem analysis Primary Locomotion: Implementation of DC Motors Throughout the timeline of the project, problems with the DC and servo motors, used to actuate various devices, were faced. During early tests, one of the wheels would stop turning, causing Pluto to pivot around one wheel and to get lost in the playing field. First thought to be a circuits issue, the voltage was checked and found to be consistent throughout the testing. The pins for the motor were also swapped to check for inconsistencies in the Arduino output. However, the problem persisted. Finally, the wheels were allowed to rotate while the chassis was lifted off of the ground, and then were put into contact with the ground. This two-stage process was repeated until it became clear the problem was an electromechanical issue. The threaded insert which connected the hub and wheel unit to the shaft of the motor would come loose, interfering with motion. Additionally, the end of the DC motor opposite to the shaft was not properly supported by the bracket mount; its weight would apply stress onto the motor shaft, keeping it from rotating properly. The issue was addressed by using cable ties to hold the motor end onto the bracket. Later in the project timeline, one of the wheels began running at inconsistent speeds. The threaded inserts were tightened and cable ties checked. Voltage and pins were tested again, and circuits were ruled out as the cause of the problem. Finally, the wheels were removed and the motors inspected: as speculated, the motors were damaged by the pre-cable ties design and the rigorous testing. The shafts of both motors were loose (one more than the other), suggesting the internal bearings were damaged. The motors were replaced. Following the replacement, Pluto veered slightly towards the right when it was supposed to move in a straight line, causing problems with the calibration turn and alignment with hoppers. The motor pins were swapped to rule out any circuit or microcontroller issues. Testing with different codes led to the conclusion that the motors simply ran at different speeds, a problem known to be faced by other teams. This issue was resolved by adjusting the calibration turn and adjusting turn times for hopper alignment. 26

31 6.2 - Navigation: Line Detection The line detection system, as described in section I of 5.4.4, was decided upon early on and used throughout testing and evaluations. One of the problems encountered with line detection was its deviation from traditional line following techniques: although Pluto corrects itself to be perpendicular to a set of lines, it doesn t ensure that Pluto is straddling a line at all times. One way to address the issue was by using an array of IR sensors to check for the position of Pluto with respect to the line it is straddling. Sensor data would be used to correct its position. However, this change from line detection to line following would slow Pluto down (more frequent stops to check straddling of a line) and would add more sensors and complicate the feedback program. The other option was to use ultrasonic sensors and implement a global positioning system. This was the chosen design, however due to difficulties further discussed in section 6.3, could not be successfully implemented. The original design of fixed and independent mountings for each sensor was difficult to implement given the desired location of the sensors: immediately next to the wheels. To simplify the design, the two IR sensors were mounted on a bracket which could be attached to the chassis on different places and at different heights. This flexibility proved to be important as the optimal range of operation for the sensors was determined through multiple trials. Additionally, the three global playing fields all differed in topology - specifically, there were small ridges on the floor within playing fields. The bracket allowed for easy adjustment, while keeping the two sensors on the same plane and protecting them against bumping into any objects or ridges. For most of the testing, Pluto was operated at a low speed to allow for noticing small errors in operation and to prevent any damage from collisions with walls or hoppers. It was thought that the speed could be increased without affecting the performance of the navigation system, but implementation proved otherwise. As the speed increased, the momentum also increased, casting the wheels a greater distance before coming to a complete stop. This threw off the robot making it hard to detect lines and execute turns. By powering the DC motors to different voltages and testing, it was determined that Pluto could operate at a maximum of 14.5V without affecting navigation or line detection, but an optimal voltage was within V Navigation: Failure of the Ultrasonic Sensors One of the primary obstacles encountered during the design process was the navigation system. Pluto was initially supposed to use 2 IR reflectance sensors and 3 HC-SR04 ultrasonic proximity sensors located at the left, right and back of the chassis. These provided the mechanisms for line detection, and global navigation and positioning respectively. Using more than one type of sensor was necessary to not only align with the black lines on the playing field, but to act as a self-check mechanism to correct any error accumulation from both line detection and odometry. Thus, accurate alignment to the hoppers and the gameboard would be ensured. By using the ultrasonic sensor, Pluto would be able to check the distance to the right and left walls, and make sure it is within a good range to ensure it is straddling a line. 27

32 Prior to implementation, the ultrasonic sensors were tested through bench-test experiments and proved to be an incredibly reliable component for global positioning. One ultrasonic was installed on Pluto for progress evaluation I, and it proved to work accurately with no flaws. However, once they were soldered to protoboards, mounted and used for some time, they began to give problems. The outputted values were usually incorrect or 0, however sometimes correct values were outputted. There was no way to filter out the incorrect values due to the inconsistencies of the readings. The sensors were taken off the chassis, the wires were checked, and the sensors were bench-tested without any avail. This sudden failure of all three ultrasonic sensors made it impossible to implement the global navigation system, leaving only the IR sensors and line counting to determine the position of Pluto on the playing field. To determine the problem with the ultrasonics, each sub-system member completed a set of tests that are outlined below. However, no conclusive data was obtained and the cause of failure remains unknown Electromechanical Testing To determine the problem with the ultrasonics, various testing systems were used. Each sensor was tested while mounted on the chassis, and then taken off and tested independent of the other sensors to check if noise or signal interference was an issue. Ultrasonics placed into close proximity sometimes interfere with one another, however they are not known to do this if placed 90 or more from each other. As our ultrasonic array had three ultrasonics all 90 from each other, this seemed to be the unlikely cause of the problem. The height above the ground and the sensors angle to the chassis was also varied to determine if there was an issue in the mounting of the component. The sensors were tested off the chassis as well, to try and eliminate either component failure or mounting issues. The sensors continued to give inconsistent readings, indicating a component issue. Our next steps to diagnosing the issue was for each member to take a new sensor, solder it to a board, mount it to a makeshift chassis and write the code to process the data. This might help to eliminate overlooked human error. However, given that there were only a few days to the preliminary competition, it was decided to focus on making the remaining design more reliable Circuit Testing Considering that the first time the issue with the ultrasonic sensors occurred was after the circuits were implemented on the protoboards, the first test that was done to check for the circuits issue was to do a continuity test on the protoboards. For this purpose the multimeter was used to touch the probes to the wires of interest. If the multimeter gave any reading not equal to 1, it would indicate that there was no connection made between the elements and the circuit would need to be re-soldered; however this problem was not found to be the true cause of the sensor failure. The multimeter was also used to check the voltage supplied to the input pin on the sensor. It was found to be equal to 5V, which is the required voltage input, so this was ruled out as the cause of the issue. The last test that was done was after the sensors were each removed from the base of 28

33 the robot and checked separately. To make sure that the issue was not related to the power and ground being shared by the three sensors, each of them were tested separately, after being supplied with 5V and connected to ground. This test showed that all 3 components were permanently damaged since the readings persisted to be inconsistent and thus the root cause of the issue could not be able identified without further tests with fully functional sensors Microcontroller Testing An algorithm was used to eliminate outliers or flaws in sensor readings. The sensor takes seven successive readings, arranges them in ascending order, then takes the average of these values. If the average is not close to the mean (within 1 cm), the readings are trimmed from both sides, and the average is taken again. This was put in place to eliminate faulty readings and increase the reliability of the sensors. When the ultrasonic sensors failed, all the readings were examined. There were major inconsistencies, such as reading all zeros, reading 2 correct value and 5 incorrect lower values, or reading 7 incorrect values. The amount of time between each emitted ultrasonic wave was adjusted to determine if this was an issue, but changing the times did not make a difference. Instead of depending on ultrasonics for position correction, timing methods were implemented by hard-coding adjustments to the paths Pluto was taking around the playing field. Through multiple tests, areas where Pluto deviated significantly from the desired course were observed and corrected. The ultrasonics were also to be used to align with the center hoppers and align Pluto s back with the gameboard from dropping the ball. Since they were not implemented, the corner hoppers were emptied first, and the side ramp was used to drop the balls in the gameboard Alignment: Approaching the Hoppers The initial proposed design had a larger base than the final implemented design to help with hopper alignment. However, the larger base would restrict movement around the playing field, especially around the hoppers. To maintain maneuverability, a smaller base with hopper alignment features was used. Conceptually, the triangular bumper features would help guide the robot into the hopper by sliding against the hopper leg. When implemented, this didn t work. The angle of the bumpers was too shallow, relative to the approach and the bumper didn t extend the width of the chassis enough to come into contact with the hoppers upon every approach. However, when the two bumpers did come into contact with the hopper legs, they kept Pluto from moving too far forward, allowing it to capture balls very accurately once aligned. Larger bumper features with a different design were tested, however they failed to improve the alignment by a considerable degree Electromechanical improvements The reliance on odometry could be further reduced by widening the base to allow the chassis to catch onto the hopper legs more effectively. This would improve navigation and alignment to the central hoppers, which proved to be incredibly challenging without a global positioning system. 29

34 Even though this can restrict movement around the playing field, it might be worth-while compensation to increase the chances of retrieving the balls Circuits/Microcontroller Improvements To further aid hopper alignment, IR proximity sensors could have been used to detect the hopper legs. Having sensors on either side could help correct Pluto s alignment to the hopper. In all the trials done, at least one side bumper comes in contact with a hopper leg. After Pluto aligns with the hopper, it would check both sensor to check if they re close to the hopper legs. If only one of them is, Pluto would back up, reorient itself, and align with the hopper again. This would be a more flexible design by eliminating the sole reliance on odometry and timing. The use of a realtime feedback system could improve the reliability of aligning to the hopper without a significant change to the algorithm in place Alignment: Interference with the Gameboard When conducting trial games, the release ramp often crossed over the center-line and into the opponent s territory, both violating the center-line rule and depositing the ball into the other half of the global playing field. Initially, the ultrasonic sensors were to be used for navigating to and aligning with the gameboard. However, without these or a system of global positioning, odometry was not accurate enough, therefore mechanical aids were tested. Specifically, plastic gears on a metal axle were mounted onto basswood supports. One was placed onto the back left corner of the chassis, and served to keep the robot a distance from the central wooden barrier: when approaching the gameboard, Pluto makes a turn at the front corner of the playing field. When the gear comes into contact with the barrier and/or side wall, it keeps Pluto from moving closer to the barrier and thus the gameboard. This gear ensured the robot doesn t get stuck at the wall while turning. To address the center-line rule violation, a similar gear structure was added onto the left side of the chassis, protruding about 8-9cm out from the chassis edge. Theoretically, when the gear comes into contact with the gameboard, it keeps Pluto from moving closer and allows it to slide against the gameboard and retain the desired distance. When tested, the single gear sometimes got caught into the columns and created a pivot point. Without a global positioning system, Pluto would be unable to correct itself. To fix this, a second gear was added - since they are placed close to one another, contact with one should allow the second gear to come into contact with the gameboard as well, thus getting rid of the pivot point. In the preliminary tests, this system proved to work fairly well. However, further testing showed the gears appeared to catch on ridges in the wall or metal rods in the gameboard, causing Pluto to pivot about one gear and lose its orientation. These two gears were removed prior to the final competition Ball Retrieval: Developing the Gripper The gripper was initially designed as half a bucket, to slide under the ball and pull it into the other half of the bucket which was connected to the arm. When testing this design with the corner 30

35 hoppers, the bucket sometimes got stuck against the wall and was not able to capture the ball or would be damaged in the process. Due to this, the design was changed to the final hockey stick design, which was shaped to slide the ball out without getting caught in the corner of the playing field. The gripper was initially mounted to the base of the arm, and thus would also rotate upwards when the arm was raised. This design was not feasible as it destabilized the arm, added weight, and introduced mechanical complexities in terms of operating the gripper motor. Finally, it was decided to try mounting the gripper to the chassis. It was difficult to find a secure and stable way to house the motor while ensuring the gripper was in the correct position to retrieve the ball every time. Additionally, the permanent housing would make motor change difficult, as shown by future changes. During testing, the gripper speed was observed to be noticeable slower, indicative of a problem with the motor s internal gearbox. After conducting more tests, the servo motor began failing, and would no longer rotate the gripper consistently. Prior to progress evaluation III, the motor was replaced with a new, identical model Release System: Developing the Arm The first prototype developed was made of thin wooden board, popsicle sticks and actuated with the 90 plastic DC motor. The success of the prototype in showing functionality led to the first iteration of the arm using a single continuous sheet of thick aluminum sheet metal which was easily bent into the desired shape. With a trapezoidal cross-section, the ball fit into the channel of the arm very easily, with enough freedom to roll when the arm was rotated. The motor was attached to the arm using a custom connection made of pine wood, using small machine screws to hold the motor shaft in place. The motor didn t meet the torque requirement when operated at its recommended voltage. However, when supplying the motor with a higher voltage, it was able to raise the arm well. Testing it with a ball proved that it was going too fast and thus throwing the ball off. To compensate for that, a duty cycle was introduced in order to raise the arm slowly with considerable control over the ball. An alternative to overpowering the motor was taking off weight off the arm in order to decrease the motor s torque requirement. To address this, the metal arm could be modified by cutting slits into the rail to reduce the weight of the arm. However, this would have been difficult and time consuming. The other alternative was to make a new arm out of thinner aluminum sheet metal. Difficulties in attaching the DC motor to the new arm was avoided by changing motors to a small light-weight servo motor. This not only made mounting easier, reduced cost and simplified the support design, it also gave more control over the arm rotation. Prior to the preliminary competition, the servo motor for the arm stopped functioning consistently as it was programmed to do. The arm was originally supplied with an operating voltage of 3.3V to help control the speed at which the arm was being raised, but was changed to 5V, which momentarily fixed the problem. Though it is unclear why this worked, it is possible 31

36 that the servo motor's power threshold is close to 3.3V and repeated operation of the motor caused the issue to become visible. However, at the higher voltage and speed, the ball was sometimes thrown up and out of the arm during deposit. To address this, the arm was raised in two steps, decreasing the initial acceleration of the ball and providing more control. The servo motor eventually stopped working prior to the final competition. During the final test before its failure, the arm was caught under the gripper. The motor continued to try to lift the arm, damaging the gears. When tested, the servo was not able to lift the arm past 50, and had to be replaced. The new servo motor was supplied with 5V and raised in two steps; with this implementation, the ball was thrown out of the arm only once during the competition Release System: Developing the Release Ramp The initial release ramp design consisted of a semi-circular tube which would be continuous with the arm once it was raised. This design worked very well for the progress evaluations and allowed for easy manipulation of the speed of the ball by changing ramp angle and surface material. Testing this system showed it was more difficult to align accurately with the gameboard when coming from the corner hoppers, while aligning from the center hoppers was very easy. The design was then modified to incorporate a two-way ramp with a servo-controlled gate which redirects the ball down the back release or the side release ramps. Specifically, balls from the central hoppers would use the back release, and balls from the corner hoppers would use the side release to simplify navigation. A few prototypes were developed out of sheet metal. Initially, the entire back release ramp was controlled by the servo, but alignment of the ramps was difficult. This was then changed to have a stationary Plexiglas ramp mounted on a basswood support, with a gate to redirect the ball. This design proved to work very well and was easy to both design and implement. However, once the ultrasonic sensors failed, navigation to and from the central hoppers became difficult. As a result, the strategy was changed to only pick up balls from the corner hoppers, and release using the side ramp only. During the final competition, there were two instances where Pluto aligned properly with the gameboard, but the ball overshot and went into the opponent s playing field. To reduce the speed of the ball upon exit of the ramp, electrical tape was added at the end to make the surface rougher, fixing the issue Debugging Environment Using the LCD It was not practical to connect the laptop to the Arduino board during Pluto s run, because the USB cable could interfere with the movement of the robot and cause a hassle for the team members. Therefore, gathering information through the serial monitor wasn t always feasible. In addition, sometimes the sensors would output different values when the Arduino board was powered via the USB cable rather than on board power. Hence, the LCD screen was introduced to help in troubleshooting problems that arose and to provide feedback about the testing trials. 32

37 Some of the major uses for the LCD screen was outputting the readings of the ultrasonic sensors and the IR reflectance sensors. It was also used during the competition to get feedback about the entered hopper positions as described in section General Process for Circuits If a problem was encountered during testing and it was determined to be a circuits issue, various techniques were employed to find the root cause and to fix the issue. Some techniques included the use of a multimeter to check the quality of the connections on the protoboards, the voltage supplied to and the output voltage of different circuit elements, and using the LCD display to check the readings from the sensors. Occasionally, if there was a concern that any of the components were damaged or initially defective, new samples were acquired and tested to rule out all other causes of the issue Powering the Arduino Another issue which arose during the final weeks of the project was the sudden reset of the Arduino microcontroller while in the middle of a trial. When it reset, it returned to the beginning of the program and executed the calibration turn once again. The Arduino would consistently reset itself after depositing the first ball and moving away from the gameboard, and at other random instances during the game. The nature of the reset depicted a problem with the power supply to the board. The battery caps were found to be loose, and thus were replaced by new ones, and the battery holders were replaced with new ones too. Since the problem persisted, the barrel clip was removed, and the board was powered via the Vin pin. This change worked for a few trials, after which the board returned back to resetting itself. To solve the issue, a rechargeable battery pack was used to power the Arduino via the USB cable and the USB port on the microcontroller, replacing the AA batteries used to power the Arduino via barrel clip Implementation of Circuits Preliminary testing for every circuit component was conducted within the first month of the project, making use of breadboards. This strategy allowed the team to observe the outputs of each circuit, test the design and make improvements, and provided a simple and effective platform for debugging any issues related to the wiring of the circuits. Once tested numerous times individually and after integration with the microcontroller and electromechanical sub-systems, all circuits were transferred to protoboards and soldered according to appropriate circuit diagrams. One of the major challenges encountered during the implementation process was the robustness of the wire connections made on the protoboards, and in particular, the use of solid wires for all connections. There were many incidents where the wires would snap from being turned too sharply or from the handling of Pluto during transport. Additionally, wires sometimes came out of the protoboards, despite being soldered in and checked numerous times. This issue was solved by using stranded wires for the majority of electrical connections. Not only did this change make 33

38 all of the connections more robust, it also made it easier to organize and move the wires around since stranded wires can be easily bent without damaging the core, unlike solid wires Organization of Components Electromechanical Sub-system Prior to constructing the robot, numerous sketches of individual systems and components were made to help develop the design. These sketches were modified and kept up to date, keeping track of adjustments and improvements. Referring to developing designs provided information on the flexibility of the design: where could a feature be moved or changed to accommodate another system? How critical is a dimension to the design? Gaining more experience in the design process and looking at past work and justification for decisions helped to further develop the rest of the robot. Additionally, figuring out where the Arduino board and circuits could be housed was very important. Some pre-planning was completed to ensure secure and safe mountings of critical and sensitive components. The original design had a protective housing for the Arduino, batteries and for any sensitive sensors. However, these housings restricted access to the components which were often handled and worked with. Due to this, machine screws and nuts were used to mount components so they could be easily removed if needed. Accessibility was more critical than originally thought and greatly influenced design decisions Circuit Sub-system As the various systems were being integrated together, the number of circuit components increased. In order to organize the circuits and wires, appropriate labels were attached to all of the wires located on Pluto. This reduced time spent debugging problems that arose and also helped if any wiring had to be changed or removed, as was the case with the ultrasonic sensors and the servo motor for the gate. In addition, all of the wires related to the same circuitry elements were taped together with electrical tape which added a new level to organization of circuit components and made it easy to trace the wires from the protoboards Microcontroller Sub-system The organization of the code was essential for fast access to the code for bench-testing components and for keeping track of trials. Each piece of code used to program a component is saved in its own file, with a date-stamp, a short summary of what the code does and comments throughout the file. By doing this, it was easy to troubleshoot a faulty component by going back to the bench-testing code and trying it out on its own. For big programs that encompass several tasks, different versions of the program were saved with time-stamps and a short summary of the changes made from one version to another. This secured versions of the code to go back to if the current version experiences issues or if different algorithm needed to be tested simultaneously. 34

39 The final piece of code that was uploaded onto the Arduino board for the competition was divided into states as outlines in section 5.4. This allowed a complex program to be organized in an easy-to-follow steps and helped in visualizing the code Gameplay strategy In the proposal, it was stated that the optimal solution would be setting up a camera to capture the state of the gameboard and decide on the respective move. If this was not possible due to prioritizing navigation and/or time constraint, then a simple touch sensor would be installed to check the vacancy of the top row in order to determine whether or not the column is filled. However, this design was based on navigating backwards to the gameboard - i.e. a back release ramp and approaching the gameboard along a straight path. Since navigating to the gameboard was changed to a side-approach involving many timed turns, due largely to the absence of ultrasonic sensors, the touch sensors would not be useful anymore as no direct pressure would be applied to them. Additionally, the progress of other teams indicated the matches would be largely focused on robots navigating through the playing field and trying to play a ball, as opposed to a strategic connect 4 match. Therefore game strategy was not prioritized, and hence not implemented. 7 - Project Management Project Schedule A proposed schedule was established for project proposal that outlines the work for all team members, it can be seen below in Figure 21. When preparing the schedule, two things were considered. Firstly, most tasks would take more than the time planned for them. Some ideas would inevitably change because of practicalities while testing, unforeseen difficulties, and acquiring better judgement due to the experience gained in the process. Secondly, if too much time is assigned to a task, the motivation to finish it quickly would diminish. Therefore a balance had to be sought in order to assign a manageable short time for a task, and still leave a buffer area in anticipation of any difficulties. The project plan went mostly as planned. Further details are provided below. The proposed milestones and the accomplishments are outlined in the following table Table 1: A comparison between the proposed plan and what was accomplished Milestone Proposed plan Accomplished Progress Functional base that can Pluto followed a line detection algorithm. It kept Evaluation I move, detect nearby scanning with the ultrasonic sensor, and turned left Progress Evaluation II objects and react to them Accepting hopper position from the user. Be able to align with hoppers, retrieve a ball, whenever it detects a nearby object. Pluto was able to go from one coordinate to another, avoid obstacles and approach (but not align well to the gameboard). It was able to align with the corner hoppers and retrieve a ball. 35

40 Progress Evaluation III avoid obstacles and navigate to gameboard. Fully functional with the capability of playing a 7- minute game. Pluto could go around to all four hoppers around the playing field, aligning with hoppers and gameboard. Although it could only align with one arrangement of the central hoppers. Alignment with gameboard needed improvement. Sensing the gameboard was not implemented. Figure 21: Gantt chart of the proposed project plan Electromechanical sub-system The first base that was built was meant to be a prototype, and another base was to be built after extensive testing. However, since the prototype performed as required and changes in the proposed design were made, there was no apparent reason to rebuild the base. This saved some time from the schedule. Before progress evaluation II, the electromechanical system was supposed to be completed (see Figure 21). However, this proved to be too ambitious. The base, 36

41 arm and gripper were completed by this point. However, only a prototype ramp was being tested, and a mechanical solution was being brainstormed to help align with the hoppers. By progress evaluation III, this subsystem was completed. Prior to the design competition, the DC motors that controlled the wheels for primary locomotion was replaced, and all components were tested Electrical sub-system According to the proposed plan, the electrical sub system needed to be completed by progress evaluation as well, with integration and testing time that last for two weeks. However, by progress evaluation II, there were still breadboards on Pluto, and there was no stop button yet. But before progress evaluation III, all breadboards were converted to protoboards and two flip switches were added to stop the wheels and the arm Microcontroller sub-system This sub-system is the one that deviated from the plan the most. According to the proposed plan (see Figure 21), navigation was supposed to be completed within the first week of February, followed by aligning with the hoppers, retrieving the balls and dropping them off through the following two weeks. However, navigation was the hardest part for this sub-system. Navigation from a point to another on the playing field was completed by progress evaluation II, along with aligning to the corner hoppers. However, aligning to the center hoppers was harder, and therefore took more time. By progress evaluation III, Pluto was able to align to both central hoppers as well, but only when put in a specific arrangement. It could also align to the gameboard and drop balls in. There was some dependence on ultrasonic sensors, but since they failed to work, more time had to be put in order to navigate Pluto without using proximity sensors. By the preliminary competition, Pluto was able to align to all hoppers and play a full 7-minute game Division of Labour The division of labour is outlined in the Gantt chart in Figure 21. Each member of the team is responsible for their respective subsystem. Upon integration, all members of the team came together to understand the role each part plays in the integration process. After which they troubleshoot together and brainstorm suggestions and ideas for improvement Budget All components that were included in the final version of Pluto were accounted for and their prices were outlined. The final cost of Pluto is $ See Table 2 for the detailed budget, including taxes and shipping. 37

42 Table 2: The price of all components on Pluto Item Price Quantity Subtotal Line Sensor LCD display Pushbuttons Flip switch Arduino Mega Battery snap Battery Battery holder Battery Pack Protoboards H-bridge H-bridge holder Wires (per ft) Solder Servo motor (black) Servo motor (blue) Silver motor Yellow wheel Ball Caster Motor bracket Screws and nuts (for wheels) Screw Nuts Screw (square head) Sheet metal (0.2 mm) (per cm2) Sheet metal (1.5 mm) Bass wood (per inch 3 ) Roof (per inch 3 ) Pine wood (per inch 3 ) Plexiglass (per inch 2 ) Base (per inch 3 ) Total $

43 8 - Conclusion The final design presented by Monsters, Inc. resulted from substantial background research, careful selection of conceptual ideas, testing of various prototypes and implementation of the three interrelated sub-systems in the limited amount of time provided. As shown in the final competition, the team managed to demonstrate a fully functional autonomous robot which was able to play a game of connect 4 and receive a second place overall finish at the final Robot Competition in the AER201 class, The design of Pluto incorporated all of the team values and aimed to produce a highly accurate and consistent robot without compromising effectiveness and speed. These goals were accomplished by using two-wheel direct drive to minimize the slippage, implementing a rotating gripper to allow for some freedom while retrieving the ball, using a rotating arm to elevate the ball quickly, moulding the base into the shape of the hoppers to align easily and using IR reflectance sensors to navigate around the playing field. In the course of the construction of the robot, the team encountered a variety of issues related to the implementation of the initial design and had to go through multiple iterations of designs to develop a winning robot. This course helped develop new skills related to troubleshooting, fixing problems related to all three subsystems and producing a simple, reliable and effective design. Brainstorming problems ahead of time, developing checklists and keeping design notebooks ensured the team was organized and had the means necessary to successfully finish the project. Apart from the knowledge and effort that was brought in this course, the main key to success was still related to the effective team dynamics. Team collaboration, combined with persistence, genuine desire to succeed and all of the positive qualities of every member of the group made it possible to not only complete this project, but also leave plenty of positive memories behind us. 39

44 9 - Works Cited [1] "GearBest," [Online]. Available: [2] "High Performance 5 x 7cm Double Sided Glass Fiber Prototyping PCB Breadboard for DIY Project - 5PCS," [Online]. Available: [3] Texas Instruments, "QUADRUPLE HALF-H DRIVERS," September [Online]. Available: [Accessed 9 January 2015]. [4] Arduino, "Arduino Board Mega," [Online]. Available: [Accessed 26 March 2015]. 40

45 Appendix A: The Final Design: Pluto The roof covers the lower electrical components to provide a form of protection. It is also another platform to mount components. The external battery supply powered the Arduino via the USB port. It outputted 5V at 1A of current. Battery pack for the motors consisted of 9 AA batteries, putting out a total voltage of 12.5V. Figure 22: Isometric side view of Pluto showing key components of the design. The power supplies can be seen clearly in this image. Additionally, the path of the ball can be mapped out. 41

46 LCD display used initially for debugging purposes and then as a user interface when inputting hopper positions Pushbuttons to input hopper locations Pushbuttons used for inputting hopper locations Gears to aid in turning the chassis prior to gameboard alignment Figure 23: Angled front and back views of Pluto 42