Team Seven/Journal
Contents |
Day 1
January 7
We went to lecture and discussed the game, parts, lab rules, etc. After the first lecture, we discussed our overall scoring strategy, and the robot functions that would be required to implement this strategy. Whiteboard sketches were drawn, erased, drawn, erased, etc. Parts were tallied, and it seems we'll be well within the number of sensor points allotted. We talked about an arm design we wanted to use and how it would handle trying to score in different towers and over the wall. We'll try to CAD something up tonight to finalize the configuration of components. For our software, we'll be sketching out our state machine to help us figure out what modules need to be written.
We put together the Pegbot, and coded up some basic control code for the Arduino. Then we found out there were different voltage regulators, and we had neglected to check the specs... costing us one melted voltage regulator. We couldn't figure out why the motors weren't working at all.
As it turns out, two of the pins on the Arduino Mega weren't working at all, so we switched up the pins we used, and now the robot moves! Hooray for movement! We've also set up the GitHub repo, and are now working on the second checkpoint and planning our state transitions.
Day 2
January 8
Lecture today was about robot behaviors and sensors. We found that while Hans is able to code up some pretty nice localization software, localizing himself in MIT is an issue. A clipboard with an algorithm written down to localize oneself on campus was suggested. Results of this experiment will be noted at the end of MASLab.
In lab, we tested sensors and webcam inputs, and refined our wall avoidance code a bit before getting the second checkpoint. We also finished the high level software planning, with all the state transitions and more or less listed the functions that needed to be implemented. Some parts of the robot were also drawn up in CAD.
Day 3
January 9
Today's morning lecture was about vision, and afternoon lab time was about beating our heads against the computer trying to get vision to work. Victor spent 2 hours trying to recognize quadrilaterals. Hosea spent 3 hours trying to point at corners. We also realized that pentagons are strange, and sometimes, they are actually quadrilaterals in disguise. On the mechanical side of things, we found that the little laptop isn't really so little. It's actually rather large. We shall have to be clever about housing it properly. We should probably get to machining things soon.
Along the way, we also got our first design review checkoff done by demonstrating that we can draw, use calendars, twiddle with threads, and think about playing games. We also got the encoder software working, and tested it by waving things in front if it. It should probably work when used with actual wheels. For this bit, we decided to have encoder plates with holes in them and use a photosensor instead of messing around with coupling rotary encoders to our wheels. These should work better.
And there was CADing, and coding long into the night. And there was evening, and there was morning- the third day.
Day 4
January 10
Lots and lots of CADing today. We more or less finalized a design, and decided to be ambitious and try to separate the balls we collected based on color so we can put only our balls in the tower, and throw only enemy balls over the scoring wall. This added two more systems to the robot- one to recognize the balls and divert enemy balls, and one to bring enemy balls from their own hopper back to the normal release point towards the end of the game. Strategically, this would help quite a bit. Hopefully, it's worth the extra effort. We might have two modes for opponents that are aggressive about scoring on the wall, and opponents who are primarily trying to score in their own tower.
Day 5
January 11
Turns out the new ball separation design needed quite a bit of work, so we spent a lot of time going through a couple different ways of doing this today, and did a whole bunch of CADing. On the software side, we're trying to simplify the code the staff provided because it seemed like that code had very wordy communications methods that would take way longer than is really necessary to actually talk to the Arduino. We tried for a long time to sweet-talk the Arduino into doing our bidding using Python. For a while, it was not swayed. Turns out at the end of the day that at least part of the issue was that Victor's COM ports were messed up, so the Arduino wasn't getting any data from the computer. By something like 2AM, we finally managed to make contact with the Arduino. We said hi, and it said "D;" back. Great success! Tomorrow will be a lot of machining. Hopefully, we'll be working much more on the actual robot soon rather than the pegbot.
Day 6
January 12
Today was a great day. We machined some things. They turned out very machine-like. Success!
Victor is very happy. So happy, he's rethinking his life as a course 6 major
We did a bit of testing on the Pegbot, which is getting frustrating, since the wiring is very messy, and it probably isn't worth it to fix it too much since we won't be using this for much longer anyway. Still, having to reconnect a bunch of things after every time we move the robot from lab is annoying. The vision code is more or less working now, so the robot can track balls. We continued messing with the communications protocol, and it seems to be more or less set by now. The only problem is that we can't test PID stuff well on the Pegbot because we don't have encoders on it. That will have to come when the actual robot is done.
Day 7
January 13
Today we decided we're going to win. WIN I TELL YA. The python code now has Arduino interfacing. Also it has an eye. ONE EYE- we named it cyclop (the eye, not the robot).
Day 8
January 14
Most of the CAD stuff under the top layer of the robot was finalized today. Matt spent most of the day machining stuff for the drive system. After dinner, we managed to get access to the CSAIL machine shop and cut out our bottom and middle bases and some of the supports and mounts for them. Lasers are very useful. We now have most of our acrylic pieces done, though one of bases might have to be redone due to a crack on one corner.
Day 9
January 15
Our robot kind of has a body now! We started putting together the acrylic parts, and are dealing with mounting some of the drive system stuff. We also managed to get our wheels waterjetted. We misjudged how big a sheet of metal would be needed to waterjet the wheels, so instead of using two 1/8 sheets, we combined two 1/16 sheets per wheel. We also redesigned our guide rail system for the top hopper. Instead of tilting the entire hopper to one side, we're bending the entire top hopper slightly so that the balls will roll towards the center instead, allowing us to use a straight set of guide rails instead of the curved set we were originally planning. We also thought to put in something of a counter-weight to the guide rails. This will ensure that the center of mass of the rails is near the servo, which stops the arm from oscillating as much when the robot is moving, and help the servo move the rails without as much torque.
Day 10
January 16
Lots of machining! Metal flying everywhere! We have carved the likeness of many robot parts from the scraps and not-scraps of material we scavenged and/or asked for and/or bought from lands far away. The drive system is nearly complete, and the bottom intake roller of our Lovely Machine has been constructed. The helical lift system is also partially installed now, though without the top hopper, it remains rather precarious. Hans has made and tested the ball differentiation system, so now our robot can sort balls using the power of Math!
In the evening, we refined our game strategy, which has changed somewhat since the beginning of the month. We realized that the new way we are having the robot handle the game removes the need for it to change "modes" depending on what the opponent does, since that would already be taken into account by how many and what kind of balls it is able to collect. The fact that we can sort balls now actually simplifies our strategy a lot, so the robot can be going after all the balls rather than just our balls or opponent balls at any given time. Simplicity is good.
Day 11
January 17
Lots of random little things to be fixed today. We made a bunch of mounts, trimmed off some of our metal bottom hopper, fixed up some of the hubs and axles that were giving us issues, and put the robot together. Edgerton was super-busy today, so machining was a bit slower than usual. After we put most of the first layer of the robot together, we realized that our roller rod was actually mounted too low, and balls couldn't pass through, so we will need to fix the holes on that.
During some late-night testing, we managed to get the robot to recognize green balls as well (it had previously only recognized red balls) and generally got the robot talking happily with Arduino and Python. Some mechanical issues came up during this testing though, and one of the wheels is still very wobbly- something we will have to fix in the morning. Because of these problems, we weren't able to fully test to robot's ball capture protocols beyond observing wheel movements while the robot was lifted up, and the rudimentary collision avoidance and wandering methods have only been observed as part of serial communication commands rather than full testing.
Day 12
January 18
Day 13
January 19
Day 14
January 21
Days 15 and 16
January 22 and 23
So Hosea is filling in this log two days after the fact, and admittedly, the last two days were kind of a very long blur, which is why this is one giant entry. A bunch of us were gone over the weekend, leaving poor Hans working on the robot for the most part. On Tuesday, we got the helix system up and running, which took a bit of extra machining along with a touch of tape to keep it sturdy. Actually, the tape helped a lot, and stabilized an otherwise unreliable system into something that could actually deliver balls to both of our hoppers. We are very thankful for tape. We also got the middle hopper cut out, and the supports for the top hopper in place. A bit of extra work around midnight of Tuesday/Wednesday saw the rubber band roller for the middle hopper completed. There was a bit of worry that it was too high to effectively trap the balls, but sometime in the wee hours of Wednesday morning, we put in a layer of bumpy foam stuff towards the front of the hopper, making it easier for balls to stay in until the roller turned on.
Lots and lots of soldering and electronics happened around this time too. We finally got rid of the pesky breadboard that kept on dropping wires, and now have things on a protoboard, which helps a lot when you don't want to rewire half the stuff at least twice a day. A state machine was also finished, which implemented the game strategy we came up with days ago, though communications between the state machine and the Arduino need to be worked out a bit. Turns out we missed an update to the staff code that would've made our lives easier, but Victor had put in some code a while ago that will probably work better anyway. And then at maybe 6 AM or thereabouts, something fizzed and smoked on our motor control board. And we were very sad because our robot couldn't move now.
Ah... the mock competition. Most of us were dead tired by this time, having gotten far fewer than however many number of hours doctors recommend. We found out that MASLab is not good for one's health. Anyway, though most of the mechanical systems and software probably worked, we didn't have any way to be sure until we got a new motor control board during the competition period. By then, we had put in a stripped-down version of the software, hoping to get the robot at least moving and maybe chasing balls on the field. But of course the motor wiring was now messed up, requiring us to re-test all the connections. You try wiring up a robot after sleeping two hours in two days. You and Hans could then bond over that experience while drinking the caffeinated beverage of your choice next to your semi-working robots.
Seems like we weren't as far behind as we thought though- at least relative to the other teams. Quite a few teams weren't able to compete, which is kind of sad when you look at the score boards and then glance back at the initial schedule we had planned for IAP. The sponsor dinner was amusing. Having the people paying for this whole thing see students dropping off from exhaustion right in the middle of their recruitment pitches may not have been the best idea (*** MASLAB STAFF TAKE NOTE***). I wonder what the Oracle guy thought when two people right in the front just gave up and put their heads down to sleep.
After the dinner, Matt and Kojo (who weren't among those of us who didn't sleep the previous night and were therefore still conscious and able to not kill themselves in a machine shop) got into CSAIL and fixed up the intake roller's positioning, making it much easier for it to grab balls. (At some point here, midnight passes and I'm actually writing into the next entry.) They also bent and mounted the top hopper, so now all three levels of the robot are in place! The robot now looks like a tipsy three-tiered creature of technological wonderfulness and trailing rainbows (of wires)! The fact that it looks tipped over, by the way, is intentional, in case you were concerned.
Day 16
January 24
Hans spent the day trying to find a way to use AVR code to talk to the Arduino so we can bypass Processing on the microcontroller. There's quite a bit of ambiguity about the mechanical design right now, because we're not sure whether we can/should put in a couple of components, such as the second (top) hopper, and the associated counting/ball differentiation/arm systems. It's complicated. It also really changes how we play the game. Hosea made a virtual robot to test state transitions and spent a bit of time looking online for a robot simulator to check wall following methods. The 6.01 code would have probably been suitable if it wasn't fairly complicated already and for the fact that Hosea is the only member of the team who hasn't taken 6.01...
Day 17
January 25
Day 18
January 26
MASLab staff decided to use black gym tiles instead of carpet. That's great for setup, but we have a heavy robot and spikey metal wheels. That means our robot sinks into the tile and refuses to move. That's not fun. We spent basically the whole day trying to make the drive system work properly, but the difference between the amount of force required to start motion on a squishy floor with spiked wheels and the amount of force required to keep it rolling is quite large. This means that the robot either will turn in a circle forever as one motor can't overcome the initial force and the other one does fine, or both motors get moving, and then one immediately overtakes the other. These are dark days for robots that wish to drive straight.
Day 19
January 28
We tested the robot late into the night. It sort of follows walls now, but sometimes likes to crash right into the wall for fun. The roller works great though. We're still adjusting the helix a bit, because it's hard to get it to provide enough torque to move the balls up without spinning so fast that it would never pick up balls from the bottom plate to begin with. We also found that that working on a carpeted surface is kind of hard because screws and nuts and bolts are hard to find when dropped on carpet... The night only ended because our motor controller died by 3AM and we could no longer get the robot to move at all.
Day 20
January 29 Mock competition was today. We hid in the hallway next to the stage for most of the time trying to get the robot to drive straight. It was a hard floor, so robot moved fine, but one motor was noticeably more powerful than the other, causing the robot to circle, or (more often) just overcorrect and crash into a wall. Lots of attempts at compensating for this only made things marginally better. During the mock competition, the robot again couldn't move on the tiles (big surprise there). It kind of shot forward then just got stuck. We had the timing right for shutdown though, and somehow, that meant we weren't actually last (in fact, we ranked near the middle). By the looks of many of the teams could barely move properly and had motor and code issues much like we were having. The mechanical part of MASLab definitely takes longer than everybody anticipated.
Day 21
January 30
On this fine morning, our robot caught on fire. We fried three motor controllers in the morning- at least one of which actually produced a big flame. After many attempts at trying to work out wiring and/or connection issues, and smelling a lot of smoke, and wondering whether it was safe to run the robot, we finally got Arthur to take a look. It took him about 5 seconds to tell us that our motors were (1) overloading our motor controller, and (2) were actually different models. Well, that explains why the robot kept on turning. We found we could either use our old motors with new rubber wheels that would let us move on the tiles, or swap out motors entirely. The robot frame, however, was only made for the old motors, so we decided to go with those for now. Mounting new wheels also presented a challenge, since the wheel wells were made for narrow metal wheels and not wide rubber ones. If we do decide to switch it would not be an easy process.
We swapped wheels and motors. And lo and behold, the robot drove straight, and even at a much slower, more manageble speed. Wall following actually worked for the most part by this evening. This day has got to be the fastest turnaround ever. The robot has officially moved purposefully on the gym tiles for the first time today.
At this point, we decided to scrap the top hopper and focus only on the systems we had working already. Mechanical issues have been dogging us long enough that we didn't want to (and didn't have time to) deal with any more systems in addition to what we already had.
Day 20
January 31
Lots and lots of testing today. Wall following works! Collision avoidance works! We quickly implemented some loop prevention and timeouts, which helped us immensely. Turns out that a "look around" method of loop prevention actually supplants one of our more complicated exploration methods and works very well, so we scrapped most of the movement methods for one entire phase of our game strategy, relying entirely on wall following, collision detection, and looking around to get us through the game. Things seem to work now. We realized that the way to get enough torque on the helix without the speed issue was to further "pwm" the motor by pulsing it between fast and slow speeds- the first to provide enough torque to lift the balls, and the second to be slow enough to actually catch balls in the bottom base.
We also tried scoring on the yellow wall now, having given up on scoring on the tower (we were too short to reach the top two layers). The scoring method is a bit crude, mainly involving rushing at the wall until we hit it and the torque of the wheels correcting for any angle differences (rather than relying much on sensors) and then sending balls over. It seems to work, though without mapping, we can't always guarantee that the robot would actually find the wall. We adjusted the length of the endgame phase of the strategy accordingly to account for this...
We impounded! It's over! Sleep! Freedom!
