"Mechatronics" (Robotics)
A robot that plays ball

 

Team PNC with our robot. Jeff Chapin, Brian Rulifson, Ian Halpern, and myself.


Video of the robot being activated, rotating until it finds an infrared beacon,
doing an ultrasonic rangefinding sweep, returning to face the IR beacon, shooting, and reloading.

 

Goal
 
This robot was designed and built in four weeks, for Stanford's Mechatronics class ME210. The class had a competition to play a basketball-like game with three baskets along the middle of a court; the baskets opened in random order for 20 seconds at a time, with an infrared beacon above each basket to signal whether it was open or closed. For a detailed description, see the Project Specifications.  

Hardware
 
The robot chassis was built using a combination of hand-cut MDF, machined Delrin, bent aluminum sheet, machined aluminum, and a steel plate with a neoprene pad. It was by far the most physically robust of the robots made for the class. On the top of the robot are the infrared sensors and their circuitry, as well as the microcontroller board and the 'on' button. Below are the catapult and ball-holding tube, ball reloading plunger, and square base on which the robot rotates. (see photo below.)

Chassis notes:

  • The entire robot chassis rotated on a steel base-plate with a neoprene pad affixed to its underside to avid slipping. The chassis was connected to the base plate via a lazy susan.
  • A stepper motor was used to repeatably control the robot's rotational position. It was geared down 40:1 to avoid missing steps; rather than use an encoder to keep track of position, we simply made the system 'non-backdriveable' with the large gear ratio.
  • The motor sat on a bent sheet-metal platform to engage with the gears. One small gear was mounted to the stepper motor shaft, one big gear was mounted to the steel base plate and stuck up through a hole in the robot's floor, and two gears were mounted coaxially on a shaft to rotate together. (See photos below.)
  • Due to exceptional torque on the plastic gears, the two coaxial gears were pinned to their shaft to prevent slippage: the gears' mounting collars were drilled through, along with the shaft, and screws acting as pins were put through the gear collars and shaft. (See photos below.) The gear shaft was steel, with brass bushings.

              
    Turret gears & motor, from the side and above. Discolorations are from graphite powder lubricant and oil.

    Catapult notes:

  • When launching a ball, the catapult struck a stopper-plate to control the angle of ball launch repeatably. This stopper was machined aluminum, with adjustable position.
  • The catapult was machined out of Delrin, to avoid snapping from repeated impacts on the stopper. The holes are to reduce its inertia.
  • The catapult was attached to a DC motor by means of Lego gears with a 5:1 ratio. The plastic Lego shaft was destroyed during testing, so we machined an aluminum shaft to replace it.
  • Flexible Tygon tubing was used to couple the motor to the gearshaft, to avoid stripping gears when striking the stopper.
  • The block holding gearshafts was machined aluminum for robustness and repeatability; the pedestal of bent sheet metal was to position the catapult for a long swing when launching.


    Catapult mechanism with Tygon coupling, Lego gears, machined gear block & gearshaft, and sheet metal pedestal
    (see also video clips below.)

    Realoading mechanism notes:

  • The ball feeder was a spring-loaded plunger which blocked balls from falling out of the tube until the catapult fired and returned.
  • On the catapult's return stroke it hit the plunger, pushing it down far enough for one ball to fall into the catapult's ring. The catapult motor then shut off, and the plunger's internal spring pushed it and the now-loaded catapult into the neutral position.

       
    Videos of the catapult & reloader in action, with balls and without balls to show the reloader's action

    Infrared sensor notes:

  • Bent copper sheet was used as blinders for the IR sensors, so that in addition to restricting the fields of view, it would optically amplify the light of the beacons with its mirror-like surfaces.
  • Three sensors were used, angled apart from each other. This provided a nearly 235-degree field of view, and allowed simple control: when the center sensor reads highest the robot stops, when the left sensor is highest the robot rotates left, and when the right sensor is highest or no sensors read a minimum threshold the robot turns right.


    Infrared phototransistors and their copper sheet blinders/amplifiers

     

    Electronics
     
  • The robot was controlled with a Motorola 68HC11 on a special MC11 input/output board furnished by the Stanford Smart Product Design Lab (SPDL). The SPDL also furninshed motor controller boards, each consisting of a DS3658 stepper controller, a SN754410 h-bridge, or an LMD18200T h-bridge, with heat sinks and screw-mounts for wires.
  • Infrared sensors were used to sense the beacons on the court, thus aiming the robot in the right direction to shoot each time. A set of three sensors with physical reflector/blinders to separate left, right, and narrow-view middle were used to home in on the beacons.
  • Ultrasonic rangefinders were used to sense the distance from the robot to the rear wall of the court, to calculate how far to launch the balls. This also let the robot know what angle it was shooting at, by finding the position perpendicular to the back wall.

    System wiring diagram

    Notes on motors:

  • The catapult's DC motor used its own separate power supply (at 18V), because it pulled too much peak current to run simultaneously with the other electronics.
  • The DC motor used an LMD18200T h-bridge, because the large peak current it pulled blew out the SN754410's.
  • The robot was rotated by a stepper motor run at 15V.

    Notes on the IR circuit:

  • The circuit's high-pass filter cuts out noise from room lighting, sunlight, etc. and only reads the high-frequency (15KHz) oscillations of the IR beacons.
  • The circuit's output is a DC analog voltage corresponding to the light intensity; the DC voltage is given by rectifying and low-pass-filtering the signal after amplification. Note that the rectifying diode is an LED, allowing one to look at the circuit and see the intensity of light being read by the sensor, without the use of measuring instruments.
  • The signal is greatly amplified because it is designed to operate with the sensors eight feet from the beacons. This amplification of a weak signal was also the reason for the second (.75V) offset voltage: the weak signal, even at its maximum, was below 2.5V (the first reference voltage) after the voltage drop from the rectifying diode; in order to get any signal, a lower offset voltage had to be used.


    Single IR circuit diagram

    Notes on the ultrasonic rangefinder:

  • We used a Devantech SRF04 rangefinder module. It runs on 5VDC, requires a 10us logic-high pulse (TTL-level) to trigger each sample, and returns a logic-high pulse whose duration is proportional to the distance measured.
  • The rangefinder puts out pulses of sound at 40KHz for .2ms each burst, then waits for the sound to bounce back to it; it samples distances from 3cm to 3m.
  • We operated the rangefinder at 100 samples/sec, measuring distances between 4cm and 20cm.


    The ultrasonic rangefinder
     

    Software
     
    Our code was written in C using ICC11 IDE on a Windows workastation; it was compiled using Buffalo, and downloaded to the 68HC11 microcontroller via RS232.

    Notes on structure and implementation:

  • All code was written in a modular, state-based manner.
  • Pre-existing modules were provided for pulse-width modulation and period modulation of motors; however, we did write such routines from scratch earlier in the course to understand them.
  • A module was provided to handle multiple independent timers. However, since our ultrasonic rangefinder required shorter time increments, Brian wrote his own timer module with help from the professors.
  • The main program, Robot_main, called the IR_read module to read the IR sensors and compare to see which was brightest, and output the direction which the robot needed to rotate, if at all; the RotateTurret module rotated the robot and kept track of its angular position; the Ultrasound_Sample module handled the sampling of ultrasonic data, while the whole ultrasonic sweep procedure was a subroutine in Robot_main; the distance to shoot was calculated by CalcShootDistance; the shooting, reloading, and pausing between shots was handled by the Catapult module. (See the full text of the program with all its modules below.)
  • Authorship note: I wrote IR_read, RotateTurret, and CalcShootDistance, as well as most of Robot_main; Ultrasound_Sample and the parts of Robot_main dealing with ultrasonics were written by Brian; Catapult was written by Jeff.

    Block diagram of the software's flow

    Full text of software and all modules:
  • Robot_main.c
  • IR_read.c
  • RotateTurret.c
  • Ultrasound_Sample.c
  • CalcShootDistance.c
  • Catapult.c
  • Notes on ultrasonic rangefinding:

  • In addition to hardware control and sensor input, the software calculated how far to shoot based on the position of the robot in the court and the position of the basket it was aimed at. (See diagram below.)
  • The ultrasonic rangefinder was used to find the minimum position to the rear wall, and record the robot's angular position when perpendicular to the rear wall. It did this by sampling distances as the robot rotated, creating an array of angular position vs. running average of the last few distance samples, and noting the angular position at the minimum value of averaged distance. The averaging was done to eliminate possible noise variations.
  • The robot swept out an angle of thirty degrees for its ultrasonic rangefinding; we decided this was the minimum angular range needed to be sure of finding the correct value no matter where we were placed in the 'placement zone'. This thirty degrees was always in relation to the rotational position pointing at an IR beacon.


     

    Performance
     
    Our robot placed third in the competition out of 13 teams. Not bad for four product designers in a mechanical engineering class; particularly when three of us were taking the class pass/fail, and I was only auditing. As it happened, the width of the baskets plus the backboards was larger than the maximum difference between baskets no matter where the robot was set down in the start-zone, so we did not need to shoot at different distances at all, but simply use the same distance every time. This effectively meant that the ultrasonic rangefinding and calculating of shoot distance was unneccessary, despite the enormous amounts of time we spent on it. The two robots that beat us, interestingly, had much worse precision in sensors and shooting, but had massive amounts of balls constantly spewing out. Perhaps a lesson in prioritizing.


    Our robot in action at right, baskets at center and a competing robot on the left, before the breathless crowd.

    Video of the robot in action!

  •