Click here to go to the SI Home Page
.

Philhour and Cannady

"The Emperor is not as forgiving as I am. " — Darth Vader

The St. Ignatius Robotics Competition of 2009

sponsored by the St. Ignatius Robotics Laboratory (SIRL)

Most recent update February 17, 2009 2:43 PM

   

Link to a video of the 2006 competition's Winning Robot! [Willy Jaquier, Kirk Hilken, Aron Gragnani, Scott Wardell, Robert Kelly, Brett Lando]

Competition date & time & location: TBA

Maze Map (in preparation)

Press Release -- February 17, 2009

During the final exam period for Engineering, your robot will be asked to accomplish a series of tasks as described below. Don't reinvent the wheel! Don't wait until the last minute!

Tasks

  • See constraints and materials below.
  • Qualifying Tasks
    • Level 0: (to be completed only if Level 1 fails) Go forward 0.5 and 1.5 meters and come to a stop (built entirely in program).
    • Level 1: After a pause of 30 seconds, and without human contact, move forward between 0.5 and 1.5 meters and come to a stop because robot senses obstruction.
    • Level 2: Without human contact, move forward 0.75 to 1.25 meters, turn right, and stop within 0.5 meter the turn.
    • Level 3: Without human contact, move forward 0.75 to 1.25 meters, turn right, and stop within 0.5 meter of obstruction.
  • Competition
    • Robot is to independently navigate a maze. The maze map will be provided. The maze itself will be partially constructed in advance for testing.
    • Robots will compete against the clock. A 5 second penalty will be added for each contact with a wall. A 10 second penalty will be added each time the robot is physically reoriented by a student -- the robot may not be moved.
    • Walls will be approximately 30 cm in height; corridors will be 75 cm in width. Corners will be 75 cm square.
    • Electrical power will be provided by a drop-down cable designed so that it generates no net force on the robot.

Provided Materials (per group)

Available Materials (please speak with your instructor - availability may change!)

Additional Outside Materials

  • Students can use additional materials under the following constraints:
    • Each group that uses additional materials must appoint a treasurer responsible for accounting for the cost of each additional component. Note that all the 'Available Materials' from the last list are "free of charge" in this sense.
    • Outside components cannot achieve, on their own as a single unit, the three most difficult problems: they cannot have an independent CPU (that is, they can't already be robots), they cannot provide their own steering system or differential gear, and they cannot contain an integrated drive motor. Check with your instructor if you are unclear. The instructor's call might be subjective, but it is final.
    • Commercial robotics kits are allowed under certain conditions: the group must build the kit itself; the kit cannot include a CPU, and the kit cannot contain any 'black box' components. A 'black box' component is a piece that accomplishes some task without it being immediately clear how it did so. Examples include complex gear boxes & complex linkages.
    • All components in the system apart from those provided by the instructor must have an estimated cost -- receipts will do, as will catalog pages or price quotes (online or otherwise)
    • Total amount of additional materials must not exceed $50 (roughly $10 per group member; this can be considered your equipment fee for this semester)
    • Treasurer's report will be due approximately one week before the competition. All treasurer's reports will be made public for absolute transparency.
  • You may want to visit some hobby shops here in San Francisco as found by Google Maps
  • Here are some possibilities (no guarantee is made for any of these!)

Benchmarks

  • April 29th
    • Group blogs set-up and links sent to Ms. Blake
  • May 1st
    • Frame done
    • outline of program
  • May 5th
    • Body done and components mounted
    • Program ready for testing
  • May 8th
    • Qualification for the Robotics Competition
  • May 14th
    • Robotics Competition

Potential Show-Stoppers

  • Waiting too long to get started and not having enough time for testing and debugging the completed project. Your teachers recommend at least two weeks for testing, so set your 'drop dead' date to be at least two weeks before the actual competition.
  • The drive motors we are providing you with might not provide enough torque to get your robot moving from rest. You need to figure out if this is the case early so you can find a stronger DC motor. You MUST FIND THE RIGHT MOTOR FOR THE JOB.
  • Turning is a challenge -- you might need a separate motor (stepper motor?) -- perhaps you should assign a task force within your group specifically challenged with finding a solution to the turning problem.
  • You should also have a task force working on programming. Without independent work by many sub-groups within your original group, you will not complete the project in time.
  • DC and stepper motors are fragile -- they can contain internal gears that cannot stand up to lateral stress on the axle. Be very careful with how you attach your motor to your system.
  • Back up your software by copying it to other student's calculators.

Scoring Rubric

  • Students who participate in a group that
    • reaches Level 0, final exam grade performance component is C-
    • reaches Level 1, final exam grade performance component is C ("fair")
    • reaches Level 2, final exam grade performance component is B-
    • reaches Level 3, final exam grade performance component is B ("good")
    • competes, but does not finish, final exam grade performance component is B+ ("very good")
    • competes and finishes, but does not win, final exam grade performance component is A ("excellent")
    • competes and wins, final exam grade performance component is A+
  • A second component of the grade will be peer evaluations of how much each group member contributed to the completion of the project. A more detailed rubric for this component is in preparation.

Group responsibilities:

  • Project manager
    • Makes sure the group adheres to time benchmarks
  • Programmer
    • Spearheads the programming for the robot, responsible for the final program.
    • We suggest that multiple people help the programmer when possible, as this is a huge task.
  • Equipment manager
    • Responisble for obtaining/maintaining all the equipement required for this challenge.
  • Webmaster
    • Responsible for maintaining the groups blog. Everyone should contribute to the blog, but the webmaster controls the look and feel of the blog.

Example weblog:

2006 Weblog for Mr. Cannady and Mr. Philhour's robot

  • This weblog monitored our spending, documenting the challenges we faced, and recorded our progress. We suggest you keep a similar blog.
    • Spending
      • Ordered two 3 V, 30 RPM motors and a single 3V, 15 RPM motor ($24.95/ea)
      • Purchased two lightweight foam model airplane wheels from Franciscan Hobby shop on Ocean. ($14.50 total)
      • Purchased a vial of ZapGap gap-filling adhesive from Franciscan ($4.50)
    • Challenges
      • TORQUE: Almost immediately upon starting this project, we began to fear that the combined weight of the LoggerPro, DCU, calculator, motors and battery would be so high that the motors wouldn't be able to drive the robot forward. We purchased the 30 RPM motors thinking they would have more than enough torque turn the wheels. But once the first draft of the robot was assembled (on Wednesday, May 17th), we immediately discovered that the torque is just barely sufficient to start on a very flat surface. Several attempts were made to lighten the load: though batteries smaller than the lantern can weigh less & provide sufficient voltage & lifetime, the output current was too demanding. It might be difficult to replace the lantern with something lighter. Update Tuesday May 23rd: we found that replacing our old battery with a new battery was all we needed to get the torque back up -- guess we had (fairly quickly!) drained the first battery. Wow.  Update Saturday May 27th: Furthermore, our front-left motor had become detached from the wheel, meaning that we were only at half torque. A liberal application of Krazy glue solved the problem -- now we're getting much more torque.
      • TURNING: We had made the assumption that powering the left and right wheels independently would allow us to turn easily: we would just put one wheel in 'forward' and the other in 'reverse'. But no! In practice, one motor would dominate, dragging the other one (which is stalled). On Thursday, May 18th we installed a vertical rear rudder motor, but found that the motor wouldn't provide enough torque to spin the rear wheel while stopped. We are currently waiting for a new, stronger motor to handle this task. See update in Turning below! Also, Update Saturday May 27th: we were having some problems working out the back wheel -- it would be wobbly, for instance, and even collapse from time to time. We implemented a two-wheel solution (they are still very near each other, so the overall effect is one of a tricycle) that helps nicely.
      • SURFACE: When we placed our robot on the gym foyer floor, we found the robot had a significantly more difficult time moving forward than on the tabletop in 107 or the room 310 lab bench. The working theory is that the gym floor is quite warped. What was before a 'manageable' lack of torque has now dropped to an insufficient amount of torque! Update Tuesday May 23rd: see 'torque' above: we may have just had a low battery. Update Sunday May 28th: also, one wheel had come 'unglued' so we were operating at half-torque. I think we're good now.
      • PROGRAMMING: Update Saturday May 27th: So it is more challenging than we thought to implement the servo motor and DC motors at the same time. For a reason we can't quite fully explain, running DCUINIT jogs both the DC motor and servo motor, changing the wheel position. Furthermore, running the servo motor program (DCUSERVO) seems to interfere with collecting position data from our range finder (and vice-versa!). So we're going to have to be more careful about our programming than we thought -- it'd be nice to have a complete manual for the DCU commands. so we could be sure exactly what we are doing. I can't follow much of what's going on within DCUINIT, for example. That said, this looks like a programming challenge and not a major one. Update Sunday May 28th: was able to fix everything through some new programming -- see below.
    • Progress
      • TURNING: Update Thursday May 25th: I was looking through the Robotics and Control Kit and found the servo motor, a perfect motor for the job. Each group has a servo motor -- this was the motor used for the rubber-band launcher. Servo motors are ideai for rudders: they are not built to continuously spin, but to accurately turn to a certain position angle. Perfect! Plus they are very high torque! Implementation is a bit scary, but ultimately not that bad. We need to run/modify the program DCUSERVO which sends the appropriate pulse to the servo motor. The motor has three wires attached: the first two are just +6 V, which you can wire directly to the battery; the third is programmed by DCUSERVO and must be hooked up to D1.
      • PROGRAMMING: Very simple commands have saved the day. We wired up one motor to D1 & D3, the other to D2 & D4. Then we could turn on either motor by applying a voltage difference using {2001,9} for forward, {2001,6} for reverse, etc. To move forward a reliable distance on a tabletop, we just had to count (using 0->A, WHILE A < 100, 1+A->A, END as a time-wasting loop while the motors were turned on). Update Tue 5/23: we rewired so that D1 & D2 power both drive motors (forward and reverse only) and D3 & D4 deal with the rudder motor. This makes turning a lot easier since we can power the rudder and drive motors at the same time. Update Sunday May 28th: we fixed a lot of programming errors. The latest versions of our stuff is below.
      • TIME MANAGEMENT: Although we started a little late, we got a good start on the robot and learned an enormous amount from having a completed robot in hand. Our "1st draft" robot has taught us much and I think we may have to consider a "2nd draft". Fortunately, because of our good start, we have an entire week before our self-imposed "drop-dead" date of Thursday, May 25th.  Update May 23rd: wow, how time flies. We are doing our best to qualify by Thursday, May 25th. Update Saturday May 27th: we did some extensive testing of the drive motors and steering servo motor on Friday and found a number of programming challenges described above. We now feel confident that with a fresh battery we will be able to have the necessary torque on all three wheels, and will be able to adequately measure distance. Our main challenge is now in software, and we have Sat, Sun, Mon, Tue, and Wed to solve these.
    • Wiring
      • D1 is wired to the servo motor (as are +6 V and ground)
      • D2 is (as yet) unused
      • D3 is wired to the positive terminal of both drive motors
      • D4 is wired to the negative terminal of both drive motors
    • Code

      prgmBSERVO1: (1.5 ms pulse) turns rudder wheel for turning corners

      prgmDCUINIT
      {1, 31, 13, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} -> L6
      Send (L6)
      {3, 0.0015, 1000, 0} -> L6
      Send (L6)

      prgmBSERVO2: (1.75 ms pulse) turns rudder wheel straight

      prgmDCUINIT
      {1, 31, 11, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} -> L6
      Send (L6)
      {3, 0.0018, 1000, 0} -> L6
      Send (L6)

      prgmBMEASURE: finds forward distance

      prgmDCUINIT
      {1, 12, 1} -> L6
      Send(L6)
      {9, 1} -> L6
      Send (L6)
      Get D
      Disp D

      prgmBJOG: moves forward

      prgmDCUINIT
      {2001,4} -> L6
      Send(L6)
      prgmWAIT
      {2001,0} -> L6
      Send(L6)

 



Can't find what you're looking for or
see a problem with the web site? Let us know!

© Copyright 2010, St. Ignatius College Preparatory
2001 37th Avenue, San Francisco, CA  94116 · (415) 731-7500