|
|
Go to: Objective Pictures Hardware List Coding/Algorithms Problems Conclusion |
Objective: Hardware List:
Coding/Algorithms: December 12, 2004- We are planning to team up with our associate, JC&S Enterprise, to help find a general maze algorithm, although our project may not require it. January 6, 2005- Jeffrey's finished coding the stack algorithm. Our associate's site has frames. In case your browser cannot support frames, we'll save you a trip there and post the code here for you. Stack Coding January 7, 2005- Jennifer is working on the general maze algorithm with our associate, Jeffrey Sung. So far, she is thinking about a "follow forward bot." This robot follows the following algorithm: Supposedly, this algorithm will help the robot get out of an island, if started on an island. The trouble with this algorithm is that it requires a stack, which is complex and does not exist in Basic. Everything rests on Jeffrey's stack algorithm working correctly. In addition to this, this algorithm has not actually been tested in a real maze before. Of course, it should work in theory, but theory and the actual working of the robot are vastly different. And finally, the coding for the robot to make a five-pointed star does not work as it should. If we cannot get the robot to make a five-pointed star, will we understand enough to make the robot accurate enough to travel in straight lines in the maze? January 10, 2004- Today we start coding, despite the fact that we haven't exactly figured out how to control the digital encoder. January 25, 2005-Okay, we couldn't figure out what's wrong with our bot, and we ran out of time. Here's some coding. Maybe you guys could figure out why it doesn't work? Here's our code Problems: January 10, 2005- We figured out that we don't need to know how to control the bot to make a five pointed star. It's a waste of time; all we need to do is just make the bot turn a perfect 90 degree angle. January 20, 2005- We're almost done with coding the robot. We ran into a couple problems with the IR sensors (they kept on burning.) But the problems are fixed. Jennifer is almost done with soldering the sound activated relay. Hopefully, she didn't put in any capcitors or diodes in backwards. All we have left to do is to find a microphone to go with the sound activated relay, get the IRs to be less unstable, and get perfect 90 degree turn. There's really no real way to fix this except to experiment over and over with the numbers. One thing about this project is that you really learn the difference in something working in theory and something that actually works in real life. Finally, we still need to take pictures of our robot- it looks impressive with all the wires and the soldering on the sound activated relay. We're becoming more and more efficient with our time as semester quickly draws to a close... There are only two more days left in the semester (other than this one), and the pressure is building. January 24, 2005- ARGGHHH, the robot pops data out of its stack WAY too soon. Our best guess is that sometimes the IRs flicker, which causes the robot to pop whatever is on top of its stack and thus, run straight into a wall. On top of that, there is only one way to reset the data on the EEPROM, that is, to redownload the coding onto the boebot. We were wondering why the boebot was popping such random turns for a very long time. Conclusion: Okay, you guys have seen all the problems that we've run into; now the question is what did we get to work? Well there are a couple things: the VOX voice activated relay seemed to work. And we got the turns to be pretty much perfect 90 degree turns. There is no elegant way to discover the digits for a perfect 90 degree turn; it's just a crude guess and check method that you have to do. As for the voice activated relay, it wasn't hard to put together. The kit came with instructions on what to put and where. As long as you pay attention to what end is positive and what end is negative of capacitors and other things, it should be easy to assemble together. There are a host of things that we didn't get to work... You can check the Problems section if you want a list of them. One major problem that plagued our robot was unreliability. In other words, we couldn't completely depend on our IRs because sometimes they would flicker from zeros to ones or vice versa. This would cause the robot to think that it was at an intersection and pop the pervious turn that it had or push something into its "stack." In addition to that, the new wheels that came with the digital encoder kit had really, really bad traction. They would always slip over tape. Of course, our boebot depended greatly on precision, so a simple slip on the tape, on a turn, would completely mess up our bot. And finally, one of our major problems that we ran into was the issue of time. Had we had more time, we might have finished this project. Here's some advice: you only have 1 hour a day to work on this project. About ten minutes is spent up putting the bot in and out of the locker and packing up/ putting your belongings down in class. Don't waste your time doing anything other than doing the project, like eating, or talking. Finally, what was it that we learned? Well, for one thing, we now know how to solder things together, and that we do not need to use too much flux on the metal when soldering, otherwise, it creates this black, disgusting-looking fluid on whatever we're working on. Second, we learned that whenever we're working on theoretical things, we have infinite precision, or as much precision as we want. But this usually isn't the case in the real world. That's all we've got.... |
