Team One/Journal

From Maslab 2007

Total Statistics

• Total Drill Bits Broken: 2

• Machining Blades Broken: 2

• Plastic Motor Plug Tabs Broken: 3

• Four Amp Fuses Blown: 1

• Computer BIOS crashes: 1

• Burned out 74LS194 Chips: 5

• Cooling Fans: 2

• Orcboard Fires: 2

• Total Rivets Used: 25

• Number of Bump Sensors: 12

• Speed 0-60 (degrees): 0.52 seconds

Pre IAP

Thanksgiving 2006

So we officially started looking at potential designs during Thanksgiving 2006. Ellen (Yi) and Chris decided to do maslab during IAP of 2006 after watching the contest and Kim joined very shortly after. All members then proceeded to take 2.007 and built crazy robots. Chris managed to get to the top 16 in the competition and was only hindered by low motor power.

For Thanksgiving break, many sketches and research projects where done including deciding to use Omni-wheels. That weekend, we were able to build a cardboard model of our robot by making cardboard brackets for the omniwheels. We began solid modeling the robot's components, researching sensors, and working on writing code.

(1) Early Solidmodeling of basic shape. (2) A single slice of a more detailed solidmodel that analyzes the bin's design. (3) A picture of the robot on 1/19/07.

Christmas Break 2006

During Christmas break, we worked on making large decisions about or robot in terms of software architecture , sensors, and mechanical design. Each person did a powerpoint to show the others what they had researched. Below are the powerpoints.

FIGURE OUT HOW TO ATTACH THESE FILES

Mechanical Design Powerpoint

Advanced Sensor Selection Powerpoint

Software Strategy Powerpoint

Week 1

Day 1: Jan. 8th

Soldered Orcboard and assembled pegbot. This included the soldering of surface mount parts with the help of our own soldering gun, tweasers, and wire cutters. We then wrote "Hello World" onto the orcpad with some tweaking with the Linux interface. Afterwards, we were able to write a simple robot program that turned on the motors to allow the robot to drive at different speeds.

The first mechanical version of the robot was a pegbot with two motors. There was a lack of the correct sized nuts and bolts which made it difficult to attach the caster wheel but we finally found the correct parts and sufficient tools at the Edgerton Shop. The rest of the night was spent working on designs and solid models.

It would have been much more helpful to have a link from the Wiki to the UNIX commands or have tutorial code to accomplish all the tasks of the day instead of bothering the TAs all day ^_^.

• Dinner: Royal East Chinese

Day 2: Jan. 9th

This morning, we were able to go to the Hobby Shop and work on cutting a few of our parts. This year, there is training availble for the Edgerton J Shop (lasted 1-1.5 hours) directly through Maslab which is a really good idea for future years.

Today we worked on soldering the sensors, trying algorithms, and working with displaying the output of the camera on the BotClient. In order to work with the Omni-wheels, we wanted to try out different motors. The other motor we tried had a higher torque but a much lower speed which would not serve our purposes as well in this competition. A suggestion for future years may be to get motors that have a voltage rating that is more similar to the voltage rating on the orc board (motor currently rated at 19.1V while the power supply is more like 12V).

We also installed a long range IR sensor and are beginning to install the ultrasound and the bump sensors and gyroscope. Our camera can currently identify when it sees the colors red and yellow.

• Dinner: Sandwiches from LaVerdes

Day 3: Jan. 10th

This afternoon, Kim and Ellen began working more extensively on wheel and motor mounts as well as cutting out the bases. Ellen managed to bend a 5/16th drill bit in a drill press while launching a vise 15 feet through the air without hurting the part she was cutting. Hmmmm

By that night, we had an omni-wheel robot running although we could not get all the motors to run at the right speed or torques. Even though two motors are from the same supplier, they may not have the same speed or torque!!! We will have to change out our motors tomorrow. No more pegbot! (we hope....).

Today we've gone from rough code in a single file to a complex architecture with multiple threads and a stack FSM!!! Way to go Chris! Since we have found the sensors and camera to be horribly unreliable, we've also wrapped all the sensors in our own sensor classes which contain a "memory" of past data results to further increase reliability. We've also gotten some PID code written as well to add to our functionality. The checkpoint for tomorrow is a robot which can turn, see a red ball, drive towards it and stop infront of the robot. We can technically accomplish all of these tasks if we could give 2 of our motors just a little more torque on the carpet.

The software lecture today was really good. It went into just enough detail to be interesting and informative, and had plenty of great and engaging examples.

Waiting for awful batteries to recharge so we can test out our checkpoint 1 code (warning: partially written by the Mech E's) .... and OMG its 4:30am (scratch that, 6:00am now...).

• Dinner: Ankara Cafe

• Total Drill Bits Broken: 1

Day 4: Jan. 11th

Checkpoint 1 today.... The file we turned in for Checkpoint 1 is availble: here

5pm: Currently charging the battery. We changed out two of our gimpy motors for higher torque monsters. Once we have power, we can finally test out the robot's ability to drive around with real motors and under full power (we've had limited success with a near-dead battery and two wimpy motors). The Mech E's have left to scavenge parts to begin prototyping the collection mechanism, while I add debugging and calibrating tools to the code and procrastinate by updating the wiki. Hopefully we will finish the day with a fully mobile omniwheel bot that can chase down red balls and be on the way to finishing the collecting mechanism!

9pm: So we finally got a new battery and have been testing our code. Apparently, we can see balls but there was a small bug in the code so that when we do see the ball, we turn to avoid it!! After about an hour of searching and debugging, we found that we had a greater-than rather than a less-than sign somewhere so that when we saw a ball, we were telling the arbiter that we were not seeing a ball and vice versa. After we fixed the small errors, we where then able to drive up to a ball and adjust our path to hone in on it! Technically, we scored one point when we captured one ball today.

So we need to make a few fixes on making the image processing code a bit faster as well as adding PID or some faster method for honing in on balls. Also, we tend to lose sight of our balls when we get really close to them so we need to account for that too.

Mechanically, we have the funnel part of the bin finished and we will be finishing our bin tommorrow. We will also be attaching it to the base and building the rollers. Bins are sheetmetal parts that tend to take a little more time and thought than other parts ^_^.

• Dinner: Tailand Cafe

• Total Drill Bits Broken: 1

Friday, Day 5: Jan 12th

Added in PID Controller code for centering on objects and moving forward to gobble up balls. And by PID I mean P....

Also added in a prototype bin and collection mechanism.

Further tuned thresholds in the image code to better see balls and blue lines at a distance.

Also splitted up the FSM_Controller thread into two threads: An Arbiter and an Executor (so now I can update the State on the fly). Unfortunately, this involved attempting to circumvent deprecated and bad Java code. I hope saying "Executor = null; Executor = new ExecutorThread(); Executor.start()" does what I hope. Bueller? Anyone, Bueller?

In one fell swoop, Chris obliterated an entire afternoon's amount of work on the prototype roller when, on the first test run, he set the rollerMotor to "1", ie, the maximum setting. Clearly the rigging couldn't handle the power. "What happened?" He asked. "YOu TORE it ApARrT!"

• Dinner: Wing It

• Total Drill Bits Broken: 2

• Total Rivets Used:14

Saturday, Day 6: Jan 13th

Finally figured out how to use BotClient to talk to the robot. SCORE! Now we don't have to change code and recompile nonstop....

Also resoldered the gyro and tried it out. No gyro_factor needed? Heck yah!

On a slightly more depressing note, we found out our frame rate is ~5FPS. The image code itself can run at 11FPS, which means half our execution time is spent image processing and the other half is doing Everything Else. I think. Is my math right? Either way, it's time to go back in and make the code faster. And by faster I mean harder to read. Grrr. Also should note that the camera is set at 10FPS, so that's the goal to hit.

After adding in PID code for rotating to a fixed angle (using the gyro) we found out our robot turns just like Zoolander (apparently our kI is too big and in the wrong direction). update: now it goes 0-60 (degrees) in .52 seconds.

• Dinner: Pizza

Sunday, Day 7: Jan 14th

Did some coding of object finding, PID, and calibrating sensors. We also finished the brakets for the bump sensors and ordered parts online from MacMaster .

• Dinner: Dominos Pizza

Week 2

Monday, Day 8: Jan 15th

Continued to work. More work with the bump sensors, finished painting the wheels. Wrote and calibrated the torque/current curves for the motors in an attempt to tell if we hit a wall based on the motor current.

• Dinner: Wok'n Roll Chinese

Tuesday, Day 9: Jan 16th

Yah! The machine shops are finally open. Remade motor brackets (to lower the robot), made a camera mount, and performed other mechanical remodelings. Rebuilt the robot with the new modifications and tried out the new code for finding and picking up red balls. Didn't work. The botclient decided to not output our images which made debugging impossible. Or was it a symptom of a greater problem? Hmmmm.

• Dinner: None!! We forgot to eat!

Wednesday, Day 10: Jan 17th

So we finally figured out why our camera was being strange. Apparently one of the functions on the camera thread failed but did not report an error...so we could use our camera only if we start it out looking at a red ball....we'll have to fix that one. We also tried out our bump sensor array. They are working pretty well and Chris totally screwed with the robot making it jump back and forth when the bump sensors were tapped.

Soldering the bump sensor array. 11 bump sensors soldered together to give five different bump regions.

We went to ITA today for dinner. Their presentation was pretty good and their company really seems employee-friendly. It looks like a pretty interesting place to work.

We may have a balance issue with the battery which could take a little more time to solve. We also got most of our timing belts and materials in today. MacMaster totally FAILED to give us what we ordered!! How is that possible? How hard could it be to give us the size rods that we ordered? We are probably looking at building rollers tomorrow and maybe starting on attaching the bins and control boards. Tomorrow is Checkpoint 2.

• Dinner: ITA provided Mexican Food.

Thursday, Day 11: Jan 18th

whoa! 5.0FPS on the botclient, printing out every third picture, and without dropping a single packet? What did I do?! I hope I can repeat frame rates like that in the future. Good spirits as an infinite while loop was found to be the culprit to a strange-acting camera. Like any good dog and a bone, the robot was clearly upset if it didn't see a red ball. Hmph! One bug down....

Bench-level experiment with new roller and motor/belt assembly: the higher torque motor wasn't spinning nearly as fast as we'd like, but it *did* bring in balls. However, the new timing belt demands a lot of tension so we have to design a bracket-mount for the roller and motor that can withstand and maintain a serious amount of force.

10pm: Sweet! ROFL!! The roller picks up balls and is able to hold them back! Now we just need a faster deposite mechanism because the rolling out part wasn't as awesome as we had hoped. Our PID code for turning is pretty awesome but darn if our robot can drive straight! Maybe it is the gyro drift? For the mock competition tomorrow, we can run our bump sensor code with a roller...we could totally get ball possession points.

• Dinner: Sandwiches from LaVerde's

Friday, Day 12: Jan 19th

Mock Competition day. Had trouble with wireless in 26-100. And by trouble I mean wireless didn't work. To test out our "bump-wall, wander away" code we had to go into the hallways to get wireless. The "wander" code worked just fine so we went back into 26-100 to try it on the real field. Once we got it on the field the code decided to do something different: bump a wall, move away, spin ridiculous amounts, and then head back into the wall. We had no choice but to go back to the 6.002 lab to hook up the cpu to a computer and try and debug both the wireless and the bump/wander code.

We had to take the computer completely apart in order to plug in the monitor (and to modify the box so we wouldn't have to do this in the future). We also started building mounts for the electronics and a new computer box that wouldn't be so bulky. Also got the fan working.

Decided that I hate PID code. No matter what the constants are set at, it's impossible to get it to work for all angles between 0-360 (Ellen adds evil laugh here). Works "okay" for now (with overshoot) but we will have to modify a PID controller into our own personalized controller that dyanmically changes the constants depending on the desired angle.

Added code that let's us control the robot with our "nintendo" controller. And by nintendo controller I mean the orcpad accessory. But the robot can translate and rotate (and other fancy things). My teammates claim its just for kicks but I maintain it allows us to see the capabilities and moves required to get the desired motions out of the omniwheels. Also added in the code so we can "warm up" the code before starting the robot's actually run. Very nice.

Dinner: Papa Johns Pizza

Saturday, Day 13: Jan 20th

We went over the code lecture style today so that everyone is up to speed on the code. We will be adding more significantly to the FSM from now on since the mechanical component is mostly finished.

We are contemplating a R2D2 stage for our robot with flashing lights and beeping sounds! Now that would be Freaking Awesome RAWR!!

Dinner: Grilled Chicken Sandwiches by Kim. Awesome!!!

Sunday, Day 14: Jan 21st

We finished the SSS so all we have to do is attach it tomorrow. Our computer is acting funny so we will have to take it to lab and hope that someone could help us address the problem. We also bought some LEDs today.

Dinner: Anna's and Galleria Food

Week 3

Monday, Day 15: Jan 22nd

Computer is still dead so we worked on mounting the orcboard and orcpad. We also fixed the bin and fixed down most of the SSS. Most of the afternoon was spent chasing down a computer. We got an old computer from Valerie an we tried to use it...but we didn't have a password!! So still no computer :(

The sponsor dinner was pretty fun. The sponsors had a lot of "team spirit." We wouldn't mind more dinners like that.

Dinner: Sponsor Dinner Chinese

Tuesday, Day 16: Jan 23th

We went to the Slocum lecture today and it was pretty awesome. We talked about the stuff he talked about it all day. Afterwards, we got our new computer!! It took a while to hook it up but we finally got it working!

Today we worked on making a better computer box, the front bump sensors, mounted the breadboard, rivets for bump sensors, the break beam with an IR sensor, and other electronics stuff.

We need to do more code to catch up on 3 days of downtime. Checkpoint 3 is tomorrow.

Dinner: Cheesecake Factory

Wednesday, Day 17: Jan 24th

Kim worked on the computer box today while Ellen worked on lights and Chris worked on writing code for collecting balls and navigation with the SSS. We would like to have a piece of code which allows us to wander by traveling sideways but looking forward with the camera and following the wall behind with the SSS. This should make for some interesting movement and code.

We managed to capture a ball with our rollers today exactly like planned. Then we realized that we can only use the "drive forward until you break the beam" for the first ball that we encounter and it would not work for the second or third ball. We may have to be more creative about how to approach this part of our FSM.

It looks like we've hit some sort of greek trajedy where we are slammed with tons of bad luck. So Ellen buys a frozen Coke and Kim buys a can of sprite that was only 2/3rds full (it had a hole in it). Then we run into electrical problems where the orcboard randomly started smoking when it gets plugged into the wall adapter. We think the gods of electronics have put down a curse or something.

Dinner: Happy Garden Chinese

Thursday, Day 18: Jan 25th

Electrical: Replaced orc board. Got lights and sounds working: now using for debuging. Andrew Spann (Aspann) helped us replace our orcboard. The process was interesting. When we plugged in the old orc board, it started smoking and of course there was an area on the largest chip of the entire board which started glowing orange...you think it's on fire? I'm pretty sure none of use has seen an IC literally catch on fire before. Obviously a sacrifice to the gods of electronics.

Mechanical: Installed computer in new case. Feature lockdown: all components complete. Debuging: Weight distribution issues (battery makes it harder for wheels to slip: must be compensated for by PID); flaws in bump sensors (false positives, lower than top of goal, snaging on rubberbands: requires redesign); need for stuck code (wheels catch on raised carpet)

Software: first test of wander and pickup code together; first run of complete robot. Roomba navigation code fully funcitonal (sucessfully captured 8 of 9 balls on small field in 5 mins).

Goals for tomorrow: 1)Wire maanagement 2)ufo lights 3)sss code 4)shooting code

Dinner: Sandwiches from LaVerde's

Caption: This is the robot's first full performance of wander code and picking up ball code. Not bad!

Friday, Day 19: Jan 26th

Quote from Chris: "You can only drive as fast as your gimpiest motor...We're screwed guys." Well, it seems like our robot drive better with more weight on it.

[chris explains...] Our center of mass isn't in the center of the robot which means that two wheels dig into the carpet more than the other, which.....(babble, babble).... means that our robot cannot drive straight. Excellent PID code takes care of that..... by dropping power off the good motor/wheel to keep the robot driving straight. IE my quote above. Our robot can drive faster..... if it drives in circles. A few "creative" changes to our PID code, ie, using the third/back wheel for direction corrrections (like using a rudder) while allowing the front two motors to drive full power is now allowing us to drive faster. The side effect? The robot now appears to be incredibly intoxicated (some would say very excited). If fact, while Kilroy (the Kung-Fu Drunken Master) certainly gets where he is suppose to go, the PID code makes him get there in the most, silliest, round-a-bout way possible (like a puppy).

Of course (and by of course Chris means 1-2 days of delay when there is only 7 days left), we could fix this by making the ball bin smaller and placing the battery above the third motor to balance the load on both "front" motors. But my group prefers drunken steering and "show-man-ship (also known as personality which every A. I. should have ^_^ )" over such trivial things such as "speed (of which it gains none by moving the battery)", "driving straight", and "appearing intelligent and completely sober (of course we named our robot the Drunken Master about 3 months ago)."

[Ellen] If we aren't going to use omni-wheel capabilities for compensation or for show, what other purpose do they have at this point...especially since we've not finished our wandering code that utilizes omni-wheel navigation capabilities. At any rate, we wish we could show you videos of it working! It looks pretty good and it is actually faster than some of the other robots we've seen even if it is random. ^_^

Dinner: Papa John's Pepperoni Pizza.

Saturday, Day 20: Jan 27th

8.30am. Teammates asleep on couches, but me and Kilroy are still going. All-day'ers are for wimps. finally got Kilroy to listen to the SSS (rotating IR) to decide where to go. With insane turn speeds and drunken PID control behaviors, it was "entertaining" to watch, but almost entirely unusuable. Now I will have to write code to put an end to the bi-polar drunken steering. To add to our concerns yesterday (and by yesterday I mean a few hours ago) our robot now moves pretty darn fast with the new PID control code. Of course, by fast I'm more referring to side-ways and rotating motions, but I guess if your weakness is driving straight then why bother? Actually, it can drive straight but not as fast as other robots...an obvious drawback of having an omni-wheel robot with wheels at 120 degrees. After all, none of the wheels are facing forward.

9:30am. Who needs RGB when you get 15FPS? (grumbles about hand-made color-tables....). Wishing I knew how to increase the volume thru command prompts so I could hear our R2D2 beeps from Kilroy better. Glad that our yellow code and ball shooting code works. Mostly. Not happy that our robot continues to chase balls inside goals. Despite the fact that I wrote code that supposedly accounts for that. Wishing Dunken Donuts was closer to 35-50whatever room I am in. Fooood. Mentally preparing for one of our fifty-bajillion wires to catch fire. It wouldn't be the first time. Who knew breadboards were so risky? Can't wait to attach a CPU fan to the breadboard. As in, for cooling purposes. Because that's what fans do. Because those shift-registers like to get hot. It's tough work powering all those LEDs.

11:30pm. Ellen: "You attached the accelerometer to a piece of foam with nuts and bolts?" Yes. yes she did.

Dinner: Apparently Food is for the Weak

Sunday, Day 21: Jan 28th

12:00am. In-CON-ceivable! We watch "Princess Bride" while writing accelerometer code and doing wire management. "Did I make it clear that your job is at stake?!"

1:30AM "Dogma." Re-wiring almost finished.

[sleep during afternoon, reconvene later that night]

We worked on sanding the hole for the belt drive and watched Monty Python's Quest for the Holy Grail. "T'is only a flesh wound" and of course "she turned me into a newt....well I got better."

Driving robot around and fusturated by problems. Bump sensors are spamming the robot with false positives. Thank god we just added code that shuts down disobedient sensors. ("You can never have enough safety code.") Accelerometer is in and working (thanks Analog Devices). Now we just have to write redudancy code for it that will overlap its functionality with the bump sensors and the rotating IR. Can you see how much faith we have that our robot will correctly avoid walls? On a positive note, it scores quite well (thank god for omni wheels, catchphrase, "lining up - made easy!").

Dinner: au bon pain

Week 4

Monday, Day 22: Jan 29th

4:00AM Working on more sophisticated SSS code for either wall following or for intelligent navigation. It seems that narrow doorways are a problem and so is the rate of scanning. Otherwise, the algorithms look okay. We'll keep looking at the threshholds that we set.

We worked on more SSS code and a new set of faster and better spin360 code. We also found a way to increase the sound on our computer but not by a lot.

Dinner: Kendall Foodcourt

Tuesday Day 23: Jan 30th

We did alright during the mock competition today. During our first trial we scored 15 points by scoring 3 balls and collecting 3 more. In the second round, we scored 3 balls (12 points) but spent a lot of time looking at balls in the goals. It turns out that the white balance was messing up so that the top of the yellow goal was disapearing when we got close to it.

The robot is relatively consistent even though it runs a random algorithm. We've finally added our SSS capabiliites in a minimal capacity for decision making and it looks pretty good so far. It will make relatively intelligent decisions when it is bumped in terms of turning left or right or just shifting sideways to enter gaps in the wall. More complex usage of the SSS has already been written so all we have to do it test it extensively. At this point, sharp corners and hallways are alright (the Roomba can get out of this) but large rooms with small doors still prove challenging (may need mapping or odometry to get out of this one). There are a few tricks with the SSS that we could use but we may need to spend more time testing that out.

At first, we thought our spin 360 code was going crazy but it turns out to be more of a computer problem than a mechanical or software problem. We totally need to look at this issue! And by issue, Ellen means that all of our threads simultaneously crash and the computer reboots. Without printing errors. Sounds like a hardware problem to me . . . (Staff says most likely USB issues).

Dinner: Baker Dinning

Wednesday Day 24: Jan 31st

Mentally preparing for the last 24 hours. Ellen: "This is the most hardcore six-units pass/fail class EVER." Mad testing, in particular of new navigation code.

Nav code is working "pretty well", but crashing has become even more constant. While we have a list of possible suspects, we currently blame the UFO lights around the perimeter. Which is a shame, because they're awesome in action.  :/

So there is this awesome story about waking Chris up so that we could get him to do code. First we called him and said,"Chris, Kim is eating all of your donuts!" That obviously didn't work but it got him thinking....Then we called him 20 mintues later saying "Chris, OMG, Johnny 5 (another robot) is on FIRE! Its so awsome, you have to come to lab and see it!" Well, Chris totally thought we meant that Johnny 5 was very awesome at collecting balls and naturally, it got him up. He runs into lab a few minutes later freaking out because Johnny 5 was going to be such an awesome robot....

Well, when we said FIRE, we meant a literal fire with flames and smoke and shorted out battery leads...I guess what ever it takes.

The 6.001 lab smelled pretty bad with 10 teams crammed into it all throughout the night. It also smelled bad because Johnny 5 vaporized a relay when it caught on fire.

Dinner: Maslab provided Pizza...Yay

Thursday Day 25: Feb 1st

You'll never guess why our program was buggy..no, it wasn't the UFO lights! It was totally a loose battery lead! The only reason we found it is because we saw a wabble in the wheel and were trying to re-align it. Apparently, Ellen managed to nudge the lead such that it shut the computer off...A series of fortunate events. So when the robot bumps into a wall, it will knock the lead slightly loose so that it loses power for a split second which will shut down the computer! After fixing that, there haven't been any more program random shut-down errors.

So Chris and Kim managed to stay up most of the night to finish the final calibration and to add some spin 270 code. In the morning, Chris and Kim went home and Ellen tested the robot for bugs and such. We have a few problems with white balance and some of the threashholds for shooting but we managed to fix that.

At 5:00pm, we had to do an exhibitition 2 minute run for the CEO of Texas Instruments. It was a really nice reception with awesome food. When we ran our robot, it took like 30 seconds to score and about 1 minute to get at practically all the balls. It spent the rest of the time bumbling around the field. ^_^.

We are having some trouble with the sound because we cannot play it from the orcpad but can with the terminal. Hmmmmm that is a problem. The staff says it alright if we attempt to run it with our terminal tomorrow.

Go Kilroy!!

Dinner: LaVerde's Sandwiches and Chris's parents took him out to eat.