Out: Wednesday, October 16
Due: Monday, October 28, 2:00pm
Your job is to implement and test a sonar-based freespace follower. There are two ways to get readings from the sonars. The simplest way is to simply ask for the latest range reading that's come in from each sonar. These readings are stored in the signal sonar-readings, which is a vector of 16 integers, one per sonar. Readings from individual sonars can be obtained using the vector-ref primitive:
(vector-ref sonar-readings sonar-number)
will return the last received distance reading on sonar-number. In GRL, primitive procedures are automatically mapped over the elements of vectors, so that (log sonar-readings) gives you a vector of the logarithms of all the sonar readings, and (< sonar-readings 1500) gives you a vector of Booleans telling you which sonar readings are less than 1500. You may also find the following useful:
Returns the largest/smallest value in vector.
Returns the index of the largest/smallest value in vector.
(vector-reduce operator start vector)
Returns the value: start operator e0 operator e1 operator e2 ... operator en, where e0 is the first element of the vector, e1 the second, etc, and en is the last. Thus,
(vector-reduce + 0 v)gives the sum of the elements of
(vector-region vector start-index length)
(vector-region-circular vector start-index length)
Returns a new vector consisting of the length elements from vector starting at position start-index. If the -circular form is used, then the region is allowed to wrap around the end of the vector, i.e. (vector-region sonar-readings 15 3), would return a vector consisting of elements 15, 0, and 1 from sonar-readings, in order.
The problem with using just range readings is that a given sonar is only read
once a second or so, so the range readings are really telling you how far the
closest obstacle was at some point in the past, in this case, up to 1 second
ago. A more sophisticated approach is to use the
vector, gives you a vector (of type
xy-vector) to the object most
recently imaged by each of the sonars. So if you say:
(vector-ref egocentric-ping-positions 3)
you get back a vector giving the estimated distance forward (x component of the vector) and to the left (y component), relative to the robot's current coordinates, of whatever was sonar 3 the time it was fired.
You should encapsulate your freespace follower as a behavior (or as several behaviors). You should try to optimize you system for the following properties, in decreasing order of importance:
It is very likely that your system will get caught in local minima. To prevent this, you should either:
You should also encapsulate your unwedger as a behavior.
The assignment is due Friday October 25 at 2:00pm.
We will have pre-assigned demo slots for each group.
Each group will get four minutes to load your code and four minutes to
You should also prepare a brief (1-3 minute) explanation of how your
system works, which one of you should give during the demo.
You will load your code 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. You should therefore make sure you have your code loaded properly before we begin the demos and you should avoid making any last minute "improvements".
You will be graded based on the number of Bad Things that happen during your demo. Bad Things are:
Collisions (-3 points)
Sudden jerks in the robot's behavior (-1 point)
Getting caught in a local minimum for more than five seconds (-1 point)
Anything else that seems potentially dangerous to Ian and/or Aaron
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 in class the following Thursday.