Contents 1 Day 1: Monday 1/7 2 Day 2: Tuesday 1/8 3 Day 3: Wednesday 1/9 4 Day 4: Thursday 1/10 5 Day 5: Friday 1/11 6 Day 6: Saturday 1/12 7 Day 7: Monday, 1/14 8 Day 8: Tuesday 1/15 9 Day 9: Wednesday 1/16 9.1 TODO for Day 10, etc 10 Day 10 (1/17) and 11 (1/18) (part 1? Day "10" was a long day) 11 Day 11 (1/18) (part 2) 12 Day 12 (1/19) 13 Day 13 (1/21) 14 Day 14 (1/22) and 15A (1/23) 15 Day 15B (1/23) 16 Day 16 (1/24) 17 Day 17 (1/25) 18 Day 18 (1/26) 19 Day 19 (1/27) 20 Day 20 (1/28) 21 Day 21 (1/29) 22 Day 22 (1/30) 23 Day 23 (1/31) and Day 24 (2/1) part 1 24 Day 24 (2/1) Final Competition

Day 1: Monday 1/7

Today there were lectures on the game rules and software (with a focus on version control, state machines, and threading). We were supposed to complete checkpoint 1 (building the pegbot and getting it to move), but we didn't quite finish. We currently have a complete mechanical setup and believe we have powered everything correctly, but we're still working on communication between the computer and the arduino and the arduino and the motor controller. Our wiring is a bit of a mess; we really should have drawn a diagram before wiring anything.

Day 2: Tuesday 1/8

Taibo injured his arm this morning (not at maslab; don't worry, you're not responsible) and he no longer thinks he can do maslab. We are continuing as a team of 2. We completed checkpoints 1 and 2 today. For checkpoint 2 we used a short range ir sensor. When the detected distance to the wall is less than a threshold we turn away from the wall. We set range to 6-80 cm for SR IR sensor.

Day 3: Wednesday 1/9

Worked on mechanical and software design. Decided to use Archimedes wheel to pull ball up. Will experiement with IR sensors to see if we can use them to spot balls and paths.

Day 4: Thursday 1/10

Working on camera recognizing colors and robot going after balls. Checked idea of using LR IR sensors to find the balls - unfortunately ball is too small to generate reliable signal in sensor.

Day 5: Friday 1/11

Vision is now functional (and pretty fast). It has false positives for skin/wood colored stuff, but this shouldn't be a problem if we mount the camera at wall height (and limit ball detection to below ball height). So far it only works on red balls, but it will be easy to add green balls. Code is currently calibrated for the reference images, but it still works with the webcam (it doesn't classify red pixels particularly well but it still finds the ball). Yaroslav started writing PID code. Tomorrow we will put the two together.

We don't have much of an official schedule beyond a few days -- we should probably fix that. But we probably won't, at least not until the first competition. Between now and then we need to integrate vision code with PID for narrowing in on balls, write a generic wandering algorithm, and redesign/reorganize the pegbot sufficiently to fit a computer and a camera. And write code to record video to a file. And preferably figure out white balance (or other camera calibration) so the video will look the same as video we take in the future. We will probably only be moving balls around; I doubt that we'll be able to pick up balls.

Day 6: Saturday 1/12

Refactored the code a lot; vision now works on green balls (actually it works better because the background is somewhat red in hue but nothing is very close to green. I can hold a green ball in my hand and detect the ball properly). Detected balls have been translated into angles for pid purposes.

Day 7: Monday, 1/14

Adam joined the team. Started the robot based on a switch press. There's a several second delay between pressing the switch and important code executing; we'll have to figure out what causes that. But it's generally less than 5 seconds, so we're probably ok. We combined pid stuff with vision but our code kept crashing (pid code didn't work right after being reset -- didn't handle not having a dt properly). As a result we didn't do the mock competition -- at best our robot would have done nothing but it also might have crashed and gotten stuck running it's wheels at some constant speed, pushing down walls or damaging the motors. The problem was solved later that evening.

Day 8: Tuesday 1/15

Today we mainly worked on code, refactoring everything for multithreaded use. We also discussed design and scoring strategy (although unfortunately a rules clarification ruled out what we guessed would be our most effective scoring strategy). We will keep working on design later today.

Day 9: Wednesday 1/16

Today we dismantled the pegbot and touched up our designs to prepare to build. Then we talked to a course 2 major and largely redesigned the robot. The new version (mostly but not fully CADed yet) will depend on the use of a laser cutter for construction. Our original lifter idea has been replaced entirely due to the inconveniences of transferring the ball from the roller to the lifter. This also solves the problem of the lifter either interfering with the ball deployment mechanism or taking up too much space on the robot diagonally (front to back and bottom to top). Instead we, the roller pushes balls into a basket-like storage device. A four-bar linkage (one motor!) moves the basket from inside the robot to the approximate correct dumping position for the middle tower and upends the basket. We don't know the exact dimensions for the four-bar linkage yet, but based on approximate dimensions it shouldn't hit anything in the robot and it will extend far enough over the tower.

TODO for Day 10, etc

• Find a laser cutter that we can use
• Get other parts (e.g. battery, electronics) to measure and CAD. Measure and CAD them.
• Determine exact dimensions for the four-bar linkage; add it to the CAD
• Adjust existing CAD to fit actual (rather than estimated) dimensions for them. Plan wire routing, add holes for zipties
• Find lots of the same size of screw; add tabs and slots (tightened by screws) to the CAD
• Laser-cut the entire robot
• Assemble robot
• Yeah, I guess it still needs code. Even if it looks really cool.
•  ???? (anything here?)
• Profit

Day 10 (1/17) and 11 (1/18) (part 1? Day "10" was a long day)

Lots of CADing happened, but unfortunately the 4-bar linkage dimensions don't work out so well. So the lifting mechanism still needs to be designed/CADed. We built a bot with similar functionality to the pegbot (but better; better caster wheels, etc --> can turn intentionally). Code for turning towards balls doesn't work particularly well, but it does work. Mock 2 code was single threaded, so it came as no surprise that the robot was slow to react to walls. The wall avoidance method needs to be improved; the robot got stuck trying to back away from a wall into another wall several times over the course of Mock 2. Also note that the wires to the left motor should be replaced; they aren't the right size for the crimplings and they came out during Mock 2.

Day 11 (1/18) (part 2)

More CADing. The four bar linkage is being replaced with a winch-like lifter and a ramp. The ramp might be passive (starts vertical, gets knocked down by the lifter, and stays down for the rest of the game) or might be powered by a servo (potentially more reliable and we have enough spare sensor points).

Day 12 (1/19)

Lots of coding, lots of CADing. Multithreaded code now runs, but for some reason it reads values for the IR sensors incorrectly (but it's definitely a software problem, since the single-threaded code still reads them properly). CAD for the lifter is almost complete, but the robot still needs a lot of features before it can be laser cut. We have a few parts (e.g. couplers) that will need to be machined rather than laser cut.

Day 13 (1/21)

Lots of CADing. We were hoping the robot would be ready to laser cut by the end of today, but sadly it's still lacking many details (sensor placement, tabs + slots, etc). Resolved the problem with the IR sensors: they weren't reading properly because the battery wasn't connected; the battery was connected for the single-threaded version because for that version the output was wheel speed (rather than printed text). I must have been really tired that night. I theorize that multithreaded code is really slow because if image acquisition. Python switches threads after 100 bytecode instructions, but the image acquisition isn't many instructions (and takes a long time because of communication stuff). So if it is ever acquiring an image, everything else has to wait for 100 bytecode worth of images to be acquired. I started changed from threads to processes because processes shouldn't have this issue (and could potentially take advantage of the 2nd core).

Day 14 (1/22) and 15A (1/23)

Lots of CADing, some coding. The robot still wasn't ready to be cut, but it was time to cut it. So some parts of the robot will look great and some will be hacked together. Multithreaded code has been fully converted to multi-process code and it works beautifully. By which I mean it immediately reacts when I put my hand in front of the ir sensor. Image processing is running at ~8 Hz, which is less than ideal but sufficient for now. If we switch (as I hope to) from using the camera as feedback for PID loops to using the gyro as feedback for PID loops it really won't matter much at all how slow vision is. Not all laser cutters are created equal. Or something like that. Because some pieces are very nicely cut while others are singed, not fully cut, and extremely difficult to peel the paper off of. I'm almost done with that and will experimentally put some pieces together. Then I'll have to make some marks on them and take them apart to put a few extra holes in them. Too bad the CAD wasn't completely done. Still hoping to be done with that before Mock 3.

Day 15B (1/23)

Assembled the base of the robot. One side will have to be re-cut b/c it got mangled and several other parts will have to be re-cut because of mistakes. Lifter, etc will be fixed and constructed later. Electronics were attached to the back of the robot. Neither motor moved; eventually we discovered two separate wiring problems causing this. For some reason our hacked-together "stop after 3 minutes" code didn't work in the multiprocess version of the code; will have to debug that later. The sponsor dinner happened.

Day 16 (1/24)

Coding, CADing, Vecna lecture, trip to Home Depot (although not quite in that order). Medium Density Fiberboard (MDF) at .25" is sufficiently hard and should actually be easier to cut that the acrylic. And it's much cheaper. We bought 2 4x2 boards for ~$10. And that's enough material to print the entire robot ~twice. We also bought some aluminum rods to use as axles.

Day 17 (1/25)

More on-robot testing. It appears the IR distance sensors no longer work right. But I got the compass on the IMU working (fixed a sign-related bug in staff code, besides that plug and play) and figured out how to use a modded servo as a motor. It looks like we won't actually have to do that for the final robot, which is good because it's really hard to make it stop.

Day 18 (1/26)

Lots of CADing, with the hope of laser cutting at 10am tomorrow. Lots of coding, including fixing the problem with the IR sensors (staff code returned values shifted by 257 for analog sensors). Started writing lots of states for the state machine.

Day 19 (1/27)

We weren't done with the CAD by 10am, so nothing got laser cut. Just a long day of CADing and coding. But the CAD really is pretty much done now (and hopefully will be fully done (on drawing sheets) in the next half hour or so). And it has a lot more holes for mounting electronics, etc, which should make assembly easier. Hopefully we can laser cut tomorrow morning.... Code has switched from using a strict state machine to something more like a set of prioritized behaviors. It functions in a similar way, but it is a lot easier to code the transitions (and not forget to back up from walls when you hit them) and to remember old states. The robot's AI really (naturally) is a set of behaviors; state machines are a better fit for functionality like controlling individual mechanisms (input logical function command, output motor command). Behaviors have been coded for most of the tasks involved in collecting balls, with the notable exception of the BallManager (which keeps track of where the balls we've detected are). Hopefully this will change before I go to sleep.

Day 20 (1/28)

It did not change before I went to sleep. But the CAD is done. But then our laser cutting plan fell through and our backup laser cutting plan fell through. But now there is another plan, which should not fall through. Laser cutting will happen at midnight. Fortunately the robot should be easy/fun to assemble post-cutting; the design is pretty awesome in that respect. Really it's pretty awesome in a lot of ways. I added code functionality for recording video (along with all the other log files), so we should have plenty of vision testing material after the seeding competition. The BallManager is mostly done and I am working on it now (well actually I'm writing a journal entry, but you get the point). Next I need to set up the getPriority method of the ball-acquiring behaviors so they take precidence over wandering when we know where a ball is (not too hard; most of that work is in the BallManager). After that I need to tie together some loose ends with the arduino I/O (easy code, but needs the arduino to be wired) and converting some pilot commands to arduino commands (also easy, just needs to be done). Then I need to debug syntax/logic errors and the robot should work. At least to the extent of finding and collecting balls; there likely won't be sufficient vision to find scoring zones and score the balls. But if the robot can do all that for seeding I have good hopes for the final competition. Oh, and I need to crop the camera image so it only detects balls below the camera. The vision algorithm was designed to distinguish balls from other field elements, not (e.g.) tan walls or light colored (read: red -ish hue) skin. Expect another update... some time. More work will be done today.

Update: laser cutting completed, but there aren't enough screws and the motor mounts need more time to fit together than I currently have. Too bad I already took apart the Mock 3 robot for its screws; we have to use it now.

Day 21 (1/29)

After an unexpectedly long nap I somehow managed to reconstruct the mock 3 robot in time for the seeding competition. But there was a code bug (of course) so the first two matches the robot didn't do anything. For the next match it moved and avoided walls but didn't really track balls. And didn't stop, for whatever reason. That will have to be debugged. Now that our robot is done with its seeding matches I'm just watching other robots. It looks like most of the robots in the lower bracket have trouble moving and at most collect a single ball. We have no trouble moving; we have enough clearance and sufficient mechanical advantage. I believe the winning bracket has robots that score reasonable numbers of points, but I haven't seen any of the matches yet. But it's probably a good idea to focus on collecting balls (8 balls * 5 points per ball + possible 200 point bonus?) and potentially score over the yellow wall. So far no one has pressed the cyan button to release additional balls.

Update: one team just pressed the button and collected a total of 6 balls. New high score! And first button press! Still, it looks like any functional scoring mechanism would be enough to place well if not win. Will any of the teams good at collecting balls add/fix a scoring mechanism in the next few days?

Update: another team collected 6 balls (w/o button). It's becoming apparent to me that there is no reason to have such a complicated BallManager; picking the closest (ish) ball that is currently on screen should be sufficient. This robot moves really slowly; the same algorithm on a robot of our speed could reasonably clear the field. It seems reasonable to assume the BallManager I wrote (and haven't tested) is buggy; it should be replaced with "remember no balls; target the most convenient (closest) ball that you currently see", which would be easy to code and be fairly consistent on the field.

Update: Winning quote by Roxana: "Is it ok if it just vomits on the field" (their robot runs its roller in reverse after the match ends).

Day 22 (1/30)

Build, build, build; code, code, code; wire, wire, wire (well more soldering, really, but it's too many syllables). The latest and greatest version of the robot is mostly assembled (separate sub-systems are assembled but a couple of important parts need to be fixed by hand). The code has pretty much all the features it is going to have (including finding and scoring over the yellow wall -- hopefully that will work!) but it hasn't been tested at all. Actually it probably has a bunch of typos in it; after I finish this journal entry I'll start debugging it. Oh, and the robot is going to talk. Because who wouldn't want their robot to talk? It needs to work on its (non-existent) listening skills, though.

Day 23 (1/31) and Day 24 (2/1) part 1

Build, build, build; code, code, code; wire, wire, wire. Sound at all like yesterday? We finally assembled the complete robot, but the lifting mechanism doesn't work (it probably needs to be resdesigned; the pegs jam). So we'll probably just be collecting balls. The first time we test code on the robot both wheels and the roller move -- a good sign! But then we tested it again on the ground and it went nowhere and emitted smoke. At this point we're about an hour late for impounding so we break for dinner, etc. Eventually I go looking for Tej, who is also looking for me, and we take the robot to lab. The robot gets another redesign at lab: the squishy wheels are replaced with fairly hard wheels (and a different wheel mount) and the basket is replaced with a sheet metal ramp. The ramp doesn't work very well, but to be fair the basket would have been really hard to keep aligned. The first time it drives on the field the robot sprints forward, takes a sharp turn, and barges through a wall. So drive worked, but something else went wrong. I slowed the robot down and it showed clear signs of following balls (but failed to pick them up because the ramp wasn't adjusted right). Then it stopped and emitted more smoke. A few trials later it made really loud noises while driving and moves really slowly. I surmised that the set screws have come loose and applied locktight. And now I'm writing a journal entry and deciding whether to sleep in a chair or to debug the robot more. It sure doesn't work very well now; I probably ought to debug it.

Day 24 (2/1) Final Competition

So the robot wasn't really ready for competition. The first match it didn't do anything and I don't know why. Looking at the logs afterwards something caused it to lose communication with the arduino (and get "Timeout" messages), but I don't know what. In the second match it stayed put and spun its roller. When I looked at the computer afterwards to see what it thought it was doing I found a giant list of error messages along the lines of "logger.debug(...) failed because the target file is read-only". It turns out the entire hard drive was read-only for some reason. And upon rebooting it couldn't find "/". It offered to try to fix the problem and it successfully recovered its file system. Weirdest robot problem ever. And I still don't know why the wheels weren't running. My plan is to clean up around Random over the next few days, leave the robot alone for a while, and get back to working on it for a more reasonable number of hours each day. It would be nice to have the robot work the way it's supposed to.