Team Thirteen/Journal
From Maslab 2006
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15 |
| Team Thirteen's Journal · Paper |
Contents |
January 9, 2006
Today was the first day. Given the fact that none of us wanted to do too much preperation before the contest, it's a great time to "leap" into what we are doing. The constructions went fairly smoothly. I don't particularily like how are wheels are constructed, but I think it is definitely something we can repair.
We finished the construction and created the Hello World program and left to lunch. Upon returning we did a bunch of other stuff (gathered pictures, put a lot of stuff together, got the motors to work) without realizing they wanted to check us off for having done the Hello World. We didn't think to show them the program, since in the wiki they had "gyros" as listed as one of the activities.
The day culminated with a fantastic display of creativity: a cow logo printed in the LCD on the orcboard. This took serious effort, and yelling at Java. I think we're gonna go ahead and use Jython for a lot of it, so this will be a very interesting program.
We also talked about ball carrying technique especially over lunch. Alex offhandedly suggested that we shoot the balls into the goals. While we laughed, Mike said that it would be fun, so we might as well do it (we're in this to have fun, right?). Although with robotics odometry, you can correct for mistakes in your earlier information gathering, something that "shooting" a ball cannot do. We can of course comprimise: bring the robot to some place where the level of accuracy can be above some minimum, whereby we can shoot it.
Also, there is the discussion of the shooting technique. We can store the energy in springs, air pump, or (my favorite) a CO2 cartridge.
January 10, 2006
Day 2 was much more interesting. After making sure everything fit on the robot (without the OrcBoard), we mounted two sensors (the gyro and the short-range IR sensor) and started reading data. After a couple hours we got the robot to oscillate between moving towards the wall, reversing, and moving towards the wall again. It was mesmorizing. Not much hardware progress was made after that. But we have managed to work a bit on the software, discussing various image techniques. Tomorrow first thing we're going to mount the OrcBoard so tat we don't have to worry about that.
January 11, 2006
A lot got done today. Perhaps it was because we stayed in lab until 11 pm; we shall never know. In the first part of the day, while Alex and Eric worked mostly on the software, Jason and Mike worked on the hardware.
As far as hardware is concerned, we added a long-range sensor in a cool location (so as to not be interrupted by goals and balls), and we upgraded our wires so as to have a higher quality (heat-shrink tubing is your friend) and generally made it much nicer. We got an encoder kit and intended on using it, but realized we should stop when we realized it wouldn't fit on the wheels. We might have made them fit anyway, but we decided it would have been better to wait. Although we did start assembling the surface-mount components onto the boards we got.
The software made a lot of strides today. First Alex and Eric worked on the central image processing code. We got the blob detection to work by basically floodfilling on each pixel. The blob detection reports the number of objects, the types of objects they are (based on color only right now), the com coordinate, the area, and a few other things. The blob detection takes as an input a map of the image, which identifies each pixel as being one of the canonical types (i.e. BALL, WALL, BLUE TAPE, etc). After tweaking the objects a bit we decided to write some code that might actually use this to pass checkpoint one. After a few tweaks we got it to work (the seesBall() function took WAY too long initially, and rotating surely overpassed it (if it ever got the picture with the ball in it at all)). Then we were ambitious, and decided to write checkpoint two code.
At this point, we realized that we could get some cool random walk code done, which we did. What was more important, however, was zeroing in on a ball and ramming it once we did find one. After a LOT of tweaking, we finally got something that did it. We did not want the bot to get stuck, so we looked into current sensing. After realizing how it worked, we realized the actual values of the current was not interesting---the values over a .5 second time was. For this reason, we realize that threading is imperative. We have discussed what our actual code should look like---threading all the sensor classes so that each sensor can be read but also heavily tweaked with moving averages so that we can get rid of a bunch of noise. In addition, threading would be able to let us do things like "seize" the robot's control if it's stuck, and put it back on course.
Axiak 03:36, 12 January 2006 (EST) As an additional addendum, just updated our code organization description. Should have an image up later on. Sleep now.
January 12, 2006
We tweaked some code, fixed some bugs, and (barely) started porting old code to the new plan. Mike improved the motor current stuckness sensor to use thresholds for various motor inputs, and Alex wrote a bar code reader. We passed checkpointtwo and the day four objective. We discovered BotClient's ability to publish images, which is very useful. We really want to add quadphase encoders, but they weren't ready yet.
A reminder: when the lighting changes, remove and reattach the camera to recalibrate, or the bot won't recognize anything.
We left in the afternoon, ready for a weekend off doing the Mystery Hunt.
January 13, 2006
Mystery Hunt was going well. Although we were puzzle solving we were still thinking about maslab...
January 16, 2006
We tried to lay low and try to avoid the lab today, after spending a very long time in lab last week. Basically, we spent more time designing the code, and we finally started writing the real code in the form we will actually use it in. Another great breakthrough, we finally agreed on a physical design for the robot, utilizing all 30 sensor points. The design is based on a hexagon with several (i.e. three) teirs of board for holding stuff. More technical speicfications will be ready for Wednesday.
January 17, 2006
So today we really needed to build the robot. Starting into the day Jason and Mike really went over design, and started putting stuff together. Finally at 11:30pm we got the ball holding pen fairly well implemented. We decided against having our spinning throwers of doom implemented until after mock contest zero, lest we will make an error that cannot be undone in our haste. The software is really evolving into what looks like a good product. Eric made some image processing optimization (e.g. totally avoided HSV conversion) to improve the rate of image processing more than ten fold, while still producing the same results. Should really help out in the long run! Our blob detection still works as-is and is general enough that it hasn't needed to be updated despite more and more tasks (i.e. goal detection, ball detection...), they are all under the "blob" detection catagory. For our mapping, we really like the spring relaxation design. It should not be too much computation, and it's an exact method for things that are pretty close. Again, we really like it. Anyway, fun stuff to ensue. As for the design slides, we have them available here.
January 18, 2006
Alex worked on image tracking, so we can identify the same object in successive frames. Eric worked on wandering code, letting the bot follow walls with the IR sensors. Jason and Mike finished most of the construction for the bot, except for the rollers. We discovered that a foam channel to collect the balls works poorly, and balls can get stuck in the holding pen. Also, it would be nice to use long IR sensors mounted at the back of the robot, so the bad range (6-8 inches or so) is absorbed in crossing the bot.
January 19, 2006
Today was a mess. Eric and Mike forgot to set/slept through their alarms, and Jason and Alex didn't see each other in the confusion over whether to go to 26-100 or the lab. A few hours later, Eric and Alex discovered that the images can blur pretty badly when the robot spins. Alex worked on deconvolution, but found it not as useful as he had hoped. We also needed to raise the front casters so they never normally touch the ground, even if it is bumpy. Mike finally showed up just in time to go to the ITA dinner.
January 20, 2006
Mike and Jason left for home at 3:00, but before then Jason helped add quadphase encoders to the bot. Alex worked on identifying tick marks in images, while Eric worked on getting the quadphase encoders working-- one of the encoders was poorly soldered, and then some ports seemed to randomly add 2**14 to the value of the counter.
January 21, 2006
Alex and Eric slept in then worked on mapping, not very productively. Mike and Jason were in Connecticut.
January 24, 2006
After Jason and Mike came back from Connecticut, we realized we needed a better robot. Mike worked through the night in Random Hall to build a nicer robot. The hardware design has changed to a canonical circular robot with inset wheels. Hopefully the new setup will fix any serious issues with the quad encoders. The gyro works better with the updates, so it will be very useful to have. The hardware of the robot is almost done...leaving just about only the rail to add for the ball collection. The mapping has been worked on; when the actual robot is available for testing a lot of the code can finally be tested more thoroughly.
January 25, 2006
After working on the robot, a lot of the hardware bugs have been worked out...but still many remain. The preparations for mock contest 1 are on their way...we're mostly concentrating on getting mapping to work and have not spent much time at all working on getting mock contest 1 to work. We'll see what happens.
January 31, 2006
Eric and worked on wall-following more. Alex tweeked barcode scaning. One quad-phase encoder is broken, and needs to be fixed. Added nifty display function for BotClient for spectators.
