While initially developed for use in large factory processes, computer numeric control (CNC) machines have slowly made their way out of the factory and into the hands of virtually anyone who wants one. The versatility that these machines have in automating and manipulating a wide range of tools while at the same time maintaining a high degree of accuracy and repeatability is invaluable in any setting. As an illustration of how accessible CNC has become, [Arnab]’s drawing robot uses widely available tools and a CNC implementation virtually anyone could build on their own.
Based on an Arudino UNO and a special CNC-oriented shield, the drawing robot is able to execute G code for its artistic creations. The robot is capable of drawing on most flat surfaces, and can use almost any writing implement that will fit on the arm, from pencils to pens to brushes. Since the software and hardware are both open source, this makes for an ideal platform on which to build any other CNC machines as well.
A self-balancing robot is a great way to get introduced to control theory and robotics in general. The ability for a robot to sense its position and its current set of circumstances and then to make a proportional response to accomplish its goal is key to all robotics. While hobby robots might use cheap servos or brushed motors, for any more advanced balancing robot you might want to reach for a brushless DC motor and a new fully open-source controller.
The main problem with brushless DC motors is that they don’t perform very well at low velocities. To combat this downside, there are a large number of specialized controllers on the market that can help mitigate their behavior. Until now, all of these controllers have been locked down and proprietary. SmoothControl is looking to create a fully open source design for these motors, and they look like they have a pretty good start. The controller is designed to run on the ubiquitous ATmega32U4 with an open source 3-phase driver board. They are currently using these boards with two specific motors but plan to also support more motors as the project grows.
Animatronics for movies is often about making something that works and is reliable in the short term. It doesn’t have to be pretty, it doesn’t have to last forever. [Corporate Sellout] shows us the minimalist approach to building animatronics with this pair of special eyes. These eyes move in both the pan and tilt. Usually, that means a gimbal style mount. Not in this case. The mechanical assembly consists of with popsicle sticks, ping-pong balls, film canisters and dental floss.
The frame for the eyes is made of simple popsicle sticks hot glued together. The eyes themselves are simple ping-pong balls. Arduino powered servos control the movement. The servos are connected to dental floss in a cable arrangement known as a pull-pull system. As each servo moves, one side of the arm pulls on a cable, while the other provides enough slack for the ping-pong ball to move.
Mounting the ping-pong balls is the genius part of this build. They simply sit in the open end of a couple of film canisters. the tension from the dental floss holds everything together. We’re sure it was a finicky setup to build, but once working, it’s reliable. Only a glue joint failure or stretch in the dental floss could cause issues.
There are plenty of approaches to Animatronic eyes. Check out the eyes in this Stargate Horus helmet, which just won our Sci-Fi contest. More recently we saw Gawkerbot, which uses a CD-ROM drive to provide motion for a creepy robot’s eyes.
We love to see projects undertaken for the pure joy of building something new, but to be honest those builds are a dime a dozen around here. So when we see a great build that also aims to enhance productivity and push an entrepreneurial effort along, like this automated small parts counter, we sit up and take notice.
The necessity that birthed this invention is [Ryan Bates’] business of building DIY arcade game kits. The mini consoles seen in the video below are pretty slick, but kitting the nuts, bolts, spacers, and other bits together to ship out orders was an exercise in tedium. Sure, parts counting scales are a thing, but that’s hardly a walk-away solution. So with the help of some laser-cut gears and a couple of steppers, [Ryan] built a pretty capable little parts counter.
The interchangeable feed gears have holes sized to move specific parts up from a hopper to a chute. A photointerrupter counts the parts as they fall into plastic cups on an 8-position carousel, ready for bagging. [Ryan] also has a manual counter for wire crimp connectors that’s just begging to be automated, and we can see plenty of ways to leverage both solutions as he builds out his kitting system.
While we’ve seen more than a few candy sorting machines lately, it’s great to see someone building hardware to streamline the move from hobby to business like this. We’re looking forward to seeing where [Ryan] takes this from here.
There are many designs for little two-wheeled robots available to download for constructors with an interest in simple robotics. You might even think there are so many that there could not possibly be room for another, but that has not deterred [Rob Miles]. He’s created HullPixelBot, a platform for a mobile pixel as well as for simple robotic experimentation.
So what makes HullPixelBot more than just Yet Another Arduino Powered Robot? For a start, it’s extremely well designed, and has a budget of less than £10 ($12.50). But the real reason to take notice lies in the comprehensive software, which packs in a language interpreter and MQTT endpoint for talking to an Azure IoT hub. This is much more than a simple Arduino bot on which you must craft your own sketches, instead, it is a platform for which the Arduino bot is merely the carrier.
The project has had quite a while to mature since its initial release, and now has the option of a single pixel or a ring of pixels. The eventual aim is to use swarms of networked HullPixelBots to create large autonomous moving pixel displays, containing more than a hundred individual pixels.
There is an early video of some PixelBots in action which we’ve placed below the break, but it serves more as eye candy than anything else. If you have a spare ten quid, download and print yourself a chassis, install Arduino and motors, and have a go yourself!
… I had a cheap Chinese drone that was broken, but its camera seemed to be operating and when I took apart my drone I found a small WiFi chip with a video transmitter. I (decided) that I will use this little circuit for a project and I started to buy and salvage the parts.
Being a tracked robot, it can negotiate most types of terrain and climb hills up to 40 degrees. It is powered by two 18650 lithium-ion batteries with a capacity of 2600 mAh and the remote control is based on the HC-12 serial communication module. You can control it with a joystick and watch the camera’s live-stream in a virtual reality glass. That’s pretty neat but it’s not all.
[Imetomi] also used a hacked Nacomimi Brainwave Toy to make a brain controlled version of his robot. The brainwaves are detected using sensors placed on the scalp. To actually control it the operator has to focus on the right hand to move right, focus on the left hand to move left, blink to move forward and blink again to stop. There is also an ultrasonic sensor to help navigation so the robot doesn’t bump into things. It’s not very precise but you can always build the joystick version or, even better, make a version with both controls.
The Otto DIY robot has just taken first place in the coveted role as “best robot to 3D print for your (inner) child”. It’s cute, it dances, it doesn’t cost too much, it’s completely open source, and it’s not impossible to write code for. It’s probably the most refined Bob design that we’ve seen yet. Watch it move in the video below.
We fell in love with the Bob robot when we first saw it, and we apparently weren’t alone. There have been a ton of Bob-clones that have refined the basic design. And until Otto, the Spanish Zowi was the coolest that we’d ever seen.
Why is Otto so cool? They’ve tweaked the design so that, with the exception of some fiddly servo screws, everything just snaps together. The printed parts fit easily on a single RepRap bed, so you can practically churn them out. And the rest consists of very cheap commodity parts that you can easily source online. If four hobby servos cost $20, you could get the whole bot done for around $40.
Since this is a Bob clone, the firmware is approximately compatible with the Zowi. Indeed, there have already been people who’ve run Zowi firmware on the Otto (YouTube), adding Bluetooth to make use of Zowi’s cell-phone remote control. Besides the cute-factor, one of the strongest reasons to build yourself a Bob-style robot is the growing code ecosystem, both around Otto and Zowi. So don’t just sit there, get printing and contribute!
Imagine trying to make a ball-shaped robot that rolls in any direction but with a head that stays on. When I saw the BB-8 droid doing just that in the first Star Wars: The Force Awakens trailer, it was an interesting engineering challenge that I couldn’t resist. All the details for how I made it would fill a book, so here are the highlights: the problems I ran into, how I solved them and what I learned.
The Design Criteria: Portable and Inexpensive
I had two design criteria in mind. The first was to keep it low-cost. Some spend $1000 to $1500 on their BB-8s. I wanted to spend as little as I could, so as many parts as possible had to come from my existing stock and from online classifieds and thrift stores. Not counting the parts that were discarded along the way, the cost came in just shy of $300.
The second design criteria was to make it portable. It had to be something I could take on the bus or carry while walking a reasonable distance (I once carried it twenty-five minutes to a nearby school).
Both of these criteria meant that it had to be smaller than full size. A full size ball is 20″ in diameter. Mine has a 12″ ball which makes it 3/5 scale. Also, the larger it is, the more powerful and costly the motors, batteries, motor controllers, magnets, and so on.
Version One: Quick And Easy
First I tried a minimalist approach. For the ball, I found my 12″ cardboard globe on kijiji.ca. I bought an RC toy truck at a yard sale and attached a pole to it for holding magnets near the top of the globe. I then made a head with corresponding magnets under it. The head magnets attract to the pole magnets, keeping the head on. Meanwhile, the truck rolling inside the ball makes the ball move.
Making the ball roll around was easy. Making it roll around while keeping the head on was very hard. The magnets at the top of the pole attract the magnets under the head, pulling them down hard onto the surface of the globe. That essentially glues the truck to the top of the globe.
To overcome that the truck needs sufficient traction. That also means the truck needs to be heavy. And lastly, the truck’s motor needs to be powerful enough to overcome its own weight and the grip of the magnets on the ball. The alternative is to make the magnetic attraction weaker, but if it’s too weak the head falls off. It’s a tricky balancing act, in both senses of the word.
But the most dome-like head I could make stay on was just a cardboard skeleton. Anything more filled out would be heavier and require a stronger magnetic attraction. The toy truck’s motor would not be up to it.
Version Two: Drill Motors And Drill Batteries
For more powerful motors and more mass I figured I could kill two birds with one stone by going with drill motors and drill batteries in a hamster drive configuration. Using drill parts kept costs down as the batteries and one drill came from yard sales while the other drill was free through freecycle.org. Meanwhile, both are heavy.
To make sure it all fit, I drew up a 3D model in Blender, the free 3D modelling and animation software that I use a lot. In fact, finding out how to make the batteries and motors fit was the first step. They had to be as low as possible. Their large mass low down is what keeps the droid vertical, with the much lighter head at the highest point.
The drill batteries had to be easily removable for recharging. To hold them under the drive plate I simply used Velcro. Meanwhile, the drill battery stems went up through a hole in the drive plate. I made a connector to electrically connect to the battery terminals. It is a plastic rectangle with thin copper sheet metal for the contacts. Once the battery was Velcroed in place, this plastic and metal piece was lowered down onto the stem, the copper metal making contact with the battery terminals.
For the brains I used an Arduino UNO. To drive the motors I had all the parts for making two H-bridge driver boards, with the exception of 4 MOSFETs and some fuses. The Arduino does pulse width modulation (PWM) to the driver boards for speed control, as well as playing sounds at certain times when the motors are turned on.
For remote control, I hacked the RC receiver from the toy truck and added an extra set of AA batteries in parallel for more runtime. A problem I ran into right away though, was that the RC receiver put out voltages of both polarities based on which direction the motors should rotate, whereas the Arduino’s pins take only positive voltages. To solve that I came up with a converter board to go between them.
Getting all that to work reliably took a while. Before I added fuses, I burned a few MOSFETs. At one point I’d put an N-type MOSFET where a P-type should have gone and vice versa. That resulting problem alone took a few days of spare time to figure out.
The wheels were old Rollerblade wheels — I keep a small bucket of these in my shop. I decided I wanted the ball to roll at around 1 foot per second and doing the math, that meant the wheels would have to rotate at around 2 rotations per second or 120 RPM. I found a PWM value that would give something close to that and started blowing fuses. I started with 1 amp fuses, then 2, 5, and finally settled on 10 amp fuses.
My final hurdle was that the motors would behave oddly when the motors were told to turn in opposite directions but were fine when they were told to turn in the same direction. This turned out to be a bad assumption on my part about how the RC receiver was wired internally — none of the output wires were common inside. After some changes to the circuit, I now had stable electronics.
I had basically been treating the RC receiver as a black box, but when I asked for help about my converter board here on Hackaday, it was pointed out that the receiver likely contained H bridges. Opening it up, that’s exactly what I found. The converter board works fine for now, but in the near further I’ll use one of the suggestions from that Hackaday post to eliminate the board altogether. I might even try all of the suggestions, just for fun.
The Drive System
The motors were too long to fit in line between the wheels and so had to be mounted off to the sides. To transfer rotation to the wheels, I drew up some gears in Blender and 3D printed them at our local University of Ottawa Makerspace. In the print settings I used 2 shells and only 50% infill. The gears are held firmly onto the shafts solely using nuts and washers on either side. They’ve held up amazingly well, even with slipping and grinding during development.
For the bearings for the center gears and the wheels I used an old trick of making bearing blocks from hardwood.
I wanted to keep as much room as possible on the drive plate available for adding things later and so initially I’d mounted the motors at only three points. But this allowed the motors to move a little causing the gears to slip. To fix that I later added a fourth mounting point and haven’t had any slipping since.
At the end of the shaft for the drill motors is a hole that a screw goes into. That’s part of how the chuck is kept on a drill motor, and that’s how one gear was kept on. However, this screw had a tendency to get loose. Putting a little Loctite on the threads fixed that.
Given that I was trying to fit a lot in a small droid, I had to mount some things higher than I’d have liked to. When the droid stops, mass high up causes the droid to wobble. In the BB-8 droid used for promotional events they’ve gone to a great extent to keep the majority of the mass as low as possible. Originally I had the Arduino batteries and the RC receiver with its extra batteries fairly high up. I later mounted them much lower. When holding the internals in my hands I could tell the difference but it didn’t make a noticeable difference with the wobble.
Instead, for that I added Adafruit’s BNO055 inertial measurement unit (IMU) board. With it I could tell what angle the droid was at when stopping and experimented with PID loops and other algorithms of my own to minimize wobble. That helped.
As I said, I used a 12″ cardboard globe. To increase the traction of the wheels inside the globe I sprayed the globe’s interior with an anti-slip spray from a hardware store. This made a huge difference. However, over time the anti-slip coating vanished, and so I’m looking for another, more permanent coating, perhaps urethane or something. If anyone has any suggestions, please let me know in the comments. It also has to stop off-gassing eventually. The anti-slip spray had an odor for a long time.
But the main problem with the cardboard globe was its thinness. With the huge weight of the internals pushing down on it where the wheels are, it warped significantly and required a lot of effort and a copious amount of tape to keep the two hemispheres together. This large amount of tape also made an uneven ridge for the head to slide over, making it get stuck. At that point either the drive system continued to move while the head fell off or the drive system couldn’t move at all.
The solution was to carefully coat a new globe in three layers of fiberglass. I took my time doing this, over a month and a half, applying one piece at a time and then sanding before putting the next piece. The result was a fantastic improvement. It no longer deformed and now it takes a minimal effort to attach the two hemispheres with only eight narrow strips of transparent duct tape.
The Never-ending Saga
My BB-8 is now at the point that I can call it finished. At least it’s finished as far as all the engineering is concerned, and that’s usually where I call it quits.
While the paint job worked out well, up close you can see that the details are painted on. It’d be nice to have at least the lines on the head be actual grooves. Also, these drill motors are brushed motors and I’ve since learned that doing high frequency PWM to brushed motors damages them over time. I’d like to replace them with brushless motors. And as anyone who’s use cordless drills a lot knows, drill batteries don’t last long, and so it’d be great to switch to LiPos.
But for now, the reactions I get from both kids and adults is beyond my wildest expectations. Kids threat it like a friend while adults have petted it and called to it like it was a baby or a dog wagging its tail. I’d call that a success.
In a time when we’re inundated with talk of an impending AI apocalypse it’s nice to see an AI that’s intentionally useless. That AI is HAL 9000. No, not the conflicted HAL from the movie 2001: A Space Odyssey but the World’s Biggest AI Useless Machine HAL built by [Rafael], [Mickey] and [Eyal] for GeekCon 2016 in Israel.
Standing tall, shiny and black, the box it’s housed in reminds us a bit of the monolith from the movie. But, in a watchful position near the top is HAL’s red eye. As we approach, HAL’s voice from the movie speaks to us asking “Just what do you think you’re doing, Dave?” as the eye changes diameter in keeping with the speech’s amplitude. And at the bottom is a bright, yellow lever marked ON, which of course we just have to turn off. When we do, a panel opens up below it and a rod extends upward to turn the lever back to the ON position.
Behind the scenes are two Arduinos. One Arduino manages servos for the panel and rod as well as playing random clips of HAL from the movie. The other Arduino uses the Arduino TVout library to output to a projector that sits behind the red diffuser that is the eye. That Arduino also takes input from a microphone and based on the amplitude, has the projector project a white circle of corresponding diameter, making the eye’s appearance change. You can see all this in action in the video after the break.
[Ken Rumer] bought a new house. It came with a troublingly complex pool system. It had solar heating. It had gas heating. Electricity was involved somehow. It had timers and gadgets. Sand could be fed into one end and clean water came out the other. There was even a spa thrown into the mix.
Needless to say, within the first few months of owning their very own chemical plant they ran into some near meltdowns. They managed to heat the pool with 250 dollars of gas in a day. They managed to drain the spa entirely into the pool, but thankfully never managed the reverse. [Ken] knew something had to change. It didn’t hurt that it seemed like a fun challenge.
The first step was to tear out as much of the old control system as could be spared. An old synchronous motor timer’s chlorine rusted guts were ripped out. The solar controler was next to be sent to its final resting place. The manual valves were all replaced with fancy new ones.
Rather than risk his fallible human state draining the pool into the downstairs toilet, he’d add a robot’s cold logical gatekeeping in order to protect house and home. It was a simple matter of involving the usual suspects. Raspberry Pi and Arduino Man collaborated on the controls. Import relay boards danced to their commands. A small suite of sensors lent their aid.
Now as the soon-to-be autumn sun sets, the pool begins to cool and the spa begins to heat automatically. The children are put to bed, tired from a fun day at the pool, and [Ken] gets to lounge in his spa; watching the distant twinkling of lights on his backyard industrial complex.