Legend Of Drunken Panda Journal
January 26th, 2005
Today we learned that "Legend of Drunken Panda" and "Drunken Panda" were titles too RAW, REAL, and UNCUT for the competition prgram on Friday. We dicussed other names that would still capture the essense of our team's spirit while not making use of any references to alcohol consumption.
The Panda Skeet Shooter finally came together!! After several completely faulty iterations of our Panda Skeet module, a much more presision built module was completed leaving nearly frictionless gear meshing and a nicely constrained housing. Here's a picture of our Green Machine (below):
This is an R/C motor that we bought in Watertown to solve our need for a high speed but robust motor. In the rest of the assembly (even further below) features two airplane tires for rollers, a large housing to contrain those rollers, and a set of gears set between two plates. The only prblem now is finding a way to quickly integrate the shooter to the rest of our robot before impounding. Scrapping the whole idea might be our final option if things don't go smoothly.
January 25th, 2005
Well, we haven't updated in a while, due to intense work on our Drunken Panda. I'll try to recap most of the important changes today...
Our robot is currently entering its finalized mechanical version. Brockton machined a new chassis, with tighter and further-forward wheels (for faster turning with a smaller turning radius). Will has been developing a ramped ball storage tray for the top of the robot, while Brockton has been assembling the ball shooter. Tom and Matt have been wrestling with custom circuitry for the shooter; the motor for the shooter runs at 7 volts and draws upwards of 6 amps when running. To accomodate for this, we bought an RC battery pack and are trying to integrate the electronics into the Orc. Our first attempt, a relay run by a motor port, was initially successful, but when running the motor with gear friction, the resulting current spike instantaneously melted all of the small diameter wires and header, resulting in a mess of melted plastic, sparks, and a nearly cooked Will. The second attempt involved chaining power tranisitors in parallel, but resulted in too much resistance for the motor to start up. The current (and hopefully final) attempt is the same as the first, but with thicker wires and no header (just tons of solder). Initial tests are promising, but we'll have to wait for the finished ball shooter module for final testing.
Recently, we've been wrestling with a number of tricky obstacles including a wide turning radius and occupancy map localization. The first problem arises when we try to complete an exploration turn (a 360 spin that enables our IR range finders to map our immediate surroundings) in a tight space. For example, today's mock contest started our robots off in a rather narrow 'hallway', from which our robot (and the robots of a handful of other teams) had little chance of escaping. This is largely due to our wheel positioning (in the rear) and our robot's affinity for large turns (360 spins). As a result, we've been coming up with compromises in our exploration tactics, and an overhaul of the avoidance code. Below is a video of our robot trying to escape from a similar hallway. Notice how it's first action is a spin, which quickly leads into a series of avoidance triggers (like running into walls...)
http://web.mit.edu/matthof/Public/Pics/CornerOfDeath.MPG
The occupancy map is another difficult problem. Using our IR sensors, we attempt to fill in a 200x200 grid (each grid point representing a 10x10cm square on the field) with values representing the likelihood of that location's being occupied by an obstacle (aka a wall). While this is extremely useful for path finding, it is difficult to build and maintain such a grid with imperfect sensor data (imagine the effect of gyro drift has you try to plot new occupancy values on top of your map...). Because we don't have the time or knowledge to "do it the right way" by using probability localization techniques, Matt is attempting to cheat by using carefully determined tolerances and blurring factors to create a usable map. Below is an example of one of the maps our robot built; in the second one, we marked the robot's starting location and orientation on the grid with a red 'S', and we marked the two goals it saw with yellow X's. The link below is to a video of the robot making this map, so you can observe the actual field setup (don't mind the audio commentary...)
The values in the grid range from 0 (unoccupied) to 1 (occupied). Each value is initialized to .5 (unsure), which has a color of light green in these graphs. Lower values have bluer colors, while higher values have redder values. In other words, red patches are walls, and blue patches are open spaces. Blue streaks near the edges of the graph are faulty sensor readings, or areas that seemed very far away at the time.
http://web.mit.edu/matthof/Public/Pics/Mapping.MPG
January 20th, 2005
More fury, same results.
January 19th, 2005
We've been working on our robot furiously, but breakthroughs haven't been the trend.
January 18th, 2005
Today we found out that the range finding ccode in the ORC API sucks. We had much better results once we started using our own math, especially when it came to determining the uncertainty for our sensor readings.
Incidentally, we also found out that our gyro is somewhat miscalibrated. When you turn the sensor 360 degrees, it only reports about 310 degrees of turning; when you turn it back to zero, it properly returns to zero (+/- a bit of drift). To accomodate for this, we are multiplying all of our sensor values by 71/60 (a magical, empirical scale factor) to restore the invariant of 360 degrees of physical turning = 360 degrees of sensor value change.
January 17th, 2005
For a Monday, it was a very productive day (although we still haven't gotten past checkpoint #2 yet.. heh...). Due to MLK Day, the machine shops were closed, so Brockton and Will were forced to make do with the tools in 38-500. Despite this setback, they managed to vastly improve the ball-raiser. Now, even without a back, it is able to lift a ball high above the robot, thanks to some wrestling with a picky motor and (what else) the miracle of duct tape. Yes, apparently using duct tape as a belt for the elevator is quite effective as a ball grabber and raiser. They also equipped the raiser with a funky "panda bite" cut out for wire access... personally, I think they just got lazy when cutting a hole somewhere...
On the software side, Tom greatly simplified his blue-line filtering code, which naturally resulted in its working much, much better. He also made great progress on goal identifying, wall identifying, and other color-based vision code. After much agonizing debugging, Matt was able to stop the robot from continually in circles when it was "exploring." This accomplishment was largely due to discovering that the motor wires were plugged in the opposite sockets, and by reducing the sensor updating from 20 times/sec to 10 times/sec. He suspects that his reduction of synchronization code in the control package may also have improved the code, due to the fact that he doesn't know enough about Java threading to make it work the way he wants, and because Java threading is, in many respects, a nightmare. At any rate, the robot is now cruising around, looking for nice open spots to travel to. Hopefully this improvement, in conjunction with Tom's rapidly improving vision code, will allow for an overwhelmingly successful Checkpoint #2 tomorrow.
January 15th, 2005
Not very much was accomplished today (it was a Saturday, after all), but we did get some footage of our failed attempts to pass Checkpoint #2. But first, behold, Drunken Panda v0.1, in all of its mangy glory!
And, for your amusement, the Drunken Panda v0.1 in action!
http://web.mit.edu/matthof/Public/Pics/SpinOfDeath.MPG - This is what happens when we let Matt write all of the control code. His play-by-play commentary is truly rewarding, while the robot's behavior leaves something to be desired.
http://web.mit.edu/matthof/Public/Pics/FishTail.MPG - Here, we actually manage to catch a ball! Only, we "fish tail" a lot when moving, due to poor motor control (we put in a simple PID controller later on to reduce this), and, of course, the ball was already in plain view of the robot...
January 14th, 2005
Friday - the day Checkpoint #2 (find a ball, score a point) was due - was a pretty hectic day. Will and Brockton showed up to Edgerton as early as possible to gain access to the overcrowded shop, enabling them to produce a few more parts for our bot. Unfortunately, the Drunken Panda is still in worse shape than our now-scrapped Pegbot. Currently, it has the lifter module in place, but without any of the internals or a place to deposit the balls. Instead, it contains a set of arms, the camera, two IR sensors, and a one-way door, all hastily thrown on in an effort to enable our robot to capture a ball (and score us a point for the checkpoint). Hopefully, over the weekend they'll be able to flesh out the rest of the long-anticipated Panda.
On the software side, Tom and Matt finally had a chance to put their code to use in the makeshift Panda; this allowed them to realize the many small bugs in their code in terms of thread synchonization, encoder translation, and motor protocols. They expect most of these issues to be resolved by Saturday. On the brighter side, many of the code modules are now operational (including Motors, Sensors, PandaVision, GetBall, Mapper, and Explore), and all of them work well together in JUnit test suites. Furthermore, Tom is racing ahead of the checkpoint on the vision code, making sure it can accurately filter above the blue line and read barcodes.
Hopefully, we'll be able to use our Drunken Panda 0.1 to complete the checkpoint before next Monday...
January 12th, 2005
Today we finished all red-ball finding code, and all that is left is linking that to the rest of the Panda Brain.
The Panda Skeet shooter development progressed with some makeshift motor attachment. We progressed with making CAD drawings of the parts we'd need for this module, and we are ready to build as soon as the machine shop isn't so ridiculously overcrowded.
January 11th, 2005
PandaVision is now upgraded to version 1.5 since it can now track multiple red objects. Coupled with using raster dataBuffer, redball finding algorithm can run in real time. However, we didn't run any benchmarking on the code. The code is as fast as we could make it right now. Hopefully, added detection scheme will not deteriorate the performance too much. Tomorrow, we'll recycle the code for redball tracking on wall, goal, and barcode identification. PandaBrain is now put together using multiple threaded modules mimicking actual control scheme as found in real pandas. Incorporating gyro and encoders, the PandaBrain can now make a good attempt at walking down a straight path and make turns.
We also bought some motors from watertown's RC store for the ball launching devise. In the next two days, we will need to quickly build a new chasis for our poor pegBot. And that's it for today.
Quote of the day: Pandas don't bite. Only a drunken one would...
January 10th, 2005
Today we tested the feasibility of our loading belt design. After slapping together some parts, we ended up with a prototype that could run a belt that was being held together by duct tape. The lessons we took away from testing the prototype will be useful in the future. For the final design, we'd like to make the height of the apparatus a bit taller (to approx. 1'), the width of the rubber slightly smaller (< 3"), and the total volume of the module more managable. Part of this plan includes integrating the motor so it rests inside the belt and replacing the dowel pins that hold in the rollers with a full length shaft.
On the software side, we've been mainly focusing on optimizing our camera code and developing a heavily threaded behavioral-model control system. Both tasks have been very trying, due to the complicated nature of Java threading and image processing; however, we expect enlightening results in the near future (at which point we can start working on checkpoint 2...).
January 8th & 9th
The weekend! We may have done some coding and made a few mechanical drawings, but the members of Legend Of Drunken Panda definitely lived up to our namesake.
January 7th, 2005
We finally fixed our encoders - as it turns out, one of them was broken, most likely due to a faulty phototransistor. Instead of counting up and down, it simply alternated between 2 values. This was a particularly hard issue to debug, because we had trouble interpreting the data.
In other news, we completed checkpoint one (finding a ball and approaching it). Our code was pretty simplistic; first, we would turn 45 degrees, take a picture, look for a ball in the picture, and loop until we saw something interesting. Then we would drive about halfway to the ball, stop and take a picture, update our trajectory, and drive halfway again, until we were within 20cm of the ball. The simplicity of the code, along with a huge number of "state" and estimated ball position printouts, made the task relatively easy to achieve; however, our red ball detection code was overly simplistic, leading to many false positives and poor estimates of ball distance. In the next design iteration, we plan to use the distance between the bottom of the image and the bottom of the ball, instead of the width of the ball, as a heuristic for ball distance. Also, we found it useful to ignore the top of the image when looking for red ball pixels.
We made huge progress in the design of our robot today, both mechanically and electronically. We decided to use a triangular belt to lift balls from the floor to the top of the robot, where they will be stored until the end of the contest. For a control model, we decided on a hybrid of the behavioral and FSM models, with the FSM serving has a highest-level control for the lower behaviors, which will use subsumption modules for determining behavior precedence. Finally, we decided the types and placements of our robot's sensors, which will include a short range and long range IR rangefinders mounted on a servo for range determination; two short range IR rangefinders for last resort collision preventions; and a break beam for ball collection detection. More details to follow...
January 6th, 2005
Looking into other potential motors for our robot, we found the specs for a few of the varieties offered by the staff:
January 5th, 2005
RGB... HSV... you would think finding black would be easy, but apparently, it isn't. We spent most of the day trying to get our camera to read a barcode (green and black segments on a rectangle, with a white background), which involved wrestling with rogue pixels, the camera auto adjusting for light, and lots of code updates to our Eden. Over the process, we came across a new way to get files on and off the bot - the 'rsync' command, for example, 'rsync -e ssh -azr maslab@{IP ADDRESS}:{DEST} .' to copy the contents of the current directory into a destination directory on Eden. Alternatively, 'rsync -e ssh -azr . maslab@{IP ADDRESS}:{SOURCE}' moves them back. Quite handy, if you write sloppy code and need to modify frequently...
Fortunately, by the end of the day, we could very accurately locate the center and approximate boundaries of the green and black regions. Interestingly, we found it easier to find the green regions using HSV colorspace (using a similar method used in the image tutorial), and the black regions using RGB color space (checking if the sum of the values was less than some tolerance).
Mechanically, we upgraded our Pegbot with encoders and cleanly attached the IR sensor and camera; we now have a fully assembled Pegbot, ready for action.
January 4th, 2005
Today we assembled our Pegbot, and equipped it with wheels, a short range IR sensor, and a touch sensor (old Nintendo power/reset button). Using the IR range finder and OrcSpy (as well as the curve fitting capabilities of Matlab), we calibrated our Pegbot code so that it could accurately judge distances ranging from 3 to 18 inches in front of the sensor. We then programmed the Pegbot to drive forward unless an obstacle was within 4-6 inches of the robot; the touch sensor served as a "kill program" switch. The touch sensor was highly useful, both in terms of breaking out of an infinite loop and because it minimized our interaction with the OrcPad?, which seemed to crash whenever we tried running too many operations on Eden at once.
Aside from completing the Pegbot goals for the day, we started to assemble our quadrature encoders, and had lengthy discussions about our overall strategy. Currently, we are focusing on ways to lift the balls to the top of our robot, then launch the balls over the field goal to maximize our score. There is dissention amongst the team members when it comes to the mechanics of moving the balls to the top of the bot; suggested lifters include chopstick-like arms, twin tennis-ball-launcher foam discs, and a servo-powered paddlewheel. We can't seem to agree which strategy would offer the most consistency while still enabling us to quickly and easily gobble up balls.
January 3rd, 2005
First day of MASLab! We started off the class by getting our kit, which came with a faulty Eden computer and overdrained battery. After overcoming these obstacles, we built the orc pad, assembled the Pegbot, and wrote a simple HelloWorld? program. Afterwards, we explored ways of altering the menu on the Orc board and methods by which we could copy files onto Eden via SSH. Deciding this was a good start, we headed home to start planning our strategy...