Final Project Proposal - DOC by La65QzLQ

VIEWS: 8 PAGES: 8

									   Final Project Proposal

       Keith Solberg



          tennisfan




        Instructors:
         Dr. Arroyo
        Dr. Schwartz

         TAs:
      Mike Pridgen
     Thomas Vermeer

           Website:
http://plaza.ufl.edu/ksolberg/
Abstract
       This report is on the development of my IMDL robot, tennisfan. The development of this
robot will be explained through its various design stages as well as any additional testing. This
robot was developed to aid in the act of playing tennis, to assist with supplying balls to the
players on the court, both launched at the player from the opposing side and lobbed to the player
from off the court so the person can play with a friend without having to constantly run after
loose balls.


Introduction
        This project, tennisfan, was developed for implementation on a tennis court, to throw
balls to the players as well as traverse the court to meet the needs of those player(s) that are
playing or practicing tennis. Through the use of motors, the mechanism will drive to necessary
points on the court, and once the device has stopped moving it will determine the direction to
throw or launch a ball, through the use of some mechanical design. Through this paper I will
explain the rough development of the mechanical design along with the simple algorithms that
the device uses to achieve its objectives.

Integrated System
        The overall schematic of how the processor integrates with all the components is shown
in the following diagram.




                           Figure 1. Overall System Block Diagram
Essentially, the processor receives information from the wireless transmitter that corresponds to
a particular action then uses a variety of circuits and logic algorithms to move itself or other
components to accomplish that task. All algorithms, which involve moving around, line finding,
obstacle avoidance or ball launching, have a series of steps that they will each consist of, and
will be running whenever the processor determines to implement them. A picture of the
electronics for the system is shown below.




                          Figure 2. Electrical Schematic on Platform
All electronics are encased in one area to help minimize wires all over the platform, and makes
everything small and compact so it can be easily hidden and protected from objects (such as
tennis balls).

Mobile Platform
        The entire platform is situated on a 16” x 24” piece of ¾ “ plywood. The platform itself
will carry everything, which includes all the electronics, the tennis balls, the launcher, motors,
batteries and processor and the entire assembly is shown below.
                             Figure 3. Overall tennisfan Assembly
        In order to move the robot around, two DC motorsi were implemented in the rear portion
of the vehicle and differential steering was used to drive and turn. Those motors were given
signals by a motor controllerii that would take in servo-style inputs (PWM signals) and produce
the necessary signal to drive the motors. However, since those motors and controller ran off a
12V power supply, optical isolators had to be used to separate the motor signals from the
microcontrolleriii to prevent any possible damage. When the entire system was built the motors
ended up having a top speed of approximately 5ft/sec, which was not as high as we would have
liked, but due to time constraints it was not feasible to get new motors in time. At the front of
the vehicle two ball castersiv were placed at the corners, which would provide low-friction
movement so the back wheels could drive everything.


Actuation
        The actuators on the assembly have a variety of tasks, but the primary goals of all the on-
board actuators deal with launching the tennis balls one at a time, on command. To do this the
primary actuator is the tennis ball launcherv itself. This is essentially comprised of two wheels
spinning in opposite directions that get a firm grip on the ball and launch it at a significant speed
in whatever direction it is pointed in. This device was chosen due to its industrial size and, most
importantly it’s low cost, both in time and price. In order to activate this launcher we have to go
through several components, however. Since the device, when powered up from the 12V
batteryvi, draws an excess of 20A, a circuit was set up so that upon triggering a signal from the
microcontroller an optical isolator would be activated which would activate a transistor,
activating a relay that would turn on the launcher. The transistor was necessary because the
current that would be drawn by the relay was too much for the isolator to handle. Once the
launcher has been activated the device must deliver the balls one at a time to satisfy our
objectives, and for that we must have a ball dispensing mechanism. This is comprised of
essentially just a servomotorvii that is mounted on the tube delivering the tennis balls. The motor
has an arm that extends in front of the ball, and when the ball release command is given it simply
moves the arm out of the way for a set period of time to allow one ball to pass through.
          The third important actuator is the mechanism that will rotate the direction of the tennis
ball launcher. The launcher itself has been attached with Velcro to a turntable that has a timing
beltviii turned inside out and glued to the turntable, essentially creating a large sprocket. There is
then another larger timing belt wrapped around this “sprocket” that feeds into a pulley on a
stepper motorix, which is controlled by a stepper motor driverx connected through optical
isolators to the microcontroller. Using this motor, we can move the larger assembly to any
orientation, 360 degrees around with a step size of approximately 0.25º. This will allow the
tennis ball launcher to pivot its orientation in the back of the court to surprise the hitter with
shots in a variety of directions.


Sensors
          There are a few sensors involved in this system, the first of which is the wireless sensorxi
that connects to the processor when a signal has been transmitted. This was done by the use of a
wireless relay, which I have configured to send a signal whenever the wireless remote has been
triggered. There is a never-ending while loop that continuously checks for that feedback to see if
buttons have been pushed, which will lead to certain actions being taken (explained later in
“Behaviors”). Another sensor is my SONARxii, which will be used to detect obstacles in front of
the robot (primarily the net, but other obstacles, as well). The SONAR has been fully tested and
works at a range up to about 10 feet. This is not enough to detect people at the baseline from
mid-court, so I will not be using it for that intended purpose, instead mainly for obstacle
detection and to use when navigating off the court. The final set of major sensors are the
Infrared emitters and detectorsxiii on the bottom of the robot that will be used for line following.
These will all be hooked up to a power source and the output from the detectors (determining
how much light is reflected back, for white lines the amount of light should be greater and
therefore the resistance smaller) will go into comparators that will determine if the ground below
it is a line or not. The base value that is used by the comparators is set experimentally with a
potentiometer. On the courts that I tested on (the primary one being the tennis court at Madison
Pointe Apartments), it was extremely difficult to calibrate the device because the detectors would
find similar light from the white line and the out-of-bounds (which was red) part of the court.
Often even in low outside lighting it was difficult to calibrate and as a result the quality of the
line following data was sometimes poor.


Behaviors
        The overall system will essentially have three primary behaviors. The first of which is
“playing ball machine”, where the robot will orient itself on the end line of a tennis court and
launch balls to the other side in two possible modes; one that just throws the balls straight ahead
(by pushing remote control button 1) and the other that will randomly throw balls at various
positions on the court (button 2). The former will essentially be just launching balls when the
button is pushed, and the latter will involve rotating the base randomly to launch balls that stay
within the court; it will likely also launch the balls sequentially rather than at the push of a
button. The second behavior is navigation, which will involve line tracking, along with
integration of the SONAR system, to get from the baseline to the side of the net, out of play (or
the same path in reverse). This will be done whenever the person with the remote pushes the
corresponding button. The third behavior involves throwing the ball more gently to the person
on the court, this action is done from the position on the side of the net, out of play. This will
similarly be done at the push of a button, whenever the person needs a ball. This is done by
turning on the launcher and releasing a ball around the same time, so the launcher isn’t at full
speed when the ball reaches it. These behaviors would be the 3 overall components of my
robot’s algorithm, and would each be conducted as roughly a case basis, so the robot would
know what state it is in so what each remote button would mean.


Experimental Layout and Results
         The primary testing was done on the line-following algorithm and subsequent court
navigation. All tests done on the sensors, such as SONARs and Wireless Relay, were all
relatively simple and would mainly be used for calibration purposes. The navigation algorithms
were very difficult to implement due to the relative inconsistencies the robot would have. How
the line following would be calibrated and tested started with displaying the readout from the
line following array (which was 8 emitters/detectors wide) on the LCD screen so it could be
determined which detectors were being activated. Then the resistance on the potentiometer
would be altered until only a few detectors were activated, specifically those over the white line.
At this point, the system would be ready for line testing. The robot would drive along the line,
every 200 milliseconds recalibrating the drive command to make sure it stayed center. A few
problems would occur during this time: sometimes the detectors would become activated even if
they were not on the line, and in some cases one detector would stay on almost permanently (that
detector was later eliminated from the algorithm so it would no longer be looked at due to a
likely wiring error).
         Eventually the system would work pretty well, staying on the line in approximately 60%
of all the runs taken. However, when it came to navigating around the court, many problems
arose when implementing the various algorithms. Specifically turning at the various lines,
especially due to the fact that the out of bounds area, which was red, often returned positive
signals from the detectors. This made line following around that edge extremely difficult and the
calibration of the detectors rarely improved matters. As a result much of the behavior was
moved inside the court so that the ball launcher would sit on the line in between the end line and
the net and navigate to the edge that way. This proved to be much more successful, but there
was still a problem with turning the vehicle. Due to the fact that the robot would often get
slightly off course, it was difficult to write a program that would effectively determine when the
robot would hit an intersection. It would not usually hit the intersecting line at the correct angle,
and other methods to turn proved relatively unsuccessful. At this point the navigation algorithm
was altered so that the system would line follow for a set amount of time before turning
gradually towards the net and moving until it would run into the net, the SONAR would signal
when it got within approximately 3 feet and tell the system to turn around. The navigation back
to the launching position was aborted due to the same difficulties found in line following.
Instead it would be assumed that the player would move the robot back to a desired position for
the best possible practice. All these behaviors can be seen on the video which can be linked
from my robot’s website.
Conclusion
         I have gone through many different phases of this project, the first of which imagining
that this device would be an excellent tool on a tennis court to help with practicing your shots,
serves and many other things. I thought it would be better, last longer, and be much cheaper than
a traditional ball machine while still having added functionality to navigate around the court.
Those opinions have since changed. The line following and therefore navigation aspects of the
project were inconsistent, at best, and I even realized throughout the semester both in my own
thoughts and by talking to other tennis friends that the secondary feature of tossing balls casually
would never be used. This is plainly because you wouldn’t want that many balls around because
you would slip on them, by idling there for so long the batteries would quickly die, and moreover
it would just be lazy not to go around picking up balls, which tennis players rarely are.
Additionally, the launcher itself, although it was industrial grade, didn’t launch the balls very fast
(at least in tennis terms) and although would be useful for practice, it would be nowhere near as
good as a commercial ball machine. On the plus side, a final design robot would be cheaper than
a commercial system and the mechanical system could be streamlined to be smaller and less
cumbersome. However, due to the inconsistencies with the wireless transmitter, along with the
jamming of the tennis balls and the relatively weak launching abilities, the system itself would
not be much worth the relatively low difference in price, at least not at this stage. Further
developments and research could fix many of these inconsistencies and provide for a much more
effective system, and that will be a definite goal for myself in the future.
         Throughout this project I have learned a tremendous amount about the integration and
development of mechanical and especially electrical systems. Being a mechanical engineer,
before this project I had never really thought about the power consumption of various
electronics, the electrical boards that run many necessary components, current through various
lines or optical isolation to protect microcontrollers. I had never designed or assembled a custom
circuit board, programmed a processor board to accomplish a task, connected power to ground
on a battery and realized what was happening, ordered electrical components, created headers
and receptacles to connect them or even picked up a soldering iron. I have now done all of those
things and learned much more than I could have ever learned in a theory class and I look forward
to applying the skills I gained in this class on future personal projects. At that point it will be
much more interesting to get started with the knowledge I have now so I can build on my
experience rather than learn all the basics as I did with this project.
List of Parts
i
   Hsiang Neng Geared Motor HN-34PGC-2416T, DC-12V-65RPM, obtained from
lynxmotion.com
ii
    Dimension Engineering Sabertooth 2x5, purchased by lynxmotion.com
iii
    Purchased by Pridgen Vermeer, Atmega128 Board
iv
    McMaster-Carr Part # 6460K31
v
    Donated by Master Sports, motors run off 12V power supply
vi
    Werker 12V-7.5Ah Battery, obtained from Master Sports
vii
     Hitec HS-55 Feather Servo Motor. Purchased from Hobbytown, USA.
viii
     Trapezoidal Tooth Urethane Belt, 0.200” Pitch, McMaster-Carr Part # 1679K48
ix
    NEMA 24 High Torque Step Motor, Anaheim Automation Part #24Y104S-LW8
x
    Microstep Driver, 2.5 A, 12-24VDC, Anaheim Automation Part #MBC25081TB
xi
    Carl’s Electronics Part #HD2RX and HD2TX (Relay Board and Transmitter, respectively)
xii
     Maxbotix EZ-3 Sonar. Purchased from Sparkfun.
xiii
     Vishay Part # TCRT5000L

								
To top