BezBlog

I've been working on a simple usb led controller  (read  Part 1 ), but unfortunately ran into a bit a of snag - it turns out that the surface-mount package of the TLC5940 has different pin assignments than the through-hole version I've used before - even though it has the same number of pins in the same physical arrangement, the pin assignments are shifted over by 7 pins, which means my original PCB designs don't work.  Lesson learned: double check the datasheet!  I've updated the PCB design and sent off v0.2 to have new PCBs made, so now I just have to wait a few weeks for them to arrive. In the meantime though, I was able to get the LUFA usb library up and running, port the Arduino TLC5940 library to work on the ATMega32U2, and get a good portion of the led controlling firmware written.  In order to test this out, I programmed the controller board I built, but had to use led drivers on a separate breadboard.  It's ugly, but it works: The goal o...

Back when Next Make built the Next House Party Lighting System , we designed the LED controllers to connect on a shared RS-485 network over CAT5 cable.  This was a great solution for that system since the controllers were far apart (RS-485 uses differential signaling so it's pretty robust over longer distances), and we had 24 separate controllers to connect so we wanted to be able to chain them together on a single network. But if you wanted to set up a smaller scale LED system with just 1 or 2 sets of LEDs, those controllers were a bit overkill - you needed a separate USB->RS-485 converter and then had to string them together with CAT5.  So I set out to design a simpler high power LED controller that had a USB port directly on it (I'm calling it  SULC - the Simple USB LED Controller ). Instead of using an FTDI (USB->serial converter IC) along with a microcontroller, I wanted to try out the ATMega8/16/32U2 family of AVRs which has USB support built-in.  Un...

The Microsoft Natural Keyboard 4000 is pretty great, but the "Zoom" slider in the middle never seemed very useful to me - how often do I need to zoom in or out? I scroll much more often than I need to zoom, so it would be nice to remap to scroll instead.   Although Microsoft's control panel lets you remap the special function keys, it doesn't let you change the Zoom slider function. Luckily for Windows users there's a fairly simple xml file that you can edit to change the mapping (and there are plenty of explanations: SuperUser , Josh Highland , Joel Bennett , etc). Unfortunately, the "commands.xml" config file doesn't exist on Mac OS X. Instead, there's a binary file for the configuration, which makes it tough to modify: /Users/YOUR_NAME/Library/Preferences/com.microsoft.keyboard.pref After a bit of reverse-engineering, I was able to remap the Zoom slider to the UP and DOWN keys (sadly, using the SCROLL mapping doesn't auto-repeat...

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 lectu...

As part of MIT's 6.141 robotics course , we were challenged in teams to create autonomous robots that could navigate a space while collecting blocks and ultimately deploy those blocks to form some sort of structure (see: background and details ). The approach that my team took for the grand challenge was an ambitious one: create a fleet of diversified but simple robots that cooperate to gather and stack blocks. These “worker” robots are meant to be extremely simple remote-control vehicles that are commanded by a sensory “mothership” robot. The primary motivation was to develop a system that could parallelize tasks and capitalize on the agility of using smaller robots (for example, improved maneuverability in tight spaces). Our original design consisted of three “worker” robots: an agile gatherer that could grasp and carry a block, a dump truck that could carry multiple blocks, and a slow-but-precise stacker robot that could create block towers up to six blocks tall. The worker...

One of the coolest things about MIT is the wide range of opportunities to work on awesome projects outside of class. I'm on the executive board of a fairly new student group called Next Make . Next Make is a collection of motivated engineers in my dorm - Next House - with a mission of furthering Mens et Manus at MIT. We want to practice and teach hands-on engineering skills that build upon our collective past experience in order to learn and build really cool stuff! Over the past semester, and especially culminating at the beginning of February, I helped organize the design and construction of an amazing LED party lighting system for our dorm with Next Make. At the beginning, our goal was exactly that statement: "we want to build a really awesome LED party lighting system for our dorm." This was an admittedly broad goal, so during the semester we refined the idea into a detailed design that could actually be implemented. (On a sidenote, another cool thing about MIT...

As an organizer of MIT's 6.270 Autonomous Robot Design Competition I've been working on an improved vision-based system for tracking the contestants' robots on the playing field. (Sidenote: I competed in 6.270 last January and at some point I'll write a whole post or two about my experience. To sum it up, I had an awesome time competing, which is why I'm now an organizer of the competition) The basic concept is that we wirelessly feed each robots its coordinates throughout the round and act like GPS to help the robots navigate. However, this isn't as easy as it sounds. Our approach is to mount an overhead camera facing down at the playing field and then analyze the video to find special "fiducial" patterns on the robots. This isn't too hard in a controlled environment, but it gets tricky when the system has to ignore other objects on the field or when pieces of a robot go flying after it slams into a wall (which happens quite often during tes...