Group Assignment 1: Wandering aimlessly

Out: Monday, October 7
Due: Monday, October 14, 2:00PM.

 

WARNINGS

  1. Always work in groups. Don't operate the robot alone and make sure that there's always someone looking over your shoulder when you run it. This is more for the robot's safety than for yours.
  2. Don't even think about drinking beverages around the robot.
  3. Always stop and think before enabling the motors. Did you unhook the tether (serial cable) to the workstation? Is everyone clear of the robot? Are you ready to hit the kill switch if there is a problem?
  4. Do not operate the robot at unsafe speeds. The robot is operating at an unsafe speed if: Y
  5. It is easy to destroy lead-acid batteries if you abuse them. Normal use should not lead to any significant problems during the class. However, if you run the batteries down too far, you will permanently age them. You should always check the battery voltage of the robot before you start, after you are finished, and periodically while you work. If the voltage ever drops below 22.5V, you should shutdown the robot and change out its batteries. Simply follow the instructions in the Magellan manual handed out in class. There will be an extra set of batteries kept charging at all times.
  6. "It was already broken when I started" is not an acceptable excuse. If there is a problem with the robot, stop working immediately and inform Ian, Aaron, or someone else from the robot lab.
  7. Batteries are $300/set. You break 'em you buy 'em.

If you violate the safety rules your entire group will be kicked out of the course. There will be no exceptions.

Your assignment

In the file assignment1.scm, you will find the following code:

;;;;;
;;;;; CS 395 Behavior-Based Robotics
;;;;; Fall 2000 Assignment 1 
;;;;;

;;;;
;;;; VISION SYSTEM DEFINITIONS
;;;;
;;;; Left-distance, right-distance, and center-distance are each numbers
;;;; that range from 0-100.  They tell how much freespace is in each
;;;; direction.  However, they are not calibrated or linear measures.
;;;;

(define-signal polly
  (color-polly-pipeline 'smoothing-factor 3 'edge-threshold 20))
(define-signal left-distance
  (polly-left-distance polly))
(define-signal right-distance
  (polly-right-distance polly))
(define-signal center-distance
  (polly-center-distance polly))

;;;;
;;;; BASIC FREESPACE FOLLOWING POLICY
;;;;
;;;; You can tune the numbers here.
;;;;

(define-signal stopping-distance 33)
(define-signal freespace-follower-gains
  (rt-vector 100 200))

(define-signal orientation-error
  (- left-distance right-distance))
(define-signal distance-error
  (- center-distance stopping-distance))

(define-signal freespace-policy
  (* (rt-vector orientation-error
		distance-error)
     freespace-follower-gains))

;;;;
;;;; UNWEDGING POLICY
;;;;
;;;; You fill this in with whatever you want.
;;;;

(define-signal unwedging-policy
  (rt-vector 1000 0))

;;;;
;;;; STUCK DETECTOR
;;;;
;;;; You fill this in too
;;;;

(define-signal stuck?
  (< center-distance 50))
;;;;
;;;; RUN IT
;;;;

(try-signals (drive-base
	      (if stuck?
		  unwedging-policy
		  freespace-policy))
	     (blink-events stuck?)
	     (show-polly polly))

This is a boilerplate for a wandering program.  A wandering program simply tries to drive around, covering as much ground as possible without hitting anything.  The part shown in green shows is what actually moves the base around.  It says that if the signal stuck? is true, it should use the rt-vector computed by unwedging-policy, which rotates in place, otherwise, it should use the vector computed by freespace-policy, which just follows freespace.

While this version works, it isn't very good.  It's both too slow and somewhat unstable.  You job is to write a better wandering program.  You should start by modifying the parts shown in red.  That is, you should tune the freespace follower so that it has better performance, and you should come up with a better, or at least faster, unwedging policy, you should tune the freespace follower, and you should improve the definition of stuck?.

Demos

All group assignments will be publically demoed for the class.  Each team will get one chance to demo their program.  The demos will be held sometime after class.  We will discuss demo times in class on Thursday to figure out when will be convenient.  At least one person from each team should show up to demo their program.  If for some reason that's not possible, we can arrange a time for a make-up demo.

Each group will get a maximum of 5 minutes for their demo.  As you demonstrate your system, one of you will also give a brief explanation of how your system works.  We will use two robots, with one team demoing on one robot, while the next team sets up on the other robot.  Since time is short, you must download while the previous team is demoing.  If you are not ready to demo at the appointed time, your team will be skipped and your assignment will be counted as late.  So don't try doing any last-minute "improvements" - that's the most common way for people to bomb an assignment.

Grading

The demo will be graded based on the number of Bad Things that happen during your demo.  The official list of Bad Things is:

In addition, we will allow the class to award 0-5 points each for subjective speed, subjective smoothness, and cool factor.  Finally, Ian and Aaron will assign 0-10 points based on overall quality of both the robot's behavior and of your code.  We will then curve all of this and announce the results on the newsgroup.