Skip to main content

Running 6.270 Robotics Competition

This past January I organized and ran MIT's 26th annual 6.270 Autonomous Lego Robotics Competition. Basically groups of 2 or 3 students are given a box with Lego, a microcontroller, motors, and sensors, and they have just 3 weeks to put together and program a fully autonomous robot to compete in a game.

Here's the first part of the final competition video:

MIT Tech TV

Part 2 is on MIT TechTV


This year's game was about capturing territories and gathering resources, on a hexagonal playing field:
The organizing team with the playing field


Robots had to spin a gearbox to capture a territory:



Then they could collect ping pong balls by pulling a lever:



And then dump them on their half of the center:



One of the robots actually shot the ping pong balls into the center:



But the really cool part is that 6.270 is entirely student-run - the organizing team that I led had about 8 core members that took care of everything from ordering Lego, motors, and electronics, to developing lectures and labs to teach the basics of autonomous systems to the ~60 students enrolled in the class. We also design the game itself (playing field, scoring, etc), and interact with companies to get sponsorship for the competition.

We were really ambitious this year, making a hexagonal playing field rather than the usual rectangular one. One of the organizers was able to CNC-cut the plywood:

I did all the electronics in the playing field - programming a microcontroller to read the quadrature encoders on all 6 of the gearboxes, sensing the breakbeams attached to each lever, and controlling the 6 servos that dispensed the ping pong balls. This interfaced with the "vision positioning system" computer that wirelessly transmits each robot's location along with the score, who owns each territory, and how many balls are remaining in each territory - which the robots could use to make decisions.

We also integrated LED lighting in the table to indicate which team owned each territory (using my friend Joe's ACRIS LED controllers):


When we weren't giving lectures or helping contestants with their robots, the organizers had time to build a robot of our own. One of the cooler robot drive systems is omni-drive - each of the wheels are actually compound wheels, made out of a bunch of smaller wheels around the circumference. The smaller wheels are placed perpendicular to the drive direction of the large "wheel", so that it can roll sideways. This allows the robot to strafe in any direction and rotate in place (or both simultaneously). Here's one of the LEGO omni-wheels I designed:

And here's a video of the omnibot in action:




Running 6.270 was a really fun & rewarding experience - I got experience lecturing to a large group of students, learned about the HappyBoard's embedded software, hardware, etc, learned how to do basic PCB layout work on the HappyBoard, taught myself OpenCV to create the vision positioning system, utilized my 6.111 knowledge to do some FPGA programming, interacted with reps from Apple, Oracle, Dropbox, and more!


(My girlfriend made me a LEGO cake after the final competition was over!)



That's all for now. You should watch the final competition video - there were some really amazing robots this year!

Comments

Popular posts from this blog

OpenSCAD Rendering Tricks, Part 3: Web viewer

This is my sixth post in a series about the  open source split-flap display  I’ve been designing in my free time. Check out a  video of the prototype . Posts in the series: Scripting KiCad Pcbnew exports Automated KiCad, OpenSCAD rendering using Travis CI Using UI automation to export KiCad schematics OpenSCAD Rendering Tricks, Part 1: Animated GIF OpenSCAD Rendering Tricks, Part 2: Laser Cutting OpenSCAD Rendering Tricks, Part 3: Web viewer One of my goals when building the split-flap display was to make sure it was easy to visualize the end product and look at the design in detail without having to download the full source or install any programs. It’s hard to get excited about a project you find online if you need to invest time and effort before you even know how it works or what it looks like. I’ve previously blogged about automatically exporting the schematics, PCB layout , and even an animated gif of the 3D model to make it easier to understand the project at a glanc

Scripting KiCad Pcbnew exports

This is my first post in a series about the  open source split-flap display  I’ve been designing in my free time. Check out a  video of the prototype . Posts in the series: Scripting KiCad Pcbnew exports Automated KiCad, OpenSCAD rendering using Travis CI Using UI automation to export KiCad schematics OpenSCAD Rendering Tricks, Part 1: Animated GIF OpenSCAD Rendering Tricks, Part 2: Laser Cutting OpenSCAD Rendering Tricks, Part 3: Web viewer For the past few months I’ve been designing an open source split-flap display in my free time — the kind of retro electromechanical display that used to be in airports and train stations before LEDs and LCDs took over and makes that distinctive “tick tick tick tick” sound as the letters and numbers flip into place. I designed the electronics in KiCad, and one of the things I wanted to do was include a nice picture of the current state of the custom PCB design in the project’s README file. Of course, I could generate a snapshot of the

Using UI automation to export KiCad schematics

This is my third post in a series about the open source split-flap display I’ve been designing in my free time. I’ll hopefully write a bit more about the overall design process in the future, but for now wanted to start with some fairly technical posts about build automation on that project. Posts in the series: Scripting KiCad Pcbnew exports Automated KiCad, OpenSCAD rendering using Travis CI Using UI automation to export KiCad schematics OpenSCAD Rendering Tricks, Part 1: Animated GIF OpenSCAD Rendering Tricks, Part 2: Laser Cutting OpenSCAD Rendering Tricks, Part 3: Web viewer Since I’ve been designing the split-flap display as an open source project, I wanted to make sure that all of the different components were easily accessible and visible for someone new or just browsing the project. Today’s post continues the series on automatically rendering images to include in the project’s README, but this time we go beyond simple programmatic bindings to get what we want: the