Team Three/Journal
From Maslab 2006
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15 |
| Team Three's Journal · Paper |
January 9, 2006
HELLO WORLD! Eden and our Orcpad have successfully greeted the world. First, the OrcPad was assembled and soldered, the LCD attached, and the OrcBoard and OrcPad attached. After connecting the OrcPad, the OrcBoard, and Eden, while programming hello world, helpful commands to compiling and running the java code to display on the Orc pad were:
compile: javac -cp /usr/share/java/maslab.jar:. helloORC.java
run: java -cp /usr/share/java/maslab.jar:. helloORC
and copying from afs to the bot: cp /afs/athena.mit.edu/user/h/z/hzhou/Public/MASLAB/helloORC.java /home/maslab/
January 10, 2006
Today, we got the pegbot moving and chasing Steve. After calibrating the IR sensor, the bot would stop around 6 inches from an obstacle and then stop and turn counterclockwise. In addition, we got an svn repository setup and ran the BotClient and camera for the first time. We're still experimenting with the robot today, but it's getting exciting...
January 11, 2006
Checkpoint 1 was successfully accomplished! Our robot can now identify the color red and will turn and stop when a red ball is in view. One problem that we had was that there was a delay between when the robot turned passed the red ball and when it would stop. Due to this delay, sometimes the bot stopped too late and the next frame would no longer contain the red ball so that the robot would then continue turning, in search of red. We weren't sure if this was due to slow processing of the image buffer, but that didn't seem to be the case. However, we were given advice to lower the resolution of the camera which would increase processing speed.
January 12, 2006
We had our first fight with light today. When attempting to read barcodes, it became troublesome finding the appropriate thresholds for green and black values in order to distinguish between the two colors on the barcode. When the barcode was under an overhead light, the values for each color were much higher, making it difficult to distinguish between green and black. However, in this case while we were testing, the barcode was slightly tilted upward (due to human error) which made the lighting issue even worse. In the end, we finally got the appropriate thresholds and tested with multiple barcodes on the playing field. And our robot finally read barcodes! But CALIBRATION before each test run is crucial!!!
January 13, 2006
Checkpoint 2 COMPLETE! Although our wandering algorithm is a bit...inefficient, once we get more sensors and a better idea of what our strategy is, our wandering will greatly improve. We are starting to get a better idea of what we would like our bot to do. And in addition to building on the software, we started building our real robot today! Yay for tools! We have already suffered a few minor cuts, but the robot is evolving nicely. Today we built the hamburger-like part of the robot.
January 14-16, 2006
LONG WEEKEND!! Doris enjoyed NYC, Jeff and Steve relaxed in Boston. The robot enjoyed a few days of peace and quiet.
January 17, 2006
We had a nice long weekend, but today was back to fighting with tools. We continued building upon our robot that we started on last Friday. The structure is mainly complete now. We need to replace some of the mounting tape with screws and bolts and the ball gate needs a few finishing touches, but it is almost done!! We didn't get to work on too much code today, but hopefully tomorrow, we will be able to refine our strategy and our code a bit more.
January 18, 2006
Today was a tweaking day. We set our wheels straighter but they may still be misaligned since the robot has difficulty driving straight. However, our robot does not rely heavily on driving perfectly straight now, and the focus was more on driving toward features and driving along the wall. So mainly today, we ended up tweaking constants in our sensor-to-motor feedback loop and adding the D to the P in our feedback. In addition, our wall following sorta works, although the bot tends to overshoot when adjusting the motors to follow the wall if the bot starts moving away. More tweaking is in store, but at least now, the construction of the robot is mainly complete, minus a few bump sensors.
January 19, 2006
Today was a tweaking day, just like yesterday. We improved our wall following algorithm to use a proportional control feedback loop. We wired up and wrote code to control our servo, which controls the ball gate. After luckily finding some free food on our way to 26-100 we continued to the arena to test our robot. We were surprised at how large the arena was and how infrequent encounters with goals were. After a journey back to lab to get some help fixing our wireless (thanks Dheera) thing, we came back to the arena and made our robot drive around and follow the walls. Much to our surprise,it kinda did what we thought it would.
January 20, 2006
Today our hard drive crashed. Right before it died it did this weird thing where it didn't update some of our .class files when we re-compiled, so when we were running code it would run old versions. It was quite confusing. We spent the rest of the day repairing stuff and restoring what we had before. Luckily, we had just updated our repository at the end of the day yesterday, so code loss was kept to a minimum. We tried a new continuous 360 turn mechanism, but we kept passing the ball so we reverted to the old turn mechanism. All in all, we ended up with not too much more than we had yesterday.
January 21-22, 2006
Weekend = rest for Jeff/Steve/Doris = recharge for bot
January 23, 2006
Back to the grind! Our wall following improved a bit today, but our yellow goal alignment needs a little work. We attempted adjusting slew rates today for our motors to rid of delays when our motor speeds changed. However, we couldn't find the anything in the current APIs about motor slew, so we tried using the setAcceleration() function in the motor class. It didn't really seem to do anything noticeable though...we'll keep working on it.
January 24, 2006
We wrote some code for what we thought would be a temporary solution to the "fundamental goal alignment problem". In doing this, we discovered that if we combined this solution with our previous PD controller for driving to an object, we can reliably deposit balls into a goal. Specifically, we simply use the "old" procedure to drive to the goal until it is a certain height in the visual field. At this point we switch to the new controller to push the balls towards the center of the goal. It still has trouble when it approaches the goal from extreme angles, but works for most angles. We made the robot start from the orcPad, put on a 5 minute timer, and got our firmware updated...in preparation for mock contest 1.
January 25, 2006
Today was a tweaking day. We realized a minor bug in the PD control for driving to balls. This was fixed and now it goes much straighter. Also, we decided to turn off the controls when the robot is close to the ball and just drive forward for a bit, as the controller seemed to be a bit unstable as the robot gets close to the ball. We strengthened the ball gate (temporary fix)...we can't accidentally consume balls anymore, but we don't accidently release them either. We also tweaked the ball release mechanism. Now we align wit the goal, release the balls, back up, drop the gate, and drive forward again, pushing the balls through the goal with the gate. In preparation for mock contest 1, we stopped the robot from attacking balls already in the goal, by only going for balls that are lower in the image than the bottom of the goal. This seems to be a good way to do it, as long as we back out of the goal enough after scoring that we can see both the ball and at least one of the goal edges in the image.
Timeouts were added to all motor functions that loop until they acheive a certain goal. This way, if they are still running after a certain amount of time (way longer than they need to complete) we break them and call a default timeout function. This way, if the robot gets stuck and stops moving at least we can have hope that the rest of the exhibition will not be quite so boring. If stuck, the robot attempts to wiggle free, back up, turn and try going somewhere else.
REMINDER TO OURSELVES: Right wall of ball container under robot is unglued. We must fix. Also, tomorrow is cleanup day.
January 26, 2006
Our performance at mock contest was sub-par. However, there were some good things that happened: (1) robot successfully timed-out after getting stuck on a cylindrical post while trying to go to a ball, did its wiggle maneuver and freed itself (2) robot did its wall following routine without getting stuck (3) robot reliably picked up red balls (4) robot almost put a ball in the goal...but alignment was slightly off and it kept driving the ball at the goal post. Although we didn't manage to put a ball in a goal, the run at the mock contest was somewhat encouraging in that we found balls and a goal and made an effort to put the ball in. The alignment procedure and "goal vision" need some re-working, and we're going to want to speed things up. More importantly, however, we have the first picture of our robot:
January 27, 2006
We had a little more hardware trouble today, but we still managed to solve the problem we were having at the mock contest where the robot would keep driving the ball into the goal-post, just barely missing the goal. Our error was in the goal-adjustment procedure we made. Before, we would drive to the goal, align, and then call a procedure that drives the robot straight at the goal until it times out. This correctly aligned, but had trouble actually pushing the balls all the way through the goal. We modified this strategy to include driving close to a goal, aligning, releasing the balls, backing up, and driving forward again to push the balls into the goal with the gate. The problem was that we never wrote a procedure to back up straight. Consequently the robot would back up crooked (always slightly to the left), and so we always ended up pushing the balls slightly to the right. With the new "back up straight" procedure (which uses the gyro), the robot scored on 4/5 attempts.
We spent the rest of the day trying to speed up the ball finding and scoring process by making continuous turns, thus avaoiding stopping to take pictures. Every time we have tried to do this in the past we have experienced delays which made it impossible to find a ball and drive to it. Images are blurry when spinning, and by the time the stop command is sent to the motors the robot has lost the ball. We tried some new ideas, but basically we still had the same problem. Perhaps continuous rotation is not in the cards for us, but we can still work on cutting down the stopping time and making the rotations as quick as possible.
LEFT TO DO: bump sensors, figure out what to do if we lose a wall during wall following (which occurs sometimes when making sharp turns to navigate around protruding walls), cut time off of rotation/object search, TEAM & ROBOT NAME
January 28-29, 2006
Weekend = rest for Jeff/Steve/Doris. Robot and team name are agreed upon: Robot name: The Hamburglar Team name: McJeevis (a combination of our names, plus a themed prefix)
January 30, 2006
Mock contest 2 was today. Due to a recent addition to the wall following procedure we had trouble getting out of the tough starting position. On the second run through with the easier starting position we got a ball and scored. The scoring procedure looks good now, but is still a little slow. After the contest we changed our ball search procedure to spin continuously and spin back the other discretely if it encounters a ball on the continuous turn. This wastes much less time and seems to be reliable. Also, we are now taking several images during wall following. If we encounter a ball or goal during the wall follow we call the rotate behavior immediately, instead of searching for balls only after the robot has been wall following for a set amount of time (with the faster rotation procedure, this is actually worth doing). Before the final contest, we need to improve the wall following procedure so that the robot sticks closer to the wall, and we may want to increase our image processing speed by searching through a subset of pixels as opposed to the whole image. We are almost ready!
January 31, 2006
Good news and bad news. First thing today, we stumbled upon the best combination of constants yet for our feedback control loop in wall following. So we took a break from our tweaking to finally add bump sensors. After much soldering and clicking, the sensors seemed to be working. They were mounted on the bot, but when the robot started wandering, the sensors didn't seem to be responsive. Apparently...pull-up resistors are key. So we made some progress today and figured out what we still need to do.
February 1, 2006
Huzzah! Robot is done! We still have a lot of testing to do, but for the most part, no major changes should be made to it. Bump sensors were added today...successfully, along with an additional IR sensor along the ball gate to sense if we actually got the ball. The additional sensors make our robot a thousand times more robust! Our robot may look a little asymmetrical now with almost all its sensors and actuators piled on the right side of the bot, but it has character :).
February 2, 2006
We are DONE (for real this time). We just ran our robot a couple times this morning, and everything seems to be working as planned. Hopefully things will go well tomorrow. Our one major worry is the lighting conditions on the contest day. We have written code that allows us to easily tell if the robot can see the colors correctly, so that we can calibrate tomorrow before the contest. It's been fun.
February 3, 2006
The contest went pretty well. We scored 1 goal and got 2 possession points. We got stuck on the course a lot more than we thought we would, but the bump sensors that we added a few days ago helped a lot in these situations. Also we realized that our timeout function was key (basically if a motor function does not complete successfully in a certain amount of time it gives up and the robot tries to "break free"). The goal alignment was slow but reliable (as advertised). Unfortunately, if we had had a few more seconds we could have scored 2 more balls in a new goal, but time ran out just as the robot was approaching the second goal. We were lucky that balls were visible from the central island, or we could have gotten stuck going around in circles (as pointed out yesterday by the staff). Also, many thanks to our cheerleader/mother Betty who took many pictures at the contest.
