Testing from week five
Now I have this thing that can move. I took three trials recording what the sensors thought the light content was. One light had been turned off in my room on the third trial (leaving about 120 ambient watts). The results are as follows:
| |
Trial 1 |
Trial 2 |
Trial 3 |
| Sensors |
White |
Black |
White |
Black |
White |
Black |
| 1 |
57 |
39 |
55 |
38 |
54 |
37 |
| 2 |
49 |
30 |
48 |
29 |
47 |
28 |
| 3 |
27 |
26 |
26 |
26 |
26 |
26 |
Clearly, I have to replace sensor 3, which was previously implicated in being deficient .15V compared to the others. Interestingly, the sensors 1 and 2 had declining values, which could have been due to subtle declines in battery charge, to how long the sensors had been on continuously, or to how much I was blocking the light at a particular time.
One question raised was how to assure that the robot would consistently and accurately make a right-angle turn without having to check its own progress in doing so. While running my current program which has the motors turn on at various times in different directions, I monitored the voltage the motors. Given the current equipment (two hands, one multimeter), I can only check one motor at a time. Thus, it was not possible to determine whether the motors necessarily had exactly the same voltage at the same time. In a given run, voltages remained similar to the .03V. Usually, with the battery charge being listed as 8.0V (according to the RCX), measured voltage was about 7.33V, though one trial with motor C got a wider range around 6.4V. This may or may not mean that the brick will have to check its position after it thinks it has turned.
Moderately interesting stuff from week four
I built the robot, though I can't get the software to work. When doing a test run using the default programs, I noticed that the robot was veering off to one side. All of this is done with the brick displaying "1" for the first default program, using new nonrechargeable alkaline batteries in the RCX 2.0.
- At rest, one of the the motors will turn freely, and the other one makes clicky noises
- When running, this motor consistently receives about 8.46V, compared to the freely-turning one's 8.70V
- This motor is also connected with a wire that has slight insulation degradation
- Changing the connecting wire does not alter the voltage through that motor
- Between various places within one of these wires, the resistance measures inconsistently between .2 and 2 ohms, though usually about .2-.4?
- Switching out the 8.46V-motor led to new motor voltages of 8.68 (formerly 8.70) and 8.65 (new)
- The robot now moves much smoother
I have three light sensors on this thing. At rest (in default LegOS, not leJOS), the voltages going through these things are (1, 2, 3) 2.544, 2.565, and 2.400 (all measured a few times to check consistency). Moving the wires one over to the right, (still reading left to right, 1 through 3) 2.401, 2.544, and 2.564. The sensor that sucks 2.4V has an extremely long wire with mildly oxidized insulation and a severely oxidized rubber band taming the wire. The 2.54V-sensor has slightly more oxidized insulation than the 2.56 one, though just barely. The moral of this story is that not all of the Lego components are consistent with one another. The condition of its plastirubber components may predict how the item performs. Whether this proves significant for the light sensors the way it was for the motors will remain unknown until the leJOS software can be installed properly.
I put a beaver paddle on the back. This may turn into a second set of wheels, or into a drag button.
Slightly more interesting stuff from week three
Maze design
I'm going to have a LegoBot navigate a maze.
Constraints
- Three motors
- Three sensors (bumper or dark/light)
- Relatively clumsy motion
- February 23
-
- (not alive, can't see the whole thing at once, not a Mirabot, etc)
At first I wanted to build a physical maze with solid walls. However, to navigate this adequately, I would need more than three sensors so I could put the bot in reverse and still have it be able to detect if there is a wall on either side when it tries to turn. Also, when navigating like this, the robot would have to make a klutzy three-point (or ten) turn
The next idea was to draw a maze in black on white paper, using the infrared sensors rather than the push-button touch sensors. Still, this does not get around having to turn around.
So, the current plan is to draw a white-on-black maze and have the robot follow the white stripe like a track. Then, navigation can focus on figuring out the maze rather than how to determine whether or not the robot has an option to turn. Though not optimal, the robot can backtrack and still rely on sensors in the front to determine where the stripe is. The robot may then find itself in a position where its back end is off the track.
The maze will have right-angle turns, and there will be some minimum distance between turns. The stripe will probably be about two centimeters wide, and will remain constant.
About the Hardware
- The v1.0 has a port for an AC adapter. It is also heavier than v2.0. This is because (to be determined).
- When downloading the firmware, the tower and the RCX did not seem to mind when a hand was interposed for several seconds.
