Team Six/Journal

From Maslab 2007

Monday, January 8

Today we got the MASLab kit containing a PCB and several components for the OrcPad, an OrcBoard, a pegboard, a computer (800 MHz, 256 MB RAM, 20 GB HDD), a webcam, a battery, motors, wheels etc. We soldered the given components on the OrcPad PCB. I made the mistake of mounting the bigger components before surface mounting the tiny ones, but in the end everything worked out.

After successfully booting the computer with the OrcPad LCD as the display, we assembled the pegbot. Unfortunately, the USB cable in our computer was faulty so we had to assemble/disassemble the bot a couple of times. After several failed attempts to get the USB port for the wireless card working, we unplugged the camera and used the USB port for the wireless card.

Tuesday, January 9

We continued to have troubles with the wireless, so we had to use a wired ethernet connection.

We began working with the infrared sensors. It took us a little while to figure out how to connect a sensor properly, but we eventually got it to work. We got our robot to stop when it encounters a wall and to publish data to the BotClient.

Toward the end of the day we began thinking about how to design the robot and how to do image processing.

Wednesday, January 10

We began the day by discussing how we want to construct our robot. It will be a cylindrical robot to minimize catching on edges, and we will make it two stories tall to make it as compact (though not hausdorff) as possible.

We got our camera to work and coded a fairly simple heuristic for finding and driving to red balls. It may need some tweaking but it seems to work pretty well. It tends to stop a little short of its target though. The robot initially had a fear of red balls since our code reversed forward and backward and left and right for the motors. During one of the tests, the wires came off of one of the motors so we had to re-solder them.

Thursday, January 11

We discussed our plans with the Maslab staff this morning. They suggested that our mechanical plans our on the ambitious side, which is probably bad since we're math majors. We might want to find a simpler way to lift the balls.

We built a prototype for the ball holding level. We had intended on making it V-shaped but now we think we might make it flat and use rails to guide the balls instead.

Friday, January 12

Anand and Dan are doing Mystery Hunt, so we probably aren't going to be too productive this weekend.

Saturday, January 13

Sunday, January 14

Yaim and I built a prototype chassis for our robot. Considering that we only had rough plans, the final result was quite good and we built it in about 3 hours. This means that if we decide to change our design for some reason, we can rebuild the chassis in one day. We also went to a hardware store to look for some material for our corkscrew. We tried building prototype corkscrews out of thick metal wire but they didn't work too well.

Monday, January 15

Today was a somewhat productive but mostly frustrating day. Dan spent most of it coding the robot to find goals and center on them, while Anand and Yaim tried a whole host of little projects, trying to get various pieces of the chassis working. In the end, the robot was able to recognize goals and drive up to them, but not in a very centered way. Tomorrow we'll work on the code more, and hopefully both fix that and introduce wandering behavior.

On the mechanical side, our archimedes screw is well formed and works once the ball is in it, but we're having a lot of trouble getting the ball into the screw in the first place. Oops. We're talking about just paddling the ball up, but we'll see...

Tuesday, January 16

Dan wrote some wall-following code while Anand and Yaim kept working on the archimedes screw. We now have a hook attached to the botton end of the screw to get the initial lift. We mounted the screw on the robot but had trouble getting the motor to work so we couldn't test it. Meanwhile we got 2 more short range IR sensors and mounted them on either side of the robot. We'll test the wall-following code tomorrow.

Wednesday, January 17

Our robot had many problems today. Some wires for one of the motors and one of the IR sensors came loose, so we had to fix them. The computer appeared to be getting very hot, so Anand attached a fan to it. Our OrcPad stops responding after a while and we still don't have a working third USB for wireless, so we had to test the robot by typing "sleep 20; java RobotMain" and then disconnecting the keyboard and connecting the camera in its place. We are ready to begin testing our wandering code and some new goal docking code tomorrow morning.

There wasn't any room for an IR sensor on what had been the front of our pegbot, so we put one on what had been the back. Now the pegbot has rear wheel drive instead of front wheel drive.

We can't seem to get the Archimedes screw to work. Perhaps we can find a high torque motor and use a paddle wheel instead or just keep the balls on the ground.

Thursday, January 18

Today was much more productive than yesterday. After the checkpoint meeting, we decided to drop the corkscrew idea and go with the simple 'ram the balls into the goal' mechanism. We modified our design accordingly and constructed a new prototype. We plan to build the final robot next week.

The OrcPad problem solved itself. We got a USB hub and a new wireless card. Dan tested most of the untested code (wandering, finding the ball, finding the goal). We noticed that the robot was turning so fast that it lost sight of the ball before it could track it. We will have to do something about it soon.

Friday, January 19

During the mock contest today, our robot moved around a lot but didn't seem all that interested in balls. We later found out that it was because the image processing code depended on the camera on the camera being on a certain height, and it was much higher on our chassis than on the pegbot.

Saturday, January 20

Today we all got a lot done. Dan rewrote most of the wandering code, to make the robot follow walls, and get stuck less. We'll test that tomorrow - hopefully it works! Yaim and Anand built the one way gate, new l-brackets to lower the wheels, and basically finished the prototype robot. They'll build the final robot in a few days.

We had some excitement, too - at some point the wheels stopped working, and after about 2 hours we figured out it was because 1. a fuse was blown and 2. the orcboard for some reason had stopped sending strong signals to the wheels: when the program told the wheels to go at full speed, the orcboard was giving a voltage of ~.2-2 Volts - 1/100 or 1/10 of the voltage needed to actually drive the weels at full speed! Val gave us a new orcboard, and that seemed to fix everything.

So, test test test tomorrow!!

Sunday, January 21

Today was extensive testing day. We experimented with different camera positions, angles and did lots of test runs.

We realized the the ramming mechanism we had thought of before (opening the gates, ramming the balls using the rear end of the robot) does not work because the balls don't travel too far when the robot stops. In fact, they hardly cross the gate. Therefore we decided that we'd open the gate, back up, close the gate and push the balls into the goal using the gate. This means that we will need to align the robot (almost) perfectly with the goal.

We made a rough sketch for the final version of the robot. Anand is supposed to make an isometric drawing

Monday, January 22

Dan found the optimal angle and height for the camera by maximizing the horizontal distance it can see given the angular span of the camera and the height of the walls. However, the optimal height was on the order of a meter, so it's not feasible.

Dan started writing code to make the robot find gaps in the walls (so that it can go to different "rooms") by looking at the height of the blue line. However, we realized that the camera does not always see the blue line. To counteract this, we thought of mounting the camera on a servo; we don't know if we are going to do that yet. Instead, we now look at the carpet and the lower edge of the walls to find gaps instead of the blue line.

Tuesday, January 23

We mounted the IR sensors and the camera so that we don't have to adjust the duct tape every time we test the robot. We tested the gap finding code. It works pretty well, except that sometimes it gets stuck on corners. Apparently, none of the IR sensors can detect the obstacle in many of these cases, so we need some mechanism to detect that we are stuck. So we got 2 quadphase optical encoders and soldered the circuit boards.

Wednesday, January 24

Completed the construction of the quadphase encoders and mounted them on the wheels. Dan wrote code to use the encoders to detect if we are stuck.

Thursday, January 25

Mock contest: For the first run, Dan commented out the untested IR sensor code so our robot relied solely on the encoders and the camera. However, the wheels continued rotating when the robot got stuck, so we had to nudge it a couple of times. It seemed to be able to find gaps well, but would get stuck on the corners instead of going through the gap.

For the second run, we included the IR sensor code and the robot functioned a lot better. It collected five balls. It could have collected more it were not spinning as fast.

We came back to the lab and started working on the docking code. We thought of ideas to align the robot with the goal (find the angle of the horizontal yellow line) and tested some of them.

Friday, January 26

Yaim and I started building the new robot. It is ~14" in diameter (~2" bigger than the old robot). Unlike the old robot, the wheels on the new bot don't stick out. The battery is mounted on the first floor, making the robot more stable and eliminating the need for the two front casters.

We finished cutting wood, making parts for the gate, attaching the L-brackets and the motors and drilling holes for dowels and zipties. We will assemble it together tomorrow.

Saturday, January 27

We continued building the final version of the robot and Dan worked on the docking code. In the final design, the robot can hold 7 balls. We decided not to glue the top story yet since we have to attach and test the gate. Yaim had a clever idea for the design of the gate. The gate is going to be a one-way gate consisting of a series of small hollow metal tubes (~1.5" tall) attached to an axle. The tubes are free to rotate about the axle (which is connected to a servo). However, we restrict the motion of the tubes in one direction using a metal rod (attached to a servo). The servo rotates the metal rod and brings it in the other direction so that the motion of the metal tubes is restricted in the other direction. In other words, we can change the direction of the one way gate using the servo.

With this gate, it is easy (?) to ram the balls. The initial position of the gate is such that the balls can go on. When we align ourselves with the gate, we rotate the servo to change the direction of the one way gate; back up so that all the collected balls are in front of the gate and then drive forward to push the balls into the goal. We haven't yet successfully tested this. Aligning with the goal seems to be the hardest part.

Sunday, January 28

We finished the construction of the robot including the gate. However, the gate is not sturdy enough to withstand ball ramming. Especially, the hot glue is not strong enough to hold the metal pegs while ramming the ball. Often the pegs get stuck in the goal and they fall of or bring the whole gate down. We will have to come up with a better mechanism to attach the pegs to the axle (other than hot glue).

We finished zip-tieing our computer to the main chassis and rebooted the computer, but it refused to start up. We connected a monitor and saw the ominous message -"Kernel panic: Can't read block ..." (or something similar). Most probably, we fried the hard drive. Dan went home to bring his USB hard disk but could not bring it for some reason. Spann gave us the working harddrive (of team 15); we took apart the computer, the fan, and put the new hard drive in. This took at least 3-4 valuable coding/testing hours. Lesson: keep your hardware ready well ahead of time so that you can focus solely on coding/testing and do not have to worry about last-minute (well, not exactly last minute, but almost) hardware failures.

Monday, January 29

Today Anand worked on the wandering code, Yaim worked on the gate and other mechanical aspects of the robot and Dan wrote code to determine the angle between the robot and the goal. We noticed that whenever the robot lost track of a gap, it would spin in circles till it found a ball or a gap. Since losing gap was quite common, it would spend a lot of time spinning around. Also, if the robot bumped against a wall and chose the wrong direction to spin, it would travel back on the same path.

To counter this, we added a new behavior to find gaps. When the robot loses sight of the gap it is following, it spins in a random direction for 600ms; then it spins in the opposite direction for 1200ms and so on. This way, it (often) finds the nearest gap and does not spin by 180' and come back to the same spot.

Dan decided to use the lower yellow line of the goal (the boundary between the carpet and the goal) to find the angle since the upper line was not always visible.

Tuesday, January 30

Today was the last mock contest day. We did not have our docking code and gate working yet so we were going to test mainly the navigation code in a big playing field. The major problem we noticed during the contest was that our robot would get stuck at isolated walls (with a cylinder at the end) in the playing field. Although it did not spend a lot of time in corners, the cylinders were a big problem.

After we nudged the robot a bit when it got stuck at the cylinder, it went on to pick up five balls. We decided to add two long range IR sensors so that the robot could steer itself away from walls and not go dangerously close to them.

We came back to the lab and made two long range IR sensors. Now our robot has 5 IR sensors - one in front (short range), two short range (left and right), two long range (left and right). We modified the gap finding code to add an IR correction to the steering direction. Now the robot adjusts the speeds of the wheels by c*(L-R)/(L+R) where L and R are distances from left and right walls respectively and c is a constant. It worked very well. Now our robot smoothly steers away from walls and finds its way to different areas of the playing field.

Wednesday, January 31

Dan had to work on his 6.370 robot till 6 PM today so Yaim and I decided to work on finalizing the gate. To overcome the hot-glue-breaking problem we decided to use strong threads and beads/clamps to attach the hollow metal pegs to the axle. We spent the afternoon cutting the right sized metal pegs in the Edgerton shop, making an axle that fits the servo mount and assembling the gate. We also had to use some epoxy to prevent the pegs from moving laterally (along the axle).

We spent the rest of the night tweaking our navigation code and working on the docking code. We changed the constant c in our IR correction by sqrt(1/(1+f)) where f is the distance from the wall in front. This way the robot would turn sharply if it is about to bump into a wall. Although we did not notice any considerable improvement in navigation, we kept the change since it seemed to be a good idea.

We had some docking code ready by early morning (3-4 AM). However, the robot would pick up random yellow pixels or would think that a faraway goal was nearby and dump all the balls in the middle of the field. Having to deal with this problem at 5 AM was frustrating and we decided to get some sleep and resume working at noon.

Thursday, February 1

We started working at noon. The first thing to do was to get the docking code working. Dan quickly fixed the problem of the false positives of goals so the robot stopped dumping balls in the middle of the field. However, we still had difficulty aligning the robot with the goal. With what we had, the robot could push 70-80% of the balls it had into the goal, keeping the rest in the porch.

Since the impounding deadline was approaching fast, we decided to stop coding and spend the rest of the time (which was not much) testing the robot. However, since our docking code was not quite satisfactory, we felt compelled to try something new and Yaim wrote a piece of code to improve aligning. In the few tests that we did with the new aligning code, we thought that the robot had improved its ability to align but had run into other problems like ramming the balls multiple times (almost getting into a ramming loop), which we thought was not worth the advantage of better alignment. Finally, after a lot of thought, we decided to keep the old, slightly better tested code and proceeded to impound.

Friday, February 2