CSSE 120R Final Python Robotics Project—Spring 2009-2010

Project Requirements

The final project for the Python part of this course is to design and implement:

• a GUI that is a robot remote control,
• the robot commands that respond to the remote control, and
• robot line following, using PID control.

Your project must satisfy these core requirements for a passing grade:

1. Your GUI remote control can make the robot:
   • Connect to a port
   • Move forward and backward
   • Spin clockwise and counterclockwise
   • Stop
   • Start and stop line-following
     • Additionally, line-following should stop if a front bumper is bumped.

   Note: The simplest GUI is to use rectangles as buttons: use getMouse to get a click and then see which rectangle the click lies within.

2. Your robot can follow a reasonably wide black line that forms a simple oval track.
3. You have a screen layout that shows your GUI.
   • It can be hand-drawn and need NOT be pretty.
   • It should indicate how the user controls the program, using annotations as needed.
4. You implement your project using an iterative enhancement plan.
   • This means that you implement in stages (four stages for your project — see Milestones below).
   • You choose what each stage should do, with the last stage implementing full functionality.
   • Each stage must be testable by RUNNING the program (without looking at the code). This is a form of black-box testing .
   • It is OK if you reach the deadline for a stage and have not completed all the work for that stage — some replanning is appropriate in this form of agile software development.

     At the end of each stage, in your statusReport.txt document, indicate what part of the stage you did NOT complete (if any), and how your iterative enhancement plan is changed (if any).

5. Your design uses procedural decomposition and documented stubs.
   • Procedural decomposition means that main has (only) several function calls, and each of those functions have (only) several function calls, and so forth.
   • You should design the decomposition using top-down design — decide what functions main needs, then what sub-functions those functions need, and so forth.
   • As a rule of thumb, each function should have two to seven Python statements — not more!
   • Documented stubs means that you write the function as a do-nothing “stub”, then document WHAT the function does in a comment preceding the function (not HOW it does it), and only AFTER documenting it do you implement it.
     • This will help you integrate your work with your teammates' work.
     • It will also help you implement — you can't implement when you don't know WHAT you are implementing.
     • You have to document your functions (see next bullet), so you might as well document BEFORE implementing. It can only help!
6. Your code has good style and is commented appropriately.
7. All team members contribute to and understand all major aspects of the project.

   In particular, each team member should be the lead developer of:

   • some part of the GUI code, AND
   • some part of the robot code, AND
   • some part of the line-following code

   Also, each team member should contribute substantially to the screen layout, the iterative enhancement plan, the procedural decomposition, the style requirements and the documentation.

   Some division of labor is appropriate, as long as the above requirements are met. Each team member should contribute their “fair share” of the total programming effort AND their “fair share” of the overall effort.

For full marks, in addition to the above:

1. The remote control implements additional commands, e.g. speed controls, forward-until-bump, play a song, etc.
2. The GUI features controls beyond mere buttons, e.g. a slider and/or keyboard shortcuts.
3. When the robot is not under direct remote-control (e.g. when it is line-following), the remote-control commands (stop, move forward, etc) interrupt whatever the robot was doing.
4. The robot does PID line-following, as described in this article on PID control for line-following using Lego NXT robots .
   • You should recommend good values for the PID constants and also let the user experiment with their own choices for the PID constants.

Milestones

You will have at least half (and generally more than half) of each session to work on your project. Use your in-class time to:

• Coordinate your work — decide who is doing what.
• Integrate your work — making your functions “play nice” with your teammates' functions.
• Determine when and where you are meeting outside of class.

You will do your work in a repository that you and your teammates share. That repository will have 3 modules:

• person1.py
• person2.py
• person3.py

• A comment at the top of the module should indicate who this module belongs to.
• If you develop a function with one or more teammates (perfectly OK!), put it in one of your modules and have a comment preceding the function indicating who else worked on that function.

Each milestone is due at the end of the listed session (to allow you time for integration during the session), except that the last milestone is due at the beginning of the session. For each milestone, your work should be committed to the repository with a clear commit message indicating that the milestone is completed.

• Session 18:
  • Each team member checks out the repository for the project:

        http://svn.csse.rose-hulman.edu/repos/csse120-201030-teamXX
    

    where XX is your team number as announced by your instructor.
  • You complete a rough draft of your screen layout.
    • The final draft can be assigned to a team member, due at Session 19.
  • You produce the first version of your iterative enhancement plan.
• Session 19: Stage 1 is due. You complete the status report for Stage 1 (in your statusReport.txt file) and adjust your iterative enhancement plan as needed.
• Session 20: Stage 2 is due. You complete the status report for Stage 2 (in your statusReport.txt file) and adjust your iterative enhancement plan as needed.
• Session 21: Stage 3 is due. You complete the status report for Stage 3 (in your statusReport.txt file) and adjust your iterative enhancement plan as needed.
• Session 22: Stage 4 (including your final status report in your statusReport.txt file) is due at the beginning of class.
  • We will move to new material in Session 22.

Grading

I will supply this section ASAP, but you can already see from the above what is required for a C and an A, respectively.

Suggestions

• Plan first! Think about how to use top-down design and/or dictionaries. Get help early if you need it!
• Functions are your friends. Well-written ones will make your life so much easier! Encapsulate functionality!
• Comments are your friends. Doing them BEFORE implementing your functions will save you grief in integrating your work with your teammates's work.
• You will likely have certain information that many functions will need to access. You may want to put all this information in a dictionary object and pass it into the functions. I created a robotInfo dictionary that contained the robot itself, its direction, its linear velocity, and if it was currently sending IR information (which I added as an optional component of my solution). That worked well.
• Test early and test often. Don't write more than a handful of lines of code at a time without testing it.  Sometimes, this will mean writing test code that doesn't make it into your final submission. Welcome to the real world of software development!
• Use the simulator for your first level of testing whereever practical.
• You will likely want to keep track of the various states your robot is in, such as whether or not it is currently line following, connected, etc. You can use Boolean variables for these and check them each iteration of the event loop to see if you have to do that step, like drive a tiny bit around the track.