Wire Beings

Wire Beings is an open source robotics project that’s easy to build, easy to extend, and lots of fun. And because it’s design is so simple, it makes a great project for introducing robotics to kids. STEM leadership in schools should take notice. This could be a fantastic project for use in the classroom. There’s a little bit of everything here – mechanical design, electronics, and embedded software.

I came across the Wire Beings project on Hackaday a few months back and decided to give it a whirl. As you can see from the video below, this little guy is pretty mobile. I was driving it from my phone over Bluetooth, but there’s also support for obstacle avoidance and voice control modes.The eyes change color too.

For those who are also interested in tackling the project, here are a few things to consider before and during the build.

Pros

There are no kits or expensive parts to buy. Everything is open source. The body of the robot is completely 3D printed. Matthew Hallberg, the Wire Beings creator, provides all of the STL files on his website to download for free. Everything else you need can easily be found on EBay.

The whole thing is designed around an Arduino Uno, which directs the motor controller and controls the LEDs. If you’re Arduino-curious, this is a great first-step into that universe.

Assuming you already have access to a 3D printer, the whole bot can be built for somewhere between $50 and $75.

Cons

The frame is large and bulky. If you don’t already have access to a 3D printer, forget using a 3D printing service like Shapeways as you’ll easily spend over $1000 on printing alone. It’s cheaper to just buy a 3D printer.

A 9V battery is not really sufficient for this project. You’ll go through a lot of them once you get this thing up and running. The motors drain the battery fast. A good first enhancement would be to get the robot running off a LiPo. This may not be suitable for young kids though, as LiPos are dangerous.

Some of the frame pieces have little inner tabs that the screws drive into. They’re extremely delicate. Many of these will break and you’ll have to resort to super glue to keep things together.

Tips

Test your connections as you go. Once you get the motor leads connected to the motor controller, wire everything up and test connections immediately and continuously as you build. Otherwise, you chance getting something wrong and having to disassemble the robot in order to troubleshoot.

By wary of cheap Chinese 9V batteries. I bought a large pack that all show as full with a battery tester. As soon as I put a decent load across them, however, the voltage drops to around 5-6 volts. They can’t source enough power to drive the motors and the Arduino browns out a lot. I wasted a few bucks on these. Of course, once I popped in a fresh Duracell everything worked fine.

The frame design has a spot for a 9V battery, but I couldn’t for the life of me figure out how to change the battery without taking the whole robot apart. So I velcroed the battery holder on the back of the robot for easy access.

There appears to be a missing ground connection on the circuit diagram. You’ll need a ground wire coming off the Arduino Uno to the row of ground connections on the mini-breadboard.

I had some issues with the castors/spheres on the feet. At first I thought the spheres were too small because they didn’t fit snug into the castors. They’d fall right out. I then tried swapping in some 19.5mm steel balls. They fit well into the castors, but caused ground clearance problems with the wheels. I think maybe I screwed something up on the castor prints. It could have been due to bad infill settings. I’m not entirely sure. So I decided to forgo the spheres/balls altogether and stick some felt pads to the bottom of the feet. Those work fine so long as I only drive the robot around on smooth floors.

If you’re interested in adding servos for neck, arm, and antenna control or voice control, see the comments on the Instructables page. There’s some good information in there.

Conclusion

This project provides a great introduction to electronics and mechanical design. It also leaves a lot of room for improvement. And that’s a good thing! Get creative and have fun with it.

-Shane

Modern C++ and the Weight of Progress

Recent trip reports (1,2) from the February/March C++ Standard Committee meeting revealed a few details concerning the upcoming C++17 standard. It looks like a number of features, including modules, concepts, ranges, and coroutines won’t be making it in. If you’ve paid attention at all to the C++ community over the past year or two, you’ll know that these were some of the things that folks were most excited about. For a long while, there was a sense that these features were a done deal. They garnered a lot of buzz even before C++14’s paint dried. Talks have been given on them. Blogs have been written about them. Compiler vendors jumped on the bandwagon and started releasing early implementations for community review. The C++ train has had a lot of momentum, so the expectations were high. And now I suspect that many C++ aficionados are feeling a tad bit jilted.

Truth is – I’m kind of relieved.

We’ve come a long way since C++98. There have been significant improvements to the language. I can’t deny that. But with the good comes the bad, or at the very least the not-so-great. Every time a new standard is released, we get more cruft, more weird keywords, and more things that don’t feel like C++ (You thought the square bracket lambda syntax was weird? Wait until you get a load of the annotations coming in C++17!). With every new standard, the learning curve gets a bit steeper.

A couple of years ago, Mike Acton made the offhand remark in his CppCon 2014 talk “Data-Oriented Design and C++”(23:35), “I can just imagine this meeting tonight on, you know, what else can the C++ committee add to the fucking lang, er, add to the language to make it solve our problems for us, right?” It was funny. I laughed. And I totally agreed with the spirit of what he was saying.

The C++ Standards Committee has, as a matter of principle, strived to maintain backwards compatibility with each iteration of the C++ standard. It’s an honorable goal, and one I think is important. Certainly, some of the largest and oldest active codebases in the world are written in C++. So for many, breaking language changes would be a non-starter. But how do you evolve a language and keep its complexity manageable without removing something? Perhaps you can’t.

Scott Meyers suggested in CppCast Episode #26 that maybe it’s time to finally remove obsolete language features. It’s an interesting idea. But it should send a shiver down the spine of any developer who’s had to maintain a large, legacy codebase. Add in the need to support multiple platforms and compilers, things get even scarier. It’s a path rife with compiler divergence and inconsistencies. Maintaining code would only get harder. It’s a direction that I think is unpalatable for most. Not to mention at what point is C++ no longer C++?

So time will march on and C++ will continue to have, as it always has, a reputation for being complicated. Since C++11, a new standard has been released every three years. Herb Sutter’s C++17 trip report mentions the committee is considering shortening the release cycle to two years, promising bigger, better, faster, stronger. And messier.

I’m slightly discouraged by the whole thing. In an era when it’s common to build applications using a heterogeneous assortment of technologies, why does C++ feel the need to become everyone’s everything language?

Engineers are in the business of getting things done. We strive for elegant, simple solutions that clearly communicate our ideas and that are easy to maintain. For C++ developers, it’s unfortunate that the complexity of our tool is overshadowing the work we do. Most folks don’t have the time and energy to keep up with the language changes. Those folks are in the trenches, hard at work building real applications. The irony here, of course, is that these are the very folks the latest and greatest language features were intended to help.