Well we tested our LEDs outside for the first time yesterday, and when they were nearly invisible due to the sunlight, we got super bright ones to test today.  These new ones (part number, anyone?) are ultra efficient, but are still barely visible in direct sunlight.  Our verdict is that LEDs are a no-go for the CVC.  Our current plan is to have 6 servos in the CVC (one for each atoll, one for the team color) that will spin color wheels to the appropriate positions.

We were initially worried about how this would affect our meeting the CVC's 8-hour battery life requirement, but found that an unactuated servo (i.e. if we set a position and then leave it there) only draws about 6mA of quiescent current.  This equates to way less of a power draw than our LEDs would have been, anyways.

The last two days of testing showed us that we really need to change some motor mapping according to the accelerometer. The previous motor mapping was based on the fact that I used the y-axis of the accelerometer as the power and the x-axis as the direction, and I used last quarter's mapping, shown below: 

Using the accelerometer in the manner that we did yielded some very unfavorable results. For example, turning the controller completely to the left (keeping y-axis at equilibrium), yielded no turn as there was no power. 

Our new motor mapping instead takes a polar coordinate approach, in which we use the "distance/radius" from the equilibrium (2.5V,2.5V) to determine power, and we use angle to determine direction. Using the newly derived power and direction, we can use the same motor mapping as last quarter with hopefully much better results. Below shows the new way to find power and direction: 

Unfortunately this approach requires the use of functions such arctan and sqrt. I tried using those functions given by math.h, but they ended up taking approximately 60% of program and memory space. The next inclination would be to use a lookup table. I used what I thought was the most minimal lookup table that was acceptable (26 x 26), which would yield about 10 points in each direction, and apparently the compiler could not "find space" for the variable. The last approach would be to make some approximations of the functions to derive power and direction. 

We've arrived at a new set of inputs and controls for our CVC.  Since we've mostly ruled out a propulsion mode that we were secretly considering (more on that at a later date), we don't have much of a use for the balancing plank that we presented at design review.

Our new control method consists of a large (13" diameter) plastic sphere that the user holds.  The user will tilt the sphere forwards and backwards to control speed and side to side to control turning.  The user will squeeze the sphere harder to amply the boat's speed, or he will hold the sphere gently for precise movements.  The user will calibrate the accelerometer by shaking the device to initialize a calibration sequence.  The sensors we will use are:

• 2-Axis ADXL203 (pdf) accelerometer -- this senses the forward/backwards and side-to-side tilt of the sphere for driving the boat.
• Force Sensing Resistor (2128260 at Jameco) -- Two of these, one on each the left and right side of the sphere, will detect that the user is holding the sphere.  They will also measure how hard the user is squeezing the sphere for amplifying the boat's speed.
• Optical Shake Switch -- Inspired by tilt switches, we will make our own "shake switch" that will consist of an opaque weight inside a tube.  When shaken, the weight will travel to the top of the tube and interrupt an IR LED/Sensor pair.  This action will initialize calibration of the accelerometer.
  

The control method that we will be presenting at the design review will consist of a plank with force sensors (for speed control), a steering wheel with accelerometer control (for turning), and a microphone (for capturing an atoll -- we couldn't think of another reason to have a third input method).  We've also been brainstorming about alternative control methods.

One that could be very precise and intuitive to use could consist of a handle (either T-shaped or spherical, for instance) that the user grasps.  The user could tilt this handle forward for speed input, which would be registered by an accelerometer.  The user could also tilt it side-to-side (measured by a multiaxis accelerometer) or slide it horizontally (measured by a linear pot or a rotary pot with some mechanism) for turning movements.  This could be a cool, smooth input method.