Journal

January 4, 2000
Today we thought about the strategy that we want to employ in our robot. After turning over several different ideas, we'd like to build a robot which quickly scoops up most of the blocks, then sorts them using an optical sensor, deposits the professors and students in opposite team's jail, and holds the hackers. We are thinking of using a 45-45-90 shaped "funnel" to gather the pieces. We experimented with building strong angles out of the Lego and came up with a few methods, but nothing we find completely satisfactory.

January 5, 2000
Today we learned about the different types of sensors available and decided to use refractive sensors to differentiate between blocks. We also thought about different sorting mechanisms. Ideas, which came up, included a conveyor belt, flippers, and a revolving "door" which is the idea we settled on because it seemed the simplest, and the least likely to have mix ups.

January 6, 2000
We went to look at the board today, which gave us a much better idea of the magnitude of our task. We're fine-tuning our ideas. We have a ramp built which with luck will lift the blocks up to the sorting mechanism so that they can be dropped down into the bins for delivery.

January 7, 2000
Today we finalized our strategy and came up for plans in case we don't end up where we ultimately want to which is in the opponent's jail. We also divided up the labor so that each of us knows exactly what to do, though there will be a lot of cross over during testing and debugging.

January 9, 2000
We encountered difficulties when testing our robot on the board. We had originally decided upon a simple design, which would keep the blocks on the ground and drag them around. However, because of the "features" such as cracks in the table, this became impossible as the block would get stuck and then flip out of the robot, raising the robot momentarily in the air and causing a dangerous situation. And losing blocks. We experimented with other methods of keeping the blocks from being tipped by the back of the robot, such as a rotary wheel to keep the blocks jumping, but have decided that probably the best plan of action is to lift the blocks off the ground which greatly complicates our robot. At least the line following code will be the same. On the better end, our robot goes forward and turns!

January 11, 2000
We experimented with different conveyor belt configurations but couldn't really come up with anything that we thought would be reliable. We came up with a nice bin configuration when a motor pulls out a rod and then the bin falls down. Not much code could be written because we didn't have a final line-following-sensor layout.

January 12, 2000
We have a new design. Our conveyor belt is vertical. When the blocks come in they will be wedged between the conveyor belt and a door. They will move up to the top and be sorted into one of two bins by a revolving door-type mechanism.

January 14, 2000
We have been learning about the API and writing pseudo-code. We will probably have to write a few new classes because to make things easier we'd want the line-following sensors to tell us not only how much light is reflected, but easily tell us which color we're over, using 0's and 1's.

January 15, 2000
We've been working on wiring up sensors and motors. We're mainly using trapezoidal light sensors because the two main tasks we're doing are sorting blocks and following a line.

January 17, 2000
We've been working on a lot of pseudo code for the past two days and filling in the details as we become more familiar with our robot and the API.

January 18, 2000
Today we picked up our board in lab. We also went to ask about alternatives to using threads in our code. We decided that threads were too complicated and began to write the pseudo-code for the block-sorting function that would change a global variable according to what point in the function it was at. For example if there were a block in the sorter, the door would close, and set the variable to 2. Then, when the sorting function is called again, the conveyor belt would turn on, and set the variable to 3, etc. We plan to have a while loop which alternates between short calls to the navigation and sorting functions. Of course, we also had to return our skiff boards today.

January 19, 2000
Given the option, we decided to use the handy boards from two years ago. While we will have to rewrite code, C is simpler than Java and the board is much more reliable. Also, it is lighter because of the internal batteries and the number of ports is sufficient for what we intend to do. The calls to ports directly rather than using an API also seemed better.

January 20, 2000
We spent today learning IC and changing code from Java. Another major advantage of IC is the ability to do multi-tasking (which is similar to threads). It really makes our code so much simpler to write.

January 23, 2000
Today we worked on line following. We are using five sensors on the bottom of our robot for navigation. We had a function written in IC which we assumed would work, but of course real life is not ideal and it didn't run as well as we had hoped. The corrections were too much and it didn't really seem to be correcting for everything, though it did print out the correct messages on the LCD. The robot's structure is finally finished and most of the sensors are in place.

January 24, 2000
We realized that the problem with our line following was that we were differentiating between white, blue, and black rather than just between white and blue/black. Thus, our line color function would return 0, -1 , or 1 and -1 never told the line following function what to do, which was the reason for all the jumpy corrections. After that we simplified our line following to just 3 sensors in the middle of the robot. We also worked on right and left turns, getting a pretty good left turn. But our robot was not balanced because the handy board resides on the left, so it took longer to get the right turns to work. After that, the robot worked pretty well and went where it was supposed to.

January 25, 2000
Today we changed our route on the board. By snaking around the table we would have the chance to pick up a lot of blocks, but all the turns made us lose them, ending up with a very few number in the end. So, we decided to turn at each end to get in and out of jail, but go straight the rest of the time. Thus, we had to alter our navigation function a little, but it was easy because the lower level code was already written. We also worked a lot fine-tuning our turns and straight drives. At the qualifying round we went up against a robot that only picked up one hacker and returned to jail. We were pretty sure we could beat them, but something went wrong and our robot just turned in a clockwise circle once and stopped.

January 26, 2000
We spent an hour in the morning trying to figure out why our robot didn't do anything more than spin during the first round. We looked at our code, but were very confused because the robot had worked correctly with the same code in lab. We also ran a few test runs and the robot malfunctioned. Finally, we realized that on of the motors had come unsoldered from its wire and wasn't running. Luckily it was so simple to fix. The rest of the day we spent perfecting our turns and runs and also our dumping routine. Three hours before impounding we had a little extra time so we worked on bump sensors and wrote a little code. The robot didn't seem to be responding, so we just left the code at the end of the line following function in case the robot got way off course. The name we decided upon for our robot was "9th Wonder of the World" (partially named after the World Wrestling Federation's Chyna but mostly 'cause it's just a cool name.)

January 27, 2000
The second round was quite nerve wracking with a double win of 3-3 with Quik Chow. We lost the first evening round, but were just happy to make it that far.