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.
Daughter boards for microcontroller systems, whether they are shields, hats, feathers, capes, or whatever, are a convenient way to add sensors and controllers. Well, most of the time they are until challenges arise trying to stack multiple boards. Then you find the board you want to be mid-stack doesn’t have stackable headers, the top LCD board blocks the RF from a lower board, and extra headers are needed to provide clearance for the cabling to the servos, motors, and inputs. Then you find some boards try to use the pins for different purposes. Software gets into the act when support libraries want to use the same timer or other resources for different purposes. It can become a mess.
The alternative is to unstack the stack and use external boards. I took this approach in 2013 for a robotics competition. The computer on the robots was an ITX system which precluded using daughter boards, and USB ports were my interface of choice. I used a servo controller and two motor controllers from Pololu. They are still available and I’m using them on a rebuild, this time using the Raspberry Pi as the brain. USB isn’t the only option, though. A quick search found boards at Adafruit, Robotshop, and Sparkfun that use I2C.
This approach has challenges and benefits. A stack of daughter boards makes a neat package, where external boards makes a tangle of wires. Random sizes can make mounting a challenge. Providing power can also be a hassle because of the random placement of power pins. You can’t rely on USB power, especially from a Raspberry Pi whose USB is power limited.
On the other hand, external boards can offload processing from your main processor. Once a command is sent, these boards handle all the details including refresh requirements. They are likely to provide capabilities beyond the microcontroller software libraries since their processors are dedicated to the task.
I am using an 18-channel board from the Pololu Maestro Servo Controller family of boards that control from 6 to 24 servos using a single board. You might find the Adafruit 16 channel I2C board a useful alternative. For motor control I turned to the Pololu Simple Motor Controller family using one that will handle 18 amps. Others will handle from 7 to 25 amps. Or consider the Sparkfun Serial Controlled Motor Driver. Another source for USB controllers is Phidgets. I experimented with one of their spatial devices for the original robot. I should have used it to measure the tilt since one of my robots rolled over on a hill. Ooops!
The board currently installed on my robot is the Mini Maestro 18. The Maestro provides control over the servo speed, acceleration and movement limits. A home position can be set for startup or when errors occur. You can even do scripting or set movement sequences to play on command.
On the hardware side, the Maestro also allows channels to be used for digital input or output, and some channels for analog input. On some there is one channel for pulse width modulation output. An onboard regulator converts the servo power input to the voltage needed by the processor, simplifying part of the power distribution challenge.
My previous robot used the Maestro to control pan and tilt servos for camera positioning, a servo to lift samples from the ground, and a safety LED. Two analog inputs from current sensors on the motors helped avoid burnout during stalls, and four inputs from a simple RF key fob transmitter provided control. The latter came in handy for testing. I’d program a test sequence such as starting a 360° camera scan for landmarks or drive onto the starting platform and drop the sample. A button press on the key fob would initiate the activity. One button was always set up as an emergency halt to stop a rampaging robot. The rebuild is following this pattern with some additions.
The two Simple Motor Controllers (SMC) each handled the three motors on either side of the Wild Thumper chassis. The SMC does more than just control the motor speed and direction. You can set acceleration, braking, and whether forward and reverse operate at the same or different speeds. The board monitors a number of error conditions for safety. These stop the motor and prohibit movement until cleared. Such blocking errors include lost communications, low input voltage, or drivers overheating.
An additional capability I found extremely helpful is the ability to read signals from a radio control (RC) receiver. These signals can be used to control the motor and, with some cross wiring between two controllers, provide differential drive control. This is useful for driving the robot to a new location using an RC transmitter. I didn’t use the RC inputs directly. Instead I read the RC inputs and issued the control commands from my program. This let me monitor the speed in my program logs for correlation with the other logged data. I also used an input to command the robot into autonomous or RC control operations. There are also two analog inputs that can be used to directly control the motor and can be read through commands.
USB ports were my choice for communications but there is also a TTL level serial port with the standard RX and TX pins. This port can be used by the Raspberry Pi, Arduino, or any other microcontroller that has a TTL serial port.
The Maestro boards using USB appear as two serial ports. One is the command port that communications with the Maestro processor. The other is a TTL port. This port can serve as simply a USB to TTL serial port converter to allow communications with other boards, even from another vendor. Another use of the TTL port is to daisy chain Pololu boards. I could attach the SMC boards in this manner and save two USB ports for other devices. These boards support this by having a TXIN pin that ANDs the TX signal from the connected board with the TX on the board.
Both of these controllers support a few different communications protocols. I use the one Pololu created and is available on some of their other products. The command details are different between the boards, but the basic command structure is the same. They call it their binary protocol, and the basic format follows:
All the fields are single bytes except for the data field which is frequently 2 bytes to transmit 16-bit data. The returned data is only one or two bytes with no additional formatting. Note they provide for detecting errors in the message by using a CRC (cyclical redundancy check). This is probably not critical over USB but a TTL line might receive noise from motors, servos, and other devices. A CRC error sets a bit in the error register that can be read if the command is critical.
I wrote my own code, C++ of course, for the PC and converted it just now to the Raspberry Pi. The main change is the different serial port code needed by Linux and Windows. Pololu now provides Arduino source for the protocol making it easy to use these boards with that family of controller boards.
The chassis, Pi, and these boards are now installed on the Wild Thumper chassis along with a pan and tilt controlled by servos. A safety LED is on when power is applied and flashes when the robot is actively controlling the system. A LiPo battery powers all but the Pi because I need to configure a battery eliminator circuit to provide five volts. I’m powering it temporarily using a USB battery pack.
A test program, cross compiled from my desktop, moves the robot forward, pivots left than right, and then reverses. The pan / tilt moves and the LED flashes. I originally used a web camera for vision processing but will switch to the Pi camera since it is better. The Neato lidar discussed in a previous article will soon find a place onboard, along with an accelerometer to detect possible rollovers.
I’m sure I could have done this using Pi daughter boards despite the challenges I mentioned earlier. There are trade-offs to both approaches that need to be considered when working on a project. But there is one final advantage to the external boards: they have a lot of twinkly LEDs.