Main Page
|
Course Admin
|
Course Resources
|
Rules & Regulations
|
Team Profiles
|
Photo Gallery
|
Contact Info
 
  You are here: RoboFlag Main Page > Course Admin > Milestones and Deadlines


  Project proposal (Sep. 14, 2001; individual grade: 5%)

This proposal will include a description of the project, your position in the project, due dates for the whole group (as given here), and your personal due dates to insure the team due dates are met.

This is an individual proposal, and you must write everything that you present in your proposal. Reference shared charts or diagrams.

You should be sure to meet the Dept. of Electronics proposal guidelines, and to follow the recommendations outlined in the "Preparing a Fourth-Year Design Project Proposal" document available from the Report and Presentation Information section of the Course Resources.



Design review (Oct. 5, 2001; team & individual grade: 10%)

The design review is the first "make or break" point of the project. Teams will be expected to present their research and design ideas, explain the design objectives, and defend the design decisions! This is a technical review and you must be thoroughly prepared. Each team-member will be expected to talk 5 to 10 minutes with drawings or sketches.

This is both a team and individual review, and you will be graded on how well your team performs, and how well you perform. You must clearly identify what you have done, what your team-mates have done, and what you have collaborated on. Reference shared charts or diagrams.

The design review will consist of your three team members and the course coordinator. The review will be informal - no slides or suits are required - and very technical. Part of the review will take place in the lab, and you MUST be prepared to answer detailed technical questions.

If you have drawings or schematics to present, sketch them on a piece of paper and pass them around. If you design circuits or use drawings that are more complicated, print them out. There will be no portion of your mark associated with the presentation - as long as I can understand what you're talking about.

For everything outlined below, you must be able to explain WHY you're making the design decisions you are making. Please don't tell me that you're using such-and-such a sensor because everyone else does. Understand WHAT that sensor does, WHY you need it, and WHICH other sensors do the same thing. Understand this sort of thing for every technical decision you make.


Lab Presentation:

Your team will be expected to demonstrate the fundamentals of the MIT HandyBoard as follows:

  • bootstrap and initialize the board
  • download code to the board
  • execute downloaded (or manually programmed) code
  • perform a simple task
    • flash a LED
    • move a motor
    • etc.
Feel free to suprise me with the demonstration. This lab component of the project will take place before the individual presentations.


Mechanical Stuff:

You will present your design objectives for the following:

  • robot size, weight and structure
    • including scale drawings of each layer (top and side view)
  • method of moving around (legs, wheels, tracks, etc)
    • type of drive if wheeled (ackerman, synchro, differential, etc)
  • top speed and other movement calculations
  • turning speed calculations (rough - no dynamics needed)
  • grabbing mechanism design and considerations
    • detail how your grab detect sensor works
  • number of microprocessors, etc.
As with all the technical details, you must not only be able to answer the above questions - you must be able to explain WHY you've made the decisions you did, and go through the decision-making process. Understanding the alternatives is often as important as understanding your selected route.


System Stuff:

The member of your group responsible for the management & system design will present your group design objectives for the following:

  • robot design strategies
    • heavy vs. light, fast vs. slow, directional?
  • navigation & movement strategies
    • reflexive vs. historical
    • encoding & feedback? compass?
    • obstacle avoidance, arena vs. robot detection(?)
    • briefly intro algorithms detailed by software guy
  • grabber strategies
    • detect sensor
  • beacon strategy and techniques
    • how your robot will detect other robots (strategy only)
    • how your robot will detect the flag (strategy only)
  • what software tasks are required to run concurrently
    • ie: what your robot needs to DO all the time
    • control motors & grabber, poll x sensors, etc etc.
This doesn't need to be very explicit, but it will help the electrical and software designers define what technical components need to be implemented.


Electrical Stuff:

The member of your group responsible for the electrical design will present your group design objectives for the following:

  • motors
    • what type of motors your group will use (wheels, grabber, etc)
    • what motors meet the mechanical specifications & your selected type
    • how the motors will be interfaced to the HandyBoard
  • what batteries you will use for motors/logic/etc
    • will you use different power sources?
  • the power consumption of the major components of the robot
  • the operating life of the robot
    • detail any low-power states
  • the type of failure that will occur when the batteries "run out"
  • a list of sensor requirements built from the system level
    • interface circuitry for each type of sensor to the appropriate processor
    • specifications on the sensors, etc
  • handyboard ports map (listing I/Os from handyboard)
  • systems connection schematic (showing all connections on 'bot)
Again, remember the WHY and the alternatives.


Software Stuff:

The member of your group responsible for the software design will present your group design objectives for the following:

  • command and control
    • type
    • c&c algorithm review
  • algorithm block pseudocode
  • what seperate threads/subproceses/tasks will be used
    • this should cover all the concurrent tasks outlined in the system-level design
    • on which processor will they be executed
  • how will communication between different processors work
  • how will communication between different processes on multi-tasking processors work
  • what languages will be used to program the processor(s)
  • which processor(s) will multitask, which will perform single functions
  • paper arena demo
    • walkthough of an arena you bring (and I bring) explaining your algorithms
Again, don't forget the WHY and the alternatives.


PIC Presentation Stuff:

The member of your group responsible for the management will cover the following:

  • IR beacon
    • # detectors, PIC and clock speeds
    • algorithm design
    • problems
  • flag beacon
    • # detectors, PIC and clock speeds
    • algorithm design
    • problems
  • other PIC requirements


Management Stuff:

The member of your group responsible for the management will cover the following:

  • the availability and cost of all the sensors, processors, motors, etc
  • how resources (time, money, effort, etc) have been allocated per member
  • any changes in the timeline
  • any management problems



Basic demonstration (Nov. 24, 2001; team grade: 10%)

The basic demo is where you show that you have, both in hardware and software, implemented the main components of the robot design: the motors, the sensors, the IR and flag beacon and detectors, and the grabbing device. This is a technical review and you must be thoroughly prepared.

This is a collaboration of individual efforts, but you will be graded as a team. Individual grades will not be given, so everyone within your team needs to be concerned about _all_ of the deliverables. The team manager must identify any potential problems long before the basic demo occurs.

The demo is a logical extention of the design review; you must have implemented the main components of your design and accounted for any changes since the design review. This is a very important aspect of the demo and is outlined under the "managerial" section below.

The basic demo will consist of your three team members and the project course coordinator. The review will be informal - no slides or suits are required - and very technical. The entire demonstration will take place in the lab; you MUST be prepared to demonstrate the requirements outlined below, and answer detailed technical questions.

Note that for every component of the demo I will want to see code and hear an explanation of how the hardware and software interface. Please take care to make sure that you're presenting technically valid information - mistakes at this point will get you a bad grade and will require additional time to redesign.

If you have drawings or schematics to present, sketch them on a piece of paper and pass them around. If you design circuits or use drawings that are more complicated, print them out. There will be no portion of your mark associated with the presentation - as long as I can understand what you're talking about.

The following list of guidelines detail the required level of assembly for the basic demo:

  • an umbilical cord (from the PC to the handyboard) is allowed
  • the following should be attached to the chassis (as a minimum):
    • motors, gears and wheels
    • additional battery packs
    • the handyboard
    • the grabber
    • bump sensors (on the front)
  • most sensors can be demonstrated from breadboards, but they must interface with your HandyBoard!
  • bump sensors (or other obstacle avoidance sensors) must be mounted on the front of your robot for the movement demo.
  • infrared robot beacons and detectors and visible flag beacon detectors can be demonstrated from a breadboard
  • code must be shown and explained for all portions of the demo


Movement Demo:

Your team will be expected to demonstrate the basics of movement, as follows:

  • navigating around a small arena, demonstrating:
    • left hand turns
    • right hand turns
    • straight-line movement (or as straight as possible)
    • curved (arcing) movement (if required by design)
  • using bump sensors to navigate (ie: moving around obstacles)
  • covering as much as the arena as possible
Additional (optional) tasks are:
  • starting and returning to the same position within the arena
  • exhibiting some form of optical sensor -> motor feedback:
    • moving in perfectly straight lines (without using a stepper motor)
    • wall following or turning around a corner without contact
    • high-speed stop before running into an obstacle
Feel free to suprise me with the movement demonstration. As with all of the components of the demo, I'll want to see a printout and explanation of the code.


Sensors Demo:

You must demonstrate each of the sensors you specified in the design review, as well as all the ones you added due to excessive feedback from myself. You are not required to interface the total number of sensors you plan to have (ie: no need to show me six different bump sensors, one is fine), you don't have to integrate any additional processors, and it isn't a requirement that you implement ISRs.

It is important that you interface the sensors in the manner in which you presented for your design review. ie: If you propose to have five bump sensors connected to a PIC, then connected to the HandyBoard via one digital port, aim to do that! Connecting all five sensors to one HandyBoard port would be acceptable as well.

As a minimum, you must demonstrate:

  • a visible flag beacon detect sensor, which must:
    • identify the flags (seperately) by the flashing beacon
    • be able to distinguish between the two flags (20Hz, 30Hz)
    • communicate with the handyboard to indicate the flag has been detected
    • (you only need to demonstrate one sensor working in one direction)
  • an infrared robot beacon detect sensor, which must:
    • correctly identify another robot via the infrared beacon
    • correctly ignore the beacon on the robot that is doing the detecting
    • communicate with the handyboard to indicate WHICH other robot (the 3-bit robot ID) has been detected
    • you MAY hardcode your transmission timing (position 1-4 in the spec), but note that your timing slot will change FOR EACH GAME during the competition
    • (you only need to demonstrate one sensor working in one direction, but your emitter must work in all directions)
  • a zone detect sensor, which must:
    • correctly identify when the robot is in either zone (red or blue), or not in a zone at all (black)
    • communicate with the handyboard to indicate which zone the robot is in
Other sensors you might have specified and you must include:
  • bump or bend sensors
  • IR navigation sensors
  • shaft encoders or positional feedback
  • compass or directional sensors
  • grabber sensor (see the grabber section)
Additional (optional) tasks are:
  • implementing any additional processors (if req'd)
  • having the sensors interrupt the HB (if req'd)
  • implementing the sensors on the robot chassis
  • sensor feedback to motors to complete a complex task
Again, feel free to surprise/impress me. I'll want to see a printout and explanation of the code.


Grabber Demo:

You must demonstrate a fully-functional grabbing implement that meets the specifications on the Rules and Regulations page. The grabber must be mounted on your robot. The requirements of the grabber demo include:

  • activating the grabber (you may position the robot beforehand)
  • correctly grabbing the grab ring of the flag
    • "grabbing" means to somehow connect with the ring for the purpose of moving the flag
  • a demonstration of your moving turret (if req'd)
    • ie: your servo or stepper motor must be working!
Additional (optional) demonstrations include:
  • identifying the flag with the flag detector, moving towards it, and grabbing the flag with the grabber (quite difficult!)
  • dragging the flag for a short distance
  • releasing the flag (if that was part of your design objectives)

Again: show me the schematics, mechanical drawings, and code.


Management Stuff:

The member of your group responsible for the management will also cover the following:

  • the availability and cost of all the sensors, processors, motors, etc
  • how resources (time, money, effort, etc) have been allocated
  • any changes in the timeline
  • any management problems
This is a follow-up to the design review, so I expect that you will include a list of all the information that has changed since the review.

Note: You must link your current progress to your design review and explain any changes! Remember that your design review was a proposal to build a certain functionality into your robot. Some details aren't important (ie: using Acme bump switches or Emca bump switches), but others are (ie: using bump switches, or not using them at all).



Progress report (Dec. 3, 2001; individual grade: 5%)

This report presents the status of your work and should make reference to your proposal, show clearly how much progress has been made, make a prediction as to how the rest of the project is likely to develop, and state any variation from the project proposal that now seems necessary.

This is an individual proposal, and you must write everything that you present in your proposal. Reference shared charts or diagrams.

You should be sure to meet the Dept. of Electronics proposal guidelines, and to follow the recommendations outlined in the "Preparing a Fourth-Year Design Project Progress Report" document available from the Report and Presentation Information section of the Course Resources.



Oral presentation (Jan. 21-25, 2001; individual grade: 10%)

You and your team-mates will each present a 10-15 minute report on your 4th-year design project. You will need to introduce and explain the project, outline the design challenges you faced, and detail your solutions.

While you will present as a team (three students will present their design work on one robot), this is an individually-graded presentation, and you must give a good presentation with quality material. Reference shared charts or diagrams.

You should be sure to meet the Dept. of Electronics proposal guidelines, and to follow the recommendations outlined in the "Preparing a Fourth-Year Design Project Oral Presentation" document available from the Report and Presentation Information section of the Course Resources.



Final competition (Mar. 13, 2002; team grade: 5%)



Peer review (Mar. 15, 2002; individual grade: 5%)



Final report (Apr. 8, 2002; individual grade: 50%)

This report presents the status of your work and should make reference to your proposal, show clearly how much progress has been made, make a prediction as to how the rest of the project is likely to develop, and state any variation from the project proposal that now seems necessary.

This is an individual report, and you must write everything that you present. Reference shared charts or diagrams. Be sure to review the Final Report Suggestions.

You should be sure to meet the Dept. of Electronics proposal guidelines, and to follow the recommendations outlined in the "Preparing a Fourth-Year Design Project Final Report" document available from the Report and Presentation Information section of the Course Resources.

 


 
Main Page
|
Course Admin
|
Course Resources
|
Rules & Regulations
|
Team Profiles
|
Photo Gallery
|
Contact Info