Team Six/Journal
From Maslab 2006
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15 |
| Team Six's Journal · Paper |
January 28 & 29th, 2006
Lots of hardware over the weekend. Spend all day in machine shop. Now, every member of our team has used a lathe (some of us more than we'd probably liked!). The hardware is nifty, but we decide not to push it for mock contest, and instead used current hardware.
We need to implement mapping, but since odom data remains worthless for now, mapping will have to wait until monday, with new firmware???
January 27th, 2006
?
January 26th, 2006
Mock contest teaches us about getting stuck. Current sensing sounds good, as does a "stuck timer" that initiates evasive action when things aren't changing.
Work is done to return bar-code reading to functionality. Possibly successful. A visibility-graph mapping scheme is discussed, soon to be implemented? PID controlled is created, but encoders need to be less spazztastic (though here the problem is likely our inaccurate encoder wheels / IR assembly alignment, not orcboard firmware). New, better encoder wheels mounted soon?
January 25th, 2006
Something happened, but I don't remember what...
January 24th, 2006
In preparation for mock contest 1, we halt work on unnecessary things like maintaining odometry data and focus on ball capture/scoring. We achieve checkpoint 3-esque behavior with our new vision code. Hooray. Ball captured and taken to goal. Despite the fact that better mechanical parts are being made, we bolt together the plywood robot and assemble a makeshift ball capturing device to facilitate testing. Everything could stand to be better, but hey, isn't that just the way life is?
Anyone figurede out whats going on with the encoder reading spikes yet?
January 23rd, 2006
We work on encoders, and ALMOST get them working. We work on speeding up the vision processing, and meet with mild success (though it could still stand improvement). Ilan makes spiffy parts. MechE types are useful. We realize that Mock Contest 1 is on Thursday, and our robot is not assembled. Whoops.
The first mock contest
May our team's blood please not spill
We'd prefer it dripped
January 22nd, 2006
The weekend of rest drifts into the past as the lathes spin into the night. New wheel mounts are fabricated to mount new wheels. Nice CAD models are drawn for motor mounts, components of the Ball Gobbler, and a more accurate base plate. Behind the excitement of mechanical components, ideas form to answer the ever-present questions "where am I, and where am I going?..."
January 19th, 2006
We explore new vision algoriths for ball finding... we want more fps. An RGB look-up table is explored, since they seem to be in vogue at the moment. Code created to zero in on nearest ball. We play with gyro to see what type of accuracy we can expect. Not bad, but there's room for improvement. It would be nice if orc api explained the difference between gyro.calibrate(n) and gyro.startCalibration(n), and why the former seems to decrease accuracy, compared to no calibration.
January 18th, 2006
Lots of good code is written. Due to lack of orcboard, not much testing of code occurred, and so some more debugging of ball-finding algorithm is needed.
The orcboard returns to use after the 5v regulator is replaced. The second optical encoder comes alive after replacing a dead IR LED.
January 17th, 2006
Chassis is nearly built! Also, we have quad phase encoders! Subversion is working out well, and the code is in the process of being totally overhauled so as to be readable/usable/modular. The design review slides are finished. Unfortunately, the OrcBoard may have been damaged slightly. More investigation is needed.
January 16th, 2006
Holidays are for the weak. We amass materials for a ball collector. An enormous motor is gleefully considered, but a lower-velocity system wins out... for now. Prototyping will commence on the morrow.
Today, pegbot succumbs to obsolescence; a circular base is fabricated from plywood. We hope this will make our robot less susceptible to getting stuck on obstacles/corners. Further work mounting sbc, sensors, etc. to new chassis will wait until lab reopens tomorrow.
An svn repository is set up. This makes our robot sleep more easily at night.
January 13th, 2006
We work on checkpoint two. Again, the code is odd and strange, but after some calibration and much trial and error, we succeed in getting Spazzbot to chase down a ball. Our wall following mechanism "mostly works," but when it loses a wall it falls back to the "find a new wall" mode, so we should fix this. Also, we come up with a better design that doesn't involve an arm and 40 sensor points.
I would write haiku
But I have not yet eaten
So let's all go now.
January 12th, 2006
Pegbot is becoming insufficient for our work; plans for a new chassis are discussed. Construction must begin soon of chassis and ball capture mechanism. We make quick mock-ups of potential strategies. Grabber appendage and holding queue seems the favorite... can we implement it reliably without too many sensors/actuators?
Code writing for barcode detection is somewhat painful. We spend much time debating code. Barcoding gets incorporated into blue-line search. It works well on first try (cue enthusiasm, disbelief). Future refinements will average readings to filter errors, refine mechanisms of choosing pixels to test. Overall, initial barcode detection is better than anticipated. Here is a haiku about it.
Bar Code: .....coding.was.painful.......and.yet.it.all.compiled.......it.saw.the.bar.codes....
January 11th, 2006
We work on some simple vision algorithm material, whcih will probably be heavily revised by the time we have the final robot. We implement some nice noise filtering which blacks out anything above the top of the playing field, so that our bot, which is supposed to be able to see a red ball for Checkpoint One, doesn't see, say, the red lab benches and think they're balls. We make it so that if the ball is in the bot's field of vision, but not in the center, it will center itself - if it is looking at the ball and the ball is moved a few inches over, it will turn a few inches accordingly. The bot tends to oscillate when looking at a ball, so we nickname it SpazBot.
January 10th, 2006
We napkin-design our final robot. We finish building the pegbot. We hook up an IR sensor. We write software to have pegbot drive forward and stop six inches from an object. IR sensors are kind of touchy. Then, we add the camera and do some basic software to display the images on BotClient. Then, we create some code to do the Image Tutorial's red ball processing on those images and then display both the original image and the processed one in BotClient.
January 9th, 2006
We decide on our team name, All Circuits Groovy, which beats out The Hawaii State Intermediate Court of Appeals and The Kings of All Cosmos. We solder our OrcPad and hook up the OrcBoard to the Eden. We create a Goodbye Cruel World program. We build pegbot. We get the motors working, and test out the joystick and controlling them via the API. It's kind of annoying that the "reverse" bit in the Motor constructor doesn't do anything. We think really seriously about getting the digital sensors working, but don't do it because we're hungry.
