NEAT+2dot3

Okay, I reached a good stopping point on my crane. One thing I have not tried at all is the program instructions provided by the hardware designer. Had some discussion with Dr. Steele about the "diminishing returns" on further adjustments to my crane robot. There are a number of overlapping, mutually exacerbating issues: "Gear Lash" is the amount of inexactness of the location of an item at the end of a gear train. Just as the gear ratio multiplies, the amount of looseness between meshing surfaces of the teeth of different gears has a cumulative effect as the power is transmitted through several pairs of mating gears. One solution might employ a concept called "loading" in which the location can be more exactly determined if the object at the end of the gear train is moving in the same direction. So instead of moving clockwise from the beginning to the end of the arc inside of which the ultrasonic sensor detects an object at a distance less than 20 cm, then backing up half of that distance, it might be far more accurate to back up, say, three times the measured arc, then move forward 3.5 times that same distance. Another suggestion (Nathan) is to do no backing up, instead, measure the width of the object, measure the full circle, then add half the width. For example, if the motor turns 1.000 rotations with the object in range, and 10.000 rotations from first detecting it to first detecting again on the next revolution, then an additional 0.5 motor rotations should position the claw directly above the center of mass of the object. A different design for the robotic arm called [|SCARA is discussed here].

The ultrasonic sensor has any number of issues of its own. In the cranebot application, it is mounted at an oblique angle, perhaps ten degrees lower than parallel to the surface on which the crane sits. Its two "Wally eyes" are in fact an emitter and a receiver. The emitter generates sound waves in an irregular conic projection, and the receiver, mounted next to it measures the time it takes for the waves to bounce back from a solid object anywhere within the cone. In this case, the object it is seeking is a spheroid, and the first waves to hit it would be not only tangential to the "edge" but would hit it at a point further away from sensor than is the center of the ball.

The light sensor has further problems of its own. It is actually an infrared sensor with the ability to read the intensity of light it receives. It cannot read frequency of light waves. I visualize it as reading shades of gray, with white being the lightest possible "shade" and black the darkest. While it works reasonably accurately reading the intensity of light reflected back to it from a surface illuminated by its red LED from a very short distance (ideally less than 1 cm), it works rather badly reading ambient light.

What I need to get to next is documenting some applications of robotics for elementary school math and science. One thing that occurs to me as a good styarting point is to run some little car-like machines without any sensors. This might be more palatable if I phrase this in terms of using only two sensors: the rotation sensor built into the servomotor, and the time sensor (internal clock) built into the microcomputer.("Smart Brick" or simply "NXT."

The broad concepts that I want for kids to get from their hands-on experiences with the robot are the following: A. Gain a sense of personal power from the realization that they can B. Realize that their own decisions generate data C. Data, in turn, can inform further decisions
 * program a computer
 * control a machine