Make It Compatible

I’m probably as guilty as anyone of reinventing the wheel for a subpart of a project. Heck, sometimes I just feel like working on a wheel design. But if that’s the path you choose, you have to think about whether or not it’s important that others can replicate your project. The nice thing about a bog-standard wheel is that everyone has got one.

The case study I have in mind is a wall-plotter project that appeared on Hackaday this week. It’s a really sweet design, and in many ways would be an ideal starter project. I actually need a wall plotter (for reasons) and like a number of the choices made. For instance, having nearly everything, including the lightweight geared steppers on the gondola makes it easy to install and uninstall — you just pin up the timing belt from which it hangs and you’re done. Extra weight on the gondola helps with stability anyway. It’s open source and based on the Arduino libraries, so it should be easy enough to port to whatever microcontroller I have on hand.

But the image-generation toolchain is awkward, involving cutting and pasting into a spreadsheet, which generates a text file in a custom plotting micro-language. Presumably the designer doesn’t know about Gcode, which is essentially the lingua franca of moving machines, or just didn’t feel like implementing it. Where in Gcode, movement commands are like “G1 X100 Y50”, this device expects “draw_line(0,0,100,50)”. They’re essentially equivalent, but incompatible.

I totally understand that the author must have had a good time thinking up the movement commands and writing the spreadsheet that translates SVG files into them. I’ve been there and done that! But if the wall plotter spoke Gcode instead of its own dialect, it would slot instantly into any number of graphics processing workflows, which would make me, the potential user, happier.

When you are looking at reinventing the wheel, think about your audience. If you’re the only person likely to see the project, go ahead and scratch whatever itch you’ve got. You’ll learn more that way. But if you want to share the project with as many people as possible, adhering to the most widely used standards is a good choice for your users, even if it is less fun than dreaming up your own movement language.

Fumik: An Arduino Wall Drawing Robot Jellyfish

If you’ve ever wanted to build a large format plotter but didn’t have the floor space, maybe put it up against the wall and make it cute. That’s the idea behind Fumik, the wall-drawing robot. As you might expect, the little device is just a motion base with a pen. We hope there’s paper against the wall since not everyone wants computer-generated art on their drywall.

The maximum size is apparently 5 m wide by 3 m tall, plenty of room to express yourself. The controller is an Arduino Mega, and stepper motors with a CNC shield drive the whole assembly. Interestingly, the motor and electronics are all onboard the jellyfish itself, rather than the wall.

The device only holds one pen at a time, but you can draw with one color and then manually change the pen. The files on GitHub are good, but you’ll need to intuit some of the mechanics from the videos. However, since it uses off-the-shelf hardware, it should be pretty easy to figure it out. This looks like a cheap and cheerful wall plotter, and the results speak for themselves.

We have seen similar wall plotters. More than once, even.

Continue reading “Fumik: An Arduino Wall Drawing Robot Jellyfish”