Category Archives: Engineering

ComBots Cup VI

ComBots Cup VI


This weekend is ComBots Cup VI at the San Mateo Expo center. This event is eloquently described over at Suicide Bots:

“Dozens of robots makers from all over the globe have cast common sense to the wind and scattered the contents of their bank accounts in sacrifice to The Robot Gods in order to bring you one amazing weekend of total mechanical ridiculousness in the form of ear-searing, heart-stopping, insurance-adjuster-apoplexy-causing Robot Combat!”

The event runs Saturday and Sunday from 2 pm to 7 pm and advance tickets are available here.


mini jack-o-lantern in eggbot


We’ll be running a few robots of our own (vs. eggs and pumpkins–not an entirely fair fight) and will be bringing robots and robot accessories for your last minute Halloween decorating needs. Hope to see you there!

Halloween Projects from Evil Mad Scientist Laboratories

The Great Evil Mad Scientist Laboratories Halloween Project Archive!

Halloween is one of our favorite holidays, and our collection of Halloween projects continues to grow. Every fall we update it to include our latest projects for the season. In the list that follows, we’ve organized dozens of our Halloween projects into categories: costumes, pumpkins, decor and food.

Last updated: 10/2019.

Continue reading Halloween Projects from Evil Mad Scientist Laboratories

Improving open source hardware: Visual diffs

pcbdiff

As the open source hardware movement matures, it’s worth taking a moment to consider the issue of version control.

Collaborative software projects make heavy use of version control– tools like Subversion and Git, and project hosting sites like SourceForge, GitHub, and Google Code –to organize and manage the contributions of many developers to a project. But as we begin to consider open source hardware, can we use these same tools and sites for effective collaboration on hardware projects?

The short answer is, “yes”– after all, people are already doing it. But the reality is that we could do much, much better. Some people think that we do need a separate “SourceForge for hardware.” That’s hard to say. But it is the case– perhaps against conventional wisdom –that existing tools can be used, today, for meaningful hardware version control.

It’s certainly possible to take any old binary file (say from a CAD program), and store it in a version control system. This is, in fact, how many of today’s open source hardware projects are managed. However, a “diff” (direct file comparison) to see what’s changed between two versions of a given file is all but meaningless.

For design files in plain-text (“ascii”) file formats, such as Inkscape‘s SVG or KiCad‘s .brd, a diff is possible and is in principle meaningful, but it is usually all but useless in practice, because CAD is a graphical sport, and we need to treat it like graphics.

An example: Suppose that you found the following snippet in the difference between two SVG files:

 <path
       sodipodi:type="arc"
       style="fill:#ff00ff;fill-opacity:1;stroke:#ffa6a6;stroke-width:0.18000001;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
       id="path2816"
       sodipodi:cx="237.14285"
       sodipodi:cy="328.07648"
       sodipodi:rx="160"
       sodipodi:ry="84.285713"
       d="m 397.14285,328.07648 a 160,84.285713 0 1 1 -319.999997,0 160,84.285713 0 1 1 319.999997,0 z" />

You probably wouldn’t recognize that (at least not quickly) as a big magenta ellipse. While it’s perfectly legible as source code, a diff result like this would be all but useless in practice.

The obvious solution, is to add in some visual diffs in order to make sense of changes between design files. On the bright side, making these is remarkably straightforward, and– with a little bit of effort –practically supported by existing version control systems.

In what follows, we’ll walk through some examples of visual diffs– with bitmaps and PDF files –and discuss what you can do to help make version control work better for CAD files, and to make CAD files better for version control.

Continue reading Improving open source hardware: Visual diffs

In pictures: Maker Faire NY 2011

MFNY2011 - 007

The Yellow Drum Machine, above, finds and makes music with a glass beaker and an empty juice bottle: Just one of an amazing number of amazing things going on at Maker Faire NY this past weekend.

Maker Faire NY 2011

Trying to get a flavor of the whole fair(e), we’ve put over 250 other photos from Maker Faire into a photo set that you can view on flickr.

A new Kraftwerk-inspired LED tie kit?

LED Tie - 28.jpg

Well, almost— With a breath of new firmware, our Larson Scanner kit takes us on a trip to the late 1970’s.

In the old videos of electronic music pioneers Kraftwerk performing their classic The Robots, a prominent prop is the animated LED necktie worn by each member of the band. If you haven’t seen this, or it’s been a while, you can see it right here at YouTube. (Additional viewing, if you’re so inclined: Die Roboter, the German version.)

The Kraftwerk tie has nine red LEDs in a vertical row, and one lights up after the one above it in a simple descending pattern. And what does it say to the world? One thing only, loud and clear: “We are the robots.” Now, if you’re anything like us, the most important question going through your head at this point is something along the lines of “why am I not wearing a tie like that right now?

larson3

The good news is that it’s actually easy to make one. And the starting point? A circuit with nine red LEDs and just the right spacing: our open-source Larson Scanner kit. With minor modifications– a software change and dumping the heavy 2xAA battery pack–it makes a pretty awesome tie. In what follows, we’ll show you how to build your own, complete with video.

Continue reading A new Kraftwerk-inspired LED tie kit?

Octolively: Digital interactive LED surfaces

Octolively Array: 8 inches wide

Octolively is an all-new, open source interactive LED surface kit that we’re releasing today. Octolively features high resolution– an independent motion sensor for every LED, stand-alone operation, a variety of response functions, and easy scaling for large grids.

Warm white (left), Regular "cool" white (right)

Octolively represents our fourth generation of interactive LED surfaces.

Long-time readers might recall the original Interactive LED Dining Table, the infamous Interactive LED Coffee Tables, or the third-generation, not-very-creatively-named Interactive LED Panels. All of these surfaces were based on fully-analog circuitry with large circuit boards and a fairly high ratio of LEDs to sensors– typically 20:1.

Octolively: single unit, powered down-2

Octolively, by contrast, is based on smaller, lower-cost circuit board modules, “only” 4×8 inches in size. Part of the reason for this is so that there’s more flexibility in making arbitrarily shaped arrays. Arrays can now be as skinny as 4″ wide, or as wide as you like.

Each module features 8 LEDs and 8 independent proximity sensors– one for each and every LED. The LEDs are (huge) 10 mm types, and that chip in the middle of the board is an (also huge) ATmega164 microcontroller.
Each sensor consists of an infrared LED and phototransistor pair, which– together with polling and readout from the microcontroller –acts as reflective motion sensor. The LEDs are spaced on a 2-inch grid, and the edge connectors allow boards to be tiled seamlessly.

Because the circuit is now primarily digital, it’s easy to store a variety of response functions in the microcontroller. Our standard firmware contains 8 different response functions– fades, ripples, shadows and sparkles, which you can change with a button press. As it’s an open source project, we’ll expect that (in time), others will become available as well.

Octolively: 3x3 grid of boards

And, because the entire circuit is self-contained on the module, the surface scales effortlessly– you get very high resolution over huge areas without bandwidth bottlenecks, and no need for a central computer.

Of course, static pictures don’t do much justice for interactive LED surfaces. (We’ve embedded our video above. If you can’t see it here, click through to YouTube.)

Octolively, warm white LEDs

And doesn’t that look good with warm white LEDs?

Octolively begins shipping next week. Additional details– including the datasheet and documentation links –are available on the product page.

Does this LED sound funny to you?

flickerLED - 01

flickerLED - 02

At first glance, these might appear to be normal 5 mm (“T-1 3/4”) clear lens ultrabright yellow LEDs. However, they’re actually “candle flicker” LEDs— self-flickering LEDs with a built-in flicker circuit that emulates the seemingly-random behavior of a candle flame.

In the close-up photo above, you can actually make out the glowing LED die on the left side, and a corresponding-but-not-glowing block on the right: the flicker circuit itself. In what follows, we’ll take a much closer look, and even use that little flicker chip to drive larger circuitry. Continue reading Does this LED sound funny to you?