Robo Golf. Team 9 Juan Quiroz Vincent Ravera. CPE 470/670 Autonomous Mobile Robots. Friday, December 16, 2005

Similar documents
Part of: Inquiry Science with Dartmouth

Final Report Metallocalizer

Roborodentia Robot: Tektronix. Sean Yap Advisor: John Seng California Polytechnic State University, San Luis Obispo June 8th, 2016

Woody: Roborodentia 2011 Robot

Machine Intelligence Laboratory

Robot Control. Robot Control

JAWS. The Autonomous Ball Collecting Robot. BY Kurnia Wonoatmojo

Autonomous Robot Control Circuit

Your EdVenture into Robotics 10 Lesson plans

C - Underground Exploration

understanding sensors

CSC C85 Embedded Systems Project # 1 Robot Localization

Range Rover Autonomous Golf Ball Collector

CURIE Academy, Summer 2014 Lab 2: Computer Engineering Software Perspective Sign-Off Sheet

Vision Ques t. Vision Quest. Use the Vision Sensor to drive your robot in Vision Quest!

Robotics Workshop. for Parents and Teachers. September 27, 2014 Wichita State University College of Engineering. Karen Reynolds

A - Debris on the Track

A - Debris on the Track

A - Debris on the Track

The Nomenclature and Geometry of LEGO

Robodyssey Mini Roach

MESA Cyber Robot Challenge: Robot Controller Guide

Lab book. Exploring Robotics (CORC3303)

FLL Coaches Clinic Chassis and Attachments. Patrick R. Michaud

Robot Programming Manual

Dipartimento di Elettronica Informazione e Bioingegneria Robotics

Mindstorms NXT. mindstorms.lego.com

Deriving Consistency from LEGOs

GE423 Laboratory Assignment 6 Robot Sensors and Wall-Following

Darling, Robot for Roborodentia 2018

2.4 Sensorized robots

The light sensor, rotation sensor, and motors may all be monitored using the view function on the RCX.

University of Florida. Department of Electrical Engineering EEL5666. Intelligent Machine Design Laboratory. Doc Bloc. Larry Brock.

A servo is an electric motor that takes in a pulse width modulated signal that controls direction and speed. A servo has three leads:

Kulicke & Soffa 4700AD Instructions A.Atalar (April 2017)

Department of Electrical and Computer Engineering EEL Intelligent Machine Design Laboratory S.L.I.K Salt Laying Ice Killer FINAL REPORT

Lab 1: Testing and Measurement on the r-one

GRAFFITI + Robots as Artists

LEGO Mindstorms Class: Lesson 1

Western Kansas Lego Robotics Competition April 16, 2018 Fort Hays State University

An Introduction to Programming using the NXT Robot:

Capstone Python Project Features

Team Description Paper

Robotics using Lego Mindstorms EV3 (Intermediate)

Robot Olympics: Programming Robots to Perform Tasks in the Real World

Proximity-Sensor Counter Installation Instruction Model: MRC-PRO

Worksheet Answer Key: Tree Measurer Projects > Tree Measurer

Engineering with EV3 Workshop

1 of 5 01/04/

Figure 1. Overall Picture

Ev3 Robotics Programming 101

Team #3691 FLL Technical Manual. Ashburn Robotics NXTreme (Team#3691)

An External Command Reading White line Follower Robot

Overview of Challenges in the Development of Autonomous Mobile Robots. August 23, 2011

Final Review Powerpoint

Tutorial: Creating maze games

COSC343: Artificial Intelligence

ADJUSTMENT PROCEDURE I/S-TURBO REV 1.X

04. Two Player Pong. 04.Two Player Pong

Game Maker Tutorial Creating Maze Games Written by Mark Overmars

Final Report Grasshopper Nicolai Hoffman

acknowledgments...xv introduction...xvii 1 LEGO MINDSTORMS NXT 2.0: people, pieces, and potential getting started with the NXT 2.0 set...

Agent-based/Robotics Programming Lab II

Sten BOT Robot Kit 1 Stensat Group LLC, Copyright 2016

ARMFIELD OPEN CHANNEL FLUME OBSTACLES AND DYE INJECTION SYSTEM DANIEL CAHN AND JEAN DORIOT SUMMER 2004

Automatic Headlights

Embodiment from Engineer s Point of View

Line Detection. Duration Minutes. Di culty Intermediate. Learning Objectives Students will:

OWNER S MANUAL VENDING MACHINE

Topic 1. Road safety rules. Projects: 1. Robo drives safely - page Robo is a traffic light - - page 6-10 Robo is a smart traffic light

Parts of a Lego RCX Robot

Levels of Description: A Role for Robots in Cognitive Science Education

Assembly instructions

The Robot Olympics: A competition for Tribot s and their humans

Nhu Nguyen ES95. Prof. Lehrman. Final Project report. The Desk Instrument. Group: Peter Wu, Paloma Ruiz-Ramon, Nhu Nguyen, and Parker Heyl

Part 1: Determining the Sensors and Feedback Mechanism

Robot Design.

LINE MAZE SOLVING ROBOT

Patterns of Building LEGO MINDSTORMS Robots

University of Florida Department of Electrical and Computer Engineering EEL 5666 Intelligent Machines Design Laboratory GetMAD Final Report

7878 K940. Checkpoint Antenna. Kit Instructions. Issue B

Some prior experience with building programs in Scratch is assumed. You can find some introductory materials here:

JHU Robotics Challenge 2015

STOP! READ THIS FIRST

I.1 Smart Machines. Unit Overview:

Students will design, program, and build a robot vehicle to traverse a maze in 30 seconds without touching any sidewalls or going out of bounds.

Thanks to Autocheck function, it is possible to perform a complete check-up of the robot thanks to a stepby-step

G54GAM Lab Session 1

Robot Class. Are all robots created equal?

Thomas S. Narro David Zucker Darren Garnier 4/05. Copyright 2005 CPO Science

Table of Contents. Sample Pages - get the whole book at

Adjusting Backlash on Sherline handwheels

Medb ot. Medbot. Learn about robot behaviors as you transport medicine in a hospital with Medbot!

INSTALLATION INSTRUCTIONS

John Duffyʼs Manual Mill Gadget. Build Instructions

OX CNC. Mechanical Assembly Instructions. S.A. Brown & Maker Store

Chassis & Attachments 101. Chassis Overview

SAFETY. Injury hazard

EdPy app documentation

Week Lesson Assignment SD Technology Standards. SPA Handout. Handouts. Handouts/quiz. Video/handout. Handout. Video, handout.

Transcription:

Robo Golf Team 9 Juan Quiroz Vincent Ravera CPE 470/670 Autonomous Mobile Robots Friday, December 16, 2005

Team 9: Quiroz, Ravera 2 Table of Contents Introduction...3 Robot Design...3 Hardware...3 Software... 6 Deficiencies And Bugs...8 Contest Results...8 Conclusion... 9 Acknowledgments... 9 Source Code...10

Team 9: Quiroz, Ravera 3 Introduction The final competition is a game of robot golf. This is a two robot challenge on which the goal of each robot is to collect golf balls and deposit them into a ball well, marked as a black circular area in the middle of the playing field. The robots perform on a flat, white field. The golf balls to be collected are pre-placed on the field with six balls on each side of the field. The general rules of the contest are that robots play against each other in a double elimination format competition in games that last 2.5 minutes. Thus, after two consecutive losses a robot is eliminated from the tournament. The design chosen for our robot was to use a set of wheels on the front of the robot, placed on the entrance to the robot s ball storing space. By doing so the robot keeps the balls inside by keeping the capturing wheels running forward. Incoming balls are pulled into the robot by the forward force of the wheels. On the other hand, the golf balls are released by making the wheels on the front turn backward. Furthermore, we added a trolley wheel in the back of the robot. This wheel was used instead of two regular wheels in order to reduce friction when turning, and thus improve the turning of the robot. The robot s controller consisted of a wandering behavior with obstacle avoidance, which searched for the black goal at the center of the field. Robot Design Hardware The majority of the time worked on this project was spent on the hardware design. The initial robot that had been used on all of the previous labs was discarded and we created a new one from scratch. Figure 1 shows one of the previous designs of the robot s hardware design. Numerous changes were made to the design over the last few weeks. We believed that the hardware design was crucial to the performance of the robot. Indeed, hardware deficiencies found on the design were detrimental to the optimal performance of the robot.

Team 9: Quiroz, Ravera 4 Figure 1: Previous design of robot. This shows the robot s center made hole in order to capture golf balls. The robot was made as large as possible to store many golf balls. The robot s components were two motors for locomotion, one motor for the capturing balls mechanism, one board for the robot s controller, two reflective optosensors to find the goal, three wheels for steering, two wheels for capturing balls, and Lego pieces for the robot s main structure. The robot was designed with an empty core in order to have space to store the golf balls. Figure 2 shows a picture of the final robot design. On the robot s center the balls were collected and stored. We made the robot tall and long in order to maximize the number of balls that could be collected inside of the robot at any time. The previous design of our robot used rear wheel drive, it did not turn effectively, and it got stuck numerous times against the side walls and in corners. In order to solve this problem we decided to use front wheel drive on the robot and adding a third trolley wheel on the back. By doing so the robot not only was able to turn effectively, but it also minimized the amount of time needed to turn, the turns were a lot more stable, it minimized friction when turning, and this in turn minimized the amount of energy used by the robot for turning.

Team 9: Quiroz, Ravera 5 Figure 2: Final robot design. The robot was made bulky in order to make the robot robust and to prevent the robot from falling apart on the middle of the competition. The wedges provided on the Lego Kit were used to strengthen the coupling of Lego pieces. Furthermore, we removed any gaps on the robot in order to prevent such gaps from providing weak points where the robot could break off due to an external force or pressure. The design to capture the balls was to use a couple of wheels placed over the entrance of the robot s ball storing space in order to be able to capture balls encountered when wandering around the field, but capable of keeping captured balls from getting out. Such a mechanism would have the wheels turn, with the power provided by a third motor, in the forward direction. The capturing wheels were placed high enough to lightly pull balls into the robot by the force of the spinning wheels. If any of the captured balls attempted to get out they would be pushed back by the opposing force of the turning wheel from within the robot. This is a highly effective method, for the capturing and retention of captured wheels is done autonomously by turning the motor of the capturing wheels on the forward direction. Furthermore, releasing balls is done as effortlessly as capturing the balls. The release of the captured balls is done by reversing the direction of the capturing wheels. Thus, by having the capturing wheels spin in reverse, the balls are lightly pushed out of the robot by the force of the spinning wheels. The hole in the center of the field was located using two reflective optosensors located on each side of the robot, on the robot s tail. Figure 3 shows a side view of the robot with the reflective optosensor located at the tail of the robot with the orange cable used to connect its input into the robot s controller.

Team 9: Quiroz, Ravera 6 Figure 3: Side view of the robot. The reflective optosensors were placed on the tail of the robot on each side to find the center goal. Software The software design consisted of multiple behaviors running in parallel, with each behavior controlled by a process thread. The main behaviors in the robot were obstacle avoidance, wandering, identify goal, and sensor polling. The obstacle avoidance was based on the principle of meta-sensing. Meta-sensing consists of keeping a history of the number of times the touch sensors are triggered. So if the touch sensors are constantly triggered over a few seconds, then it is assumed that the robot is stuck in a loop, such as stuck in a corner. Getting stuck in corners is an example of emergent behavior, that is, the dynamics of obstacle avoidance behavior and the environment create a scenario unforeseen during the development of the robot s controller. In addition to meta-sensing, the robot turned by a random degree every time its touch sensors were triggered. It is not possible to know the exact location of the robot at any time, thus the best thing to do is to turn by a random angle in order to cover as much of the playing field as possible. Furthermore, during the testing of the robot we found that the hardware design, specifically the design of the touch sensors mechanism, made the robot prone to getting stuck if it hit an obstacle at an awkward angle. During these cases the robot would collide against an

Team 9: Quiroz, Ravera 7 object, but the sensors would not be triggered. In order to solve this problem we added a timer. This timer made the robot turn at a random angle every 7 seconds if the sensors had not been triggered within that time span. The addition of this feature was based on the idea that given the robot s wandering behavior the robot would collide against an object within 7 seconds. If the robot did not collide with anything in this allotted time, then most likely it was stuck. Furthermore, this feature added randomness to the robot s wandering behavior. The wandering behavior of the robot made the robot mode as straight as possible. Then if the robot collided against an object it would turn by a random degree on a random direction. The results from the previous labs showed that the most area was covered when moving on a straight line. So we based our wandering on this observation. The center goal was found with the use of two reflective optosensors. The reading of the reflective optosensors was taken over the white playing field and over the goal. These two readings were then used to obtain a threshold value to determine whether the robot was over the goal or over the playing field. The find goal behavior constantly checked the readings from the reflective optosensors. If the sensor readings were over the threshold, then the robot would inhibit the wandering behavior. The robot would stop, and it would back up until both reflective optosensors sensors were out of the goal. By doing this we ensured that the head of the robot was on the middle of the goal and the balls be released on the center instead of outside the goal. After the robot s head was on the middle of the goal, the robot would set the capturing wheels in reverse and would continue going backwards. The backward movement made the balls inside the robot move forward while the capturing balls pushed the balls from inside the robot into the goal area. The robot would then move forward to capture any balls that might have been released outside of the goal. If the robot did not find the goal within three seconds, then it was assumed that the robot had missed the goal, so it would continue with its wandering behavior. Otherwise, the robot would repeat the release balls procedure. After releasing the balls for a second time the robot would turn left and continue wandering. At the beginning of the game the robot would try to align itself with the balls. We accounted for three of the four possible directions that the robot could be facing at the beginning of the game. The three cases were when the robot was facing the balls and when the robot was facing any of the two walls. The case where the robot is facing the field but not the balls was not accounted for. The robot found the balls by moving forward for a few seconds. If the touch sensors were not triggered, then it was assumed that the robot was facing the balls, so the robot would continue moving forward. If the sensors were triggered, then the robot would turn 90 degrees to the left, then it would move forward again. If the touch sensors were triggered once again within a few seconds, then the robot would turn 90 degrees to the left once again, then it would move forward towards the balls.

Team 9: Quiroz, Ravera 8 Deficiencies And Bugs During the software and hardware development phases it was found that it was impossible to account for every possible case the robot might encounter. As such, we concentrated on the goals which enabled the robot to complete the task, including finding the goal, aligning itself with the balls at the beginning of the game, and obstacle avoidance. The hardware deficiencies were a major hindrance on the robot s performance. The touch sensors on the robot were very unreliable. First of all, the robot did not detect side collisions, something that would have simplified the process of aligning the robot with the balls at the beginning of the game. Furthermore, the ability to detect side collisions would have protected the robot would hard collisions against the walls, and it would have protected the robot s wheels. The robot s wheels needed to be protected because otherwise the robot could wedge itself against the walls in such a form that the robot would not be able to continue moving forwards. This deficiency was solved by adding the stuck timer which made the robot backup and turn at a random angle if the touch sensors were not triggered on 7 seconds or less. The robot was made to have front wheel drive with a third wheel on the back to enable the robot to turn effectively with minimal effort. Indeed the robot did turn, but a lot of times the robot would turn a lot even if the intended turn degree was small. Thus, while the hardware design did make the robot very effective on turning, this same flexibility made it very hard to calibrate the turning rate of the robot. Due to the hardware design we also found that the gears did not line up very well. This made the robot have a tendency to move towards the left. We tried to fix this by making the right wheel turn at a greater speed, but it was not possible to make the robot move in a straight line perfectly and constantly. Contest Results During the contest the robot did not perform as well as expected. We knew that there were cases which we could not account for, but we did not expect everything to go wrong during the contest. On the first run the robot s touch sensors went over the wall, so that when the robot tried to backup, its sensors were wedged over the wall, making it impossible to move. On the second run the robot was able to collect five out of the six balls after only 10 seconds, yet as it was approaching the center goal it did a random turn and its back wheel collided against the other robot. Consequently, the robot s wheel fell off. This made the robot tilt upwards, so that all of the collected balls escaped through the front. This in turn made it impossible to collect any balls. Furthermore, the reflective optosensors on the back fell off due to the missing wheel on the back, so that it was impossible to find the goal as well. The results of the robot on the contest were most disappointing. The hardware design made the robot very efficient for collecting balls, keeping those balls inside the robot, and releasing them.

Team 9: Quiroz, Ravera 9 Yet, this hardware design also had the disadvantage of not being robust and stable, as the results on the final contest showed. Countless hours were spent on the design, yet it seems that the simpler and smaller robots outperformed our robot. Conclusion This project was a great learning experience. The design of the robot showed us that things usually don t work out as you expect them to, even if the software is correct. It is impossible to account for every possible case that the dynamics of the environment presents. Thus, the best strategy was to create simple behaviors in the controller, which when coupled with each other and the environment produce complex behavior. We think that in this project we tried to do too much on the hardware design. It was the simplest robots which performed the best. Thus, if we could do the project over again we would design a robot which was smaller, yet robust, flexible, and sturdy! Regardless of the fact that the contest results were disappointing, we learned a lot about the process involved in designing a robot, that is, in designing an autonomous entity which interacted with the world and which was greatly constrained by its effectors and actuators. Acknowledgments We are greatly thankful that this semester is over, even though it was a lot of fun. We want to thank Dr. Nicolescu for her patience and advice, over the course of the semester, on hardware and software design. Finally we would like to thank Erick Fritzinger for being our external advisor.

Team 9: Quiroz, Ravera 10 Appendix Source Code /*************************************************** Team 9: Vincent Ravera, Juan Quiroz Final Contest: Robo Golf CPE 470/670 ***************************************************/ // GLOBAL VARIABLES float _timer; float _timer2; float _stucktimer; int bumps=0; int start=0; // Sensor variables int WALL_SENSOR=3; int GOAL_SENSOR=2; int RIGHT_SENSOR=10; int LEFT_SENSOR=11; int RIGHT_MOTOR=2; int LEFT_MOTOR=0; int SCOOP_MOTOR=3; int SCOOP_SPEED=35; int GOAL=230; int sensor; int prevsensor; int resent_hits; // TIMER FUNCTIONS void reset_timer2() _timer2 = seconds(); float timer2() return seconds() - _timer2; void reset_timer()

Team 9: Quiroz, Ravera 11 _timer = seconds(); float timer() return seconds() - _timer; void reset_stucktimer() _stucktimer = seconds(); float stucktimer() return seconds() - _stucktimer; /** * Check sensors thread. */ int check_sensors() while (1) if (digital(10)) sensor=10; reset_stucktimer(); else if ( digital(11) ) sensor=11; reset_stucktimer(); int goalleft() return (analog(wall_sensor)); int goalright() return (analog(goal_sensor)); void stop() off(left_motor); off(right_motor); void scoop()

Team 9: Quiroz, Ravera 12 motor(scoop_motor, SCOOP_SPEED); while(1) ; /** * This goal checks to see if the robot is over the black goal center. * This function constantly checks the readings from the light sensors * on the robot. If the sensors reach a threshold value then the robot * releases the balls. */ void check_goal() while ( 1 ) // If the robot is over the black hole if ( goalleft() >= GOAL && goalright() >=GOAL ) beep(); stop(); // Go backwards until the head of the robot is on the // center of the hole. motor(left_motor, -40); motor(right_motor, -45); while ( goalleft() > GOAL && goalright() > GOAL) ; motor(left_motor, -40); motor(right_motor, -45); sleep(0.20); // Reverse direction of capturing wheels and continue // in reverse to release all of the balls motor(scoop_motor, -50); sleep(2.0); motor(scoop_motor, 50); of the // Go forward again to capture any balls that missed the center // hole. reset_timer2(); while ( goalleft() < GOAL && goalright() < GOAL && timer2() < 3.) ; // if the goal was found within 3 seconds then repeat the release // balls if ( timer2() < 3. ) motor(left_motor, -40); motor(right_motor, -45); sleep(0.20); motor(scoop_motor, -50); sleep(2.0); motor(scoop_motor, 50);

Team 9: Quiroz, Ravera 13 // Turn away from the center and continue to wander left(); sleep(0.3); // If only the left side of the robot is over the goal else if ( goalleft() >= GOAL ) // turn right and go forward right(); sleep(0.2); // If only the right side of the robot is over the goal else if ( goalright() >= GOAL ) // turn left and go forward left(); sleep(0.2); // Move forward thread void move_forward() int stopf=0, start=0; int init=0; while (1) if( start_button() ) init=1; if ( stop_button() ) stop(); // If the game just got started if ( init == 1 ) // find out which direction the robot is facing and // turn towards the balls sleep(0.3); // if facing wall, need to turn 90 if ( sensor > 0 ) beep(); backward(); sleep(0.15);

Team 9: Quiroz, Ravera 14 left(); sleep(0.1); sensor=0; sleep(0.3); // if facing 2nd wall, need to turn 180 if ( sensor > 0 ) beep(); backward(); sleep(0.15); left(); sleep(0.1); sensor=0; //While the sensors are not triggered while (!sensor ) // if the sensors are not triggered within 7 seconds // then we're stuck against a wall if ( stucktimer() > 7. ) // do random avoid and wander random_avoid(); reset_stucktimer(); // if the stop button is pressed exit if ( stop_button() ) stopf=1; break; // Exit routine if ( stopf == 1 ) stop(); stopf=0; // Obstacle avoidance ***************************************** // Based on the principle of meta-sensing // if right sensor triggered if ( sensor == 10 ) if ( timer() < 4. ) // if more than 5 bumps in less than 4 seconds then we're // stuck in a corner if ( bumps >=5 )

Team 9: Quiroz, Ravera 15 // do random avoid random_avoid(); reset_timer(); bumps=0; else turn_left(); reset_timer(); bumps++; // bump hit else turn_left(); reset_timer(); bumps=1; sensor=0; fd(left_motor); fd(right_motor); sleep(0.5); // if left sensor triggered else if ( timer() < 4. ) // if more than 5 bumps in less than 4 seconds then we're // stuck in a corner if ( bumps >=5 ) random_avoid(); reset_timer(); bumps=0; else turn_right(); reset_timer(); bumps++; else // bump hit turn_right(); reset_timer(); bumps=1; sensor=0; fd(left_motor);

Team 9: Quiroz, Ravera 16 fd(right_motor); sleep(0.5); // End of Obstacle avoidance ****** /** * Random avoid function. Takes a turn in random direction * by a random degree. */ void random_avoid() backward(); sleep(.35); beeper_on(); if ( random(2) == 0 ) left(); else right(); sleep((float)random(50)/100. +.6); beeper_off(); // MOTOR AND STEERING FUNCTIONS void forward() motor(left_motor,100); motor(right_motor,60); void right() fd(right_motor); bk(left_motor); void left() fd(left_motor); bk(right_motor); void backward() bk(left_motor); bk(right_motor); void turn_left() backward(); sleep(0.20); fd(left_motor); bk(right_motor);

Team 9: Quiroz, Ravera 17 sleep(0.18); if ( random(4) == 0 ) sleep((float)random(23)/100.+.20); else sleep((float)random(20)/100.+.30); fd(right_motor); fd(left_motor); void turn_right() backward(); sleep(0.20); fd(right_motor); bk(left_motor); sleep(0.2); if ( random(4) == 0 ) sleep((float)random(22)/100.+.15); else sleep((float)random(25)/100.+.35); fd(left_motor); fd(right_motor); // DRIVER void main() //Clear screen printf("\n"); prevsensor=sensor=0; resent_hits = 0; // Start sensors thread start_process(check_sensors()); sleep(0.3); while ( 1) // if the start button is pressed, start the forward thread if ( start_button() ) // start the capture balls motor

Team 9: Quiroz, Ravera 18 start_process(scoop()); // start the check goal thread start_process(check_goal()); start=1; // move forward // reset timers reset_timer(); reset_stucktimer(); // Start wandering behavior start_process(move_forward()); break;