Journal:

About Us Downloads Code Project Research Journal

October 15, 2009

Today we got the I-robot and began researching how to send it commands and what those commands do. We obtained the previous programmer(s) code off of the G:\ drive and began looking at it. We plan to meet in a few days in order to sit down and figure out what the code means in order to manipulate it in the way we wish.

October 17, 2009

We went through the existing code and attempted to follow the logic of the previous programmer(s). We added commentation to existing functions to make it easier to follow and to explain what some of the OP codes were used for.
We defined the OP codes being sent to the robot in each array.

October 20, 2009

Today we bagan to explore how to get the sensor to respond to a code. We implimented a "wait until bumped" command which executed well after some tinkering. We had to send the robot two separate arrays, and we will try to improve upon this in future meetings. We would like to be able to get information back from the robot instead of just giving it the information to stop when it hits a wall and back up. This would allow the user to know if the bumper is being pressed. It would also be nice to control the robot with the keyboard instead of using the mouse to click buttons.

November 2, 2009

We attempted to make a function that could be universally used with all of our current functions to make the robot stop when it runs into something. Recall, we've already developed a function we named "Go Until Bumped" which makes the robot go forward until it runs into something, then it stops. We were able to figure out how to call functions from inside functions. Using this knowledge, we modified our current function "Go until bumped". Then inside of the functions "Forward", "Veer Left", and "Veer Right", we called our new and improved "Bump" function. The idea was that each function would do its specified task, but when it would run into something they would stop. There were some flaws however. If we commanded the robot to go forward, it would execute the code to drive forward and call the function to "wait until bumped" just as it was supposed to. The problem is that it would have to wait until it was bumped to matter what. We could not send it anymore commands until it was bumped. So therefore the only way to stop the robot is to bump it. It is unresponsive to the stop command because it is still waiting for the sensor bump. The same problem occured in "veer left" and "veer right"

November 3, 2009

We made our first attempt at reading information from the robot. We've been sending it commands, but haven't been receiving anything in return. We tried doing this two ways. One way is by using a command that would retrieve one packet a time. The other way is to receive data using a stream to check if the sensors were activated. There is a built in function in the robot that sends back data every 15ms on the status of certain things like whether or not bumpers have been pressed. The idea is that we could have this stream running continuously and if we find that one of the data bits representing the bumpers has been set we will command the robot to stop. We have to send the robot a request for certain data packets representing different sensor data. Unfortunately, our implementation attempt was unsuccessful. What we have yet to figure out is how to properly retrieve the information being sent back to us. We don't know how to catch the information and store it.

November 4, 2009

It was a brisk day here in sunny northern Wisconsin. Today we fixed the veer left and veer right functions so they veered a reasonable and equal amount. The previous programmer had different turn radii’s for the veerleft and veerright functions, we changed them to a more reasonable turn radius, and so they were both the same. We’ve also began writing new functions which will make the robot turn differently. We want to write functions to ‘feather’ the turns a bit more. Right now there is only one turn radius available. There’s no other option. We’d like to create a function called “Jog Left” that will make the robot jog left by a radius of maybe eight or ten degrees and then continue on its path. If the user wanted, he could hit “Jog Left” once and the robot would jog left a small portion and keep going forward. The beauty of this is that the user could hit this button as many times in a row as he likes to create his preferred turning radius. We succeeded in writing a “jog left” function. It works as we had planned. We leave tonight feeling victorious. Chalk one up for Team Cat 6.

November 5, 2009

Today we attempted to create text boxes or message boxes in order to display the data sent back to the computer from the robot. In general it was a failure. We did attempt to get some "junk" characters back, but nothing that was meaningful to us. We attempted to strip the ascii from the data that was recived in, but it didn't seem to accept the function call we used.
We will try again more this weekend, and throughout the coming week to see if we can successfully interpret the data that we are retrieving.

November 8, 2009

Today was a success as far as programming goals went. We succeeded in recieving data back from the I-robot Create and inmplimented an If...Then structure to decipher the code coming back from the robot. We touched up alot of the form succeeding in making it a bit less cluttered. After gaining the ability to read in information from the robot we will now attempt to have the robot react when it sends the detection of a bump back to the computer.

November 12, 2009

After researching some ideas on how to detect a button being pressed in Visual Basic 6.0 we decided to try and use the keyboard as a controller for the I-robot instead of having to click buttons to command it. Our next step from here will be to continually check for the sensor to be pressed, and then have the robot respond when it hits something. Some ideas of how to do this would be to use a timer or start the sensor detection when the form loads. We could also possibly call the sensor code when the robot goes forward, left, or right. Overall at this point the project is moving along well, and it seems like we will be able to easily meet all of our pre-set goals.

November 15, 2009

Today we went about buisness trying to set a timer in order to continually call the funciton to check the sensor status. We have run into a problem however because the data sent by the timer "kills" our function to move the robot forward. Therefore we have no way of checking the sensor continually at this point, however we will continue making progress and try and finish this for our presentation.

November 18, 2009

On this day we tied all of the "loose" ends and began gathering our information together and touching up parts of our project. We started on our power point, and gave some color to the form as well as implimented different images for the sensors being bumped. We also gave a text box which displays which arrow key is being pressed, and which direction the robot is traveling in. We divided up the presentation amongst ourselves, and organized the presentation in order of which we completed our objectives.

November 23, 2009

Today we presented our project along with the other groups. This project has helped us gain a better understanding of robotics, visual basic, and html. Overall it was a successful and fun project to have been a part of.