PmWiki | Student / NikhilsCreateRobotLab

Purpose: Are all of the wheel drops and bumpers functional on the Create?

Materials: Create 0x03

Procedure: 1) Stand the Create up on your lap with the top facing upward and the bottom of the Create facing away from you. 2) After sending the start command into RealTerm (128 131), enter in 142 7. Yellow values will appear in RealTerm. Repeat the command 5 times to make sure you have consistent results. Record the result. 3) Push down just the caster wheel and then send 142 7. Repeat the command 5 times. Record the result. 4) Repeat step 3 but with pushing the left wheel, right wheel, left end of the bumper, and the right end, all one at a time. 5) Push down various combinations of wheels/bumpers and record your results.

Data: Nothing pushed down: 00011100 Caster wheel pushed down: 00001100 Left wheel pushed down: 00010100 Right wheel pushed down: 00011000 Left bumper pushed down: 00011110 Right bumper pushed down: 00011101 Left wheel and right bumper pushed down: 00010101 Caster wheel and right wheel pushed down: 00001011 Left bumper and left wheel pushed down: 00010110

Diagram:

Conclusion: According to the data, all of the individual wheels and bumpers work. In the 8-bit yellow output on RealTerm, the rightmost bit represents the right bumper, and the next bit to the right represents the left bumper. When the bumpers are pushed down, these bits read “1”, and they read a “0” when they are not pushed down, and in the data, when they were pushed down, these bits did read “1”, meaning the bumpers work. The third, fourth, and fifth bits from the right represent the right wheel, left wheel, and the caster wheel, respectively. These bits read “0’s” when the wheels are pushed down, and “1’s” when they are not pushed down, and according to the data they did read “0s” when they were pushed down. Therefore, all the wheels work. The examples of multiple things pushed down at once further prove that they are functional because all the wheels/bumpers pushed down changed to the opposite number in these cases. The three rightmost bits in the yellow 8-bit output are always zero because they don’t represent anything. After understanding the meanings of these numbers, we entered into RealTerm the command 152 8 142 7 137 0x00 0x75 0x7F 0xFF 153 to make the yellow values flow in while the robot was driving, and we noticed that the bits representing the wheels read “0” and the bits representing the bumpers changed to “1” when they bumped into a wall. Thus, the bumpers and wheel drops are all functional. Purpose: How quickly are consecutive OI commands executed by the Create’s microprocessor?

Materials: Create 0x03, stopwatch

Procedure: 1) In RealTerm, enter the command 128 131 to start up the robot and then enter the script command 152 18 137 0x00 0x64 0x7F 0xFF 155 30 137 0xFF 0x9C 0x7F 0xFF 155 30 139 1 0 255 (this command makes the robot drive forward at a velocity of 100 mm/sec, wait until it drives for 3 seconds, then reverse at the same velocity, wait until it drives for 3 seconds, and then turn its “Play” LED green). 2) Enter 153 (the code used to play a script), and start your stop watch as soon as you hit send and then stop it as soon as the “Play” LED turns red. Record the time. 3) Repeat this process 5 times, recording all the stopwatch readings. 4) Find the average of these numbers. Subtract six from this value to get rid of the two 3-second waits. The resulting time is the amount of time it took for the robot to execute the consecutive commands. Excluding the wait bytes, there are 14 bytes in the command. 5) To find the speed at which the robot’s microprocessor executes consecutive commands in bytes per second, do 1 divided by the new time acquired in step 4 and then multiply 14 by this number. This result is the bytes per second speed. 6) Repeat this process with the commands 152 18 145 0x00 0x64 0xFF 0x9C 155 30 145 0xFF 0x9C 0x00 0x64 155 30 139 1 0 255 (this command makes the robot spin counterclockwise at a speed of 100mm/sec, wait until it spins for 3 seconds, then spin clockwise at the same velocity, wait until it spins for 3 seconds, and then turn its “Play” LED green) and 152 18 137 0xFF 0x9C 0xFF 0xFF 155 30 137 0x00 0x64 0xFF 0xFF 155 30 139 1 0 255 (this command makes the robot do the same thing, but it uses the “Drive” command instead of the “Drive Direct” command) to see if you get a similar bytes/sec result, and then average the two numbers for a more accurate result.

Data Tables:

	Trial 1	Trial 2	 Trial 3	Trial 4	 Trial 5	Average

Command 1 6.734 6.807 6.558 6.461 6.400 6.592 Command 2 6.367 6.829 6.752 6.842 6.526 6.663 Command 3 6.375 6.334 6.291 6.259 6.977 6.447

Calculations: Command 1: 6.592 secs – (6 seconds of wait time) = .592 seconds 1 sec/.592 secs = 1.689 secs  14 command bytes not counting wait commands…14 bytes*1.689=23.65 bytes/sec Command 2: 6.663 secs – (6 seconds of wait time) = .663 seconds 1 sec/.663 secs = 1.508 secs  14 command bytes not counting wait commands…14 bytes*1.508=21.11 bytes/sec Command 3: 6.447 secs – (6 seconds of wait time) = .447 seconds 1 sec/.447 secs = 2.237 secs  14 command bytes not counting wait commands…14 bytes*2.237=31.32 bytes/sec (23.65 bytes/sec+21.11 bytes/sec+31.32 bytes/sec)/3 = 25.36 bytes/second

Diagram of robot’s commands :

Conclusion: The Create’s microprocessor can execute consecutive commands at a rate of 25.36 bytes per second, according to the above calculations. Purpose: What can the cliff sensors detect? We believe that the cliff sensors will detect whether or not there is a surface beneath it (in other words, detect when it is on a cliff), and that it will not be able to detect changes in surface texture (course/smooth).

Materials used: Create 0x03, a dry pink sponge, a stack of pink Post-It notes Procedure: 1) Turn the Create upside down and enter 128 131 (the start command) 142 28 into RealTerm to get a reading from the left cliff sensor. Cover the sensor with my hand and hit send. 2) Take your hand off the sensor and hit send. 3) Repeat steps 2 and 3 for the front left cliff, front right cliff, and the right cliff sensor by substituting the 28 in the command (142 28) with a 29, 30, and 31, respectively. 4) Tape a ruler to the side of the Create and then tape a rough, dry, pink sponge to the ruler 5 cm above the left cliff sensor and enter 128 131 and then 142 28. Hit send with this value 10 times and find the average of the produced yellow values. Record this average, and do this for each of the front left, front right, and right cliff sensors by substituting the 28 in the command (142 28) with a 29, 30, and 31, respectively 5) Repeat step 4 but with a stack of smooth, pink post-it notes instead of the pink sponge. Make the stack have the same thickness as the sponge by pulling post-it notes off the stack. Remember to record your values

	Left Cliff (average of 10 outputs)	Front Left Cliff (average of 10 outputs)	Front Right Cliff (average of 10 outputs)	Right Cliff (average of 10 outputs)

Sponge 0 18 0 12 0 11 0 27 Post-It Notes 0 20 0 12 0 10 0 25 Data:

Conclusions: There are separate commands in RealTerm to show the sensors’ state and strength. The state reveals whether or not the sensors sense anything at all using only two numbers—0 and 1. A “0” signifies that the robot does not sense anything, and a “1” signifies that the sensor does sense something. The strength not only reveals whether or not the sensor senses something, but also reveals the intensity of the signal it receives from an object, and thus produces a wider range of values using 2 bytes of data. We chose to examine signal strength because sometimes the robot, especially on low battery, can be a bit unreliable, and the strength is far more descriptive. This robot has a fairly weak strength because all the values obtained are rather small, and they do not go into the 2nd data byte. According to our data from steps 1-3, our hypothesis that the cliff sensors are function is correct. All the cliff sensors sent out nonzero values when covered by my hand, signifying that the sensed some sort of surface beneath them, and they all sent out zeros when I took my hand off, signifying that they didn’t sense anything, and thus the cliff sensors work properly. We put the sponge and stack of post-it notes in front of each sensor to see if the cliff sensor can detect differences in surface texture. We kept the color and thickness of the surface constant because the color and thickness of the surface may affect the sensor readings. According to the yellow data that flowed into RealTerm, the cliff sensors cannot sense differences in texture, because the yellow numbers in each byte can go anywhere between 0 and 255, and all of the values, for both the rough surface and smooth surface, stayed in between 10 and 27, proving that the cliff sensors do not sense a significant difference between the two surfaces and thus cannot detect changes in surface texture, as predicted. Purpose: What can the wall sensor detect? We believe that the wall sensor will detect whether or not there is a wall in front of it, and that it will be able to interpret its relative distance from a wall. Materials: Create 0x03, compass, meter stick, a rectangular tissue box Procedure: 1) Put the robot on the ground tape a meter stick to the front of the Create horizontally with the 35 cm mark at the center of the front of the robot (so that the 50 cm mark lines up with the wall sensor), using a protractor to make sure that the meter stick is perpendicular to the vertical diameter of the Create. You may need to tape the meter stick to the ground so it doesn’t wobble. [see diagram below] 2) Stand up the tissue box so that the front edge of it lines up with the 52 cm mark (this way it is right up against the side of the robot, and since the edge is lined up with the meter stick, the box won’t slant or tilt). 3) Enter 128 131 into RealTerm to make the robot start up and then hit 142 27 to retrieve the signal strength. Enter this command 10 times and find the average of your results. Record this average. Also do this with the command 142 27 to retrieve the signal state, and record your result. 4) Repeat step 4 with the tissue box’s front edge lining up with the 54 cm mark, the 56 cm mark, and then as many intervals of 2 as you can go while still getting nonzero yellow values in Realterm. 5) Repeat steps 1-4 with a different colored tissue box to make sure the color does not have a big impact on the yellow values. 6) Repeal steps 1-4 with something thin like a notebook to make sure thickness of the wall does not have a huge affect on the yellow values. Data:

Conclusion: According to our data, the wall sensor can detect the robot’s relative distance from a wall, because as we moved the robot further and further, the yellow values that appeared on RealTerm became smaller and smaller. The color change and the thickness change of the wall had an affect on the yellow numbers, but we can still see that as you move an object farther from the wall, the signal’s strength decreases. According to other cohort members, the wall sensor readings are highest when the wall is parallel to the Create’s vertical diameter. Thus, we used a protractor to make the meter stick perpendicular to the vertical diameter, because when we stood up a wall perpendicular to the meter stick, the wall had to be paralled to the vertical diameter. The signal strength in this case is directly related to the distance of the wall from the robot, as demonstrated by the above data. This robot has a fairly low strength, because none of the values obtained went into the second yellow data byte. The state of the data, like with the cliff sensors, ranges from 0-1, where “0” means that no wall is sensed and “1” means that a wall is sensed. Looking at the data table, however, it appears that at times the state was “0” even when the strength said a wall was sensed. Once the data passed a certain point—about 0 90—it started giving out “1’s” for signal strength, meaning that the state doesn’t include strengths under 0 90. The greatest distance the wall sensor can detect varies with the thickness of the wall, but we haven’t seen the wall sensor sense a wall more than 10 cm away from the sensor. But all in all, the wall sensors can detect the presence of a wall and the Create’s relative distance from that wall. Purpose: What is the physical meaning of the radius when using the Drive Command? We think that it refers to the radius of the circle traveled by the center of the robot. Materials used: Create 0x03, pencil, pipe cutter, tape, white paper, measuring tape that uses metric system Procedure: 1) Roll out as much white paper needed to cover an area of about 3ft x 3ft 2) Use a pipe cutter to cut a pencil to a length of 2.5 cm from the tip. Tape this tip to the center of the bottom of the Create 3) Place the robot in the middle of the area of white paper and send 128 131 into RealTerm, and then a Drive Command: 137 0 80 0 150 (this makes the robot move counterclockwise at a velocity of 80mm/second and at a radius—the meaning of while will be determined in the conclusion—of 100mm) 4) Measure the radius of the circle drawn by the marker at the front of the moving Create using a measuring tape and record this value. 5) Repeat Steps 4 and 5 but with the command 137 0 80 0 500 (this makes the robot move counterclockwise at a velocity of 80 mm/second at a radius of 500 mm) and then with the command 137 0x00 0x50 0xFF 0x06 (this makes the robot move clockwise at a velocity of 80 mm/second at a radius of 250 mm)

Diagram:

	Radius Specified in RealTerm	Radius of Circle Drawn by Pencil

Trial 1 150 mm 150 mm Trial 2 500 mm 500mm Trial 3 250 mm 250 mm Data Table:

Conclusion: According to the results, the radius entered in the 3rd and 4th bytes of the open interface commands on RealTerm refers to the radius of the circle traveled by the center of the Create, because the values for the radii entered in RealTerm equaled the radii drawn in each of the three trials, and the pencil was located in the center of the Create. If we put the marker on the front of the robot, the radius of our drawn circle would be much larger because the front of the robot travels a larger path then the center (shown in diagram above). The Create’s designers have two different drive commands because one of them allows you to control each wheel independently (the “Drive Direct” command) and one does not “the “Drive’ command). The Drive Direct command makes it easier to switch in between circling clockwise and counterclockwise because to make it move clockwise you’d just have to tell the Create to move the left wheel at a faster speed than the right wheel, and do the opposite if you want it to go clockwise, but this makes it difficult to control the radius of the circle traveled by the center of the Create. The Drive command allows you to easily control the radius of the circle traveled by the center of the Create, but changing from counterclockwise to clockwise is more difficult because you have to take hexadecimal numbers and calculate their complements. I prefer to use the Drive Direct command because I don’t usually need to make the robot move in a circle of a certain radius, and I don’t want to have to calculate hexadecimal complements. I think the Create designers most likely would prefer to use the Drive Direct command, as well, because it allows them to have more “direct” control over the wheels, and they probably have the knowledge and skill to move the robot wherever they want just by adjusting the wheel speeds, and the drive command wouldn’t allow them to do that.