Some time ago my friend Mauro Alfieri showed me an interesting development board produced by DFRobot and called Bluno Beetle (now Beetle Ble). It seemed the perfect board to start “playing” with the Bluetooth Low Energy (BLE) technology; therefore I ordered one board directly from the DFRobot store.
I expected to receive the usual anonymous parcel with the board inside an antistatic plastic bag; DFRobot instead sends its products in an elegant cardboard box, protecting them with foam:
Bluno Beetle is really small and therefore perfect for wearable projects:
But what is it? Simplifying is a board, Arduino Uno compatible (it hosts the ATmega328P microcontroller) to which has been added the CC2540 chip from Texas Instruments to act as USB and BLE controller. The two chips communicate via a serial interface:
The CC2540 chip is actually a real microcontroller that runs a firmwaredeveloped by DFRobot. This firmware can be configured using AT commands. Normally the firmware runs in transparent mode, that is it acts as a “bridge” between the USB/BLE interfaces and the ATmega microcontroller. If you then connect the Bluno to your PC and activate the serial monitor, each character you type is forwarded to the ATmega and viceversa.
To send AT commands, first you have to enter the AT mode of the firmware, sending the + character 3 times (without appending a line ending). The firmware confirms the new mode with the sentence “Enter AT Mode”:
Now you can send the commands, appending the Windows line terminator (CRLF). For example to display the firmware version:
To exit the AT mode and go back to transparent mode, you have to send the AT+EXIT command.
It may happen that – if it’s the first time you connect the Bluno Beetle to your Windows PC – it is not correctly recognized:
The correct drivers are shipped with the Arduino IDE. You only need to do a manual installation specifying the path where you installed the IDE:
Windows will identify the new device as an Arduino Uno:
As explained above, if the firmware running on the CC2540 chip is in transparent mode, using the USB connection you can talk directly to the ATmega328P microcontroller. This means that you can program the microcontroller using the Arduino IDE without any problems… just choose Arduino Uno as board and select the correct serial port:
BLE and transparent mode
In transparent mode Bluno transmits via BLE each byte it receives from Arduino (the ATmega microcontroller) and – viceversa – it sends to Arduino each byte it receives from BLE.
In this first post let’s explore the demo application DFRobot provides; in a future post I’ll explain how to develop your application to interact with Bluno Beetle via BLE.
If you have an Android smartphone, you can directly install the apk file for the application named BlunoBasicDemo (application of which the source code is also available). In the same Github repository you can also find the source code of the iOS application, you have to compile by yourself.
Compile and upload the following sketch on the board:
The sketch reads the incoming bytes (coming from the app) and sends back to the app their hexadecimal value. Every 10 seconds moreover the sketch sends to the app the text Hello world!.
Launch the app. After having clicked on the Scan button, you can choose your Bluno board from the list of detected devices:
Every 10 seconds you should see a new HelloWorld! string appear. You can try to send a character (for example the letter “a”); you’ll receive an answer from Arduino (0x61 is indeed the hex code – in the ASCII table – for the letter “a”):
Bluno also supports the HID (Human Interface Device) mode. When running in this mode, Bluno simulates an input peripheral (keyboard, mouse…) connected via BLE.
The AT command that enables this mode is:
After having enabled the HID mode, you can send one or more “keys” with:
you can send up to 3 different keys at a time, concatenating their codes with the + character. The codes to be used, according to the type (page) of the HID device, are listed in the USB specification.
The AT+KEY command notifies the pressure of a key on the keyboard. It is therefore necessary, after a few moments, to send the AT+KEY=0 command to indicate that the key has been released; otherwise on the PC associated with Bluno you’ll see the character appear repeatedly!
Using two different AT commands you can enable the debug mode of the firmware. This mode allows to receive – via the USB connection – a copy of all the data sent and received through the BLE connection.
The two commands are:
AT+BLUNODEBUG=ON (copies the messages sent by the ATmega)
AT+USBDEBUG=ON (copies the messages received from BLE)
By default the first debug mode is active, while the second is disabled. You can verify it if you upload the sketch listed above: in the serial monitor you’ll see the Hello World! sentences but not the characters sent by the app.
This project implements a Knight Rider / Rainbow effect Random Selector.
It uses an Arduino UNO and a WS2812B RGB led strip.
A friend of mine needs a random selector for train scale model.
I’ve developed this using the Arduino framework, because he would like to modify the sketch “the Arduino way”.
Unluckly I have not any picture or video of his build. So I’ve built a dice selector by using an old clock frame. I would like to thank my friend Matteo for cutting vinyls out for this project.
Barton Dring has a nice build log on his Line-us clone project:
I have been going to the monthly Amp Hour, Hardware Happy Hour meetup. A lot of people bring something to show. My projects are too big. Also, you need to bring your own power. The meetup standard seems to be running off a USB cord. I was brainstorming ideas, when I saw the Line-us project on Kickstarter. It looked like the perfect size and power. I also love the challenge of non linear kinematics.
To keep hackers fueled and hacking, why not hack a coffee maker into a coffee brewing robot? [Carter Hurd] and [David Frank] did just that at The Ohio State’s Hack OHI/O 24 hour Hackathon. They even won the “Best Hardware Hack”. The video below shows it in action but the guys sent us some extra details on how it’s made.
To give it a voice they put Alexa on a Raspberry Pi. Using an audio splitter they have the voice go both to a speaker and to an Arduino. The Arduino then uses the amplitude of the audio signal’s positive values to determine how much to open the “mouth”, the coffee maker’s hinged cover. As is usually the case, there’s some lag, but the result is still quite good.
The brewing is also controlled by the Arduino. They plan to add voice control so that they can simply ask, “Alexa, make me coffee”, but for now they added a switch on the side to start the brewing. That switch tells the Arduino to work one servo to open the cover, another to insert a coffee filter, and two more to scoop up some coffee from a container and dump it into the filter.
They replaced the coffee maker’s on/off switch with a relay so that after the Arduino closes the cover again, it uses the relay to start the brewing. The result is surprisingly human-like. We especially like the graceful movement achieved by the two servos for scooping up and dumping the coffee. Full disclosure: they did admit that it would often either not scoop enough coffee or scoop enough but spill a bunch on the group.
It’s the most wonderful time of the year! No, we’re not talking about the holiday season, although that certainly has its merits. What we mean is that it’s time for the final projects from [Bruce Land]’s ECE4760 class. With the giving spirit and their mothers in mind, [Adarsh], [Timon], and [Cameron] made a programmable lock box with four-factor authentication. That’s three factors more secure than your average Las Vegas hotel room safe, and with a display to boot.
Getting into this box starts with a four-digit code on a number pad. If it’s incorrect, the display will say so. Put in the right code and the system will wait four seconds for the next step, which involves three potentiometers. These are tuned to the correct value with a leeway of +/- 30. After another four-second wait, it’s on to the piezo-based knock detector, which listens for the right pattern. Finally, a fingerprint scanner makes sure that anyone who wants into this box had better plan ahead.
This project is based on Microchip’s PIC32-based Microstick II, which [Professor Land] starting teaching in 2015. It also uses an Arduino Uno to handle the fingerprint scanner. The team has marketability in mind for this project, and in the video after the break, they walk through the factory settings and user customization.
The WS2812 is an amazing piece of technology. 30 years ago, high brightness LEDs didn’t even exist yet. Now, you can score RGB LEDs that even take all the hard work out of controlling and addressing them! But as ever, we can do better.
Riffing on the ever popular Adafruit NeoPixel library, [Harm] created the WS2812FX library. The library has a whole laundry list of effects to run on your blinkenlights – from the exciting Hyper Sparkle to the calming Breathe inspired by Apple devices. The fantastic thing about this library is that it can greatly shorten development time of your garden-variety blinkables – hook up your WS2812s, pick your effect, and you’re done.
[Harm]’s gone and done the hard yards, porting this to a bevy of platforms – testing it on the Arduino Nano, Uno, Micro and ESP8266. As a proof of concept, they’ve also put together a great demonstration of the software – building some cute and stylish Christmas decorations from wood, aluminium, and hacked up Christmas light housings. Combining it with an ESP8266 & an app, the effects can be controlled from a smartphone over WiFi. The assembly video on YouTube shows the build process, using screws and nails to create an attractive frame using aluminium sheet.
This project is a great example of how libraries and modern hardware allow us to stand on the shoulders of giants. It’s quicker than ever to build amazingly capable projects with more LEDs than ever. Over the years we’ve seen plenty great WS2812 projects, like this sunrise alarm clock or this portable rave staff.
As always, blink hard, or go home. Video after the break.
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.
At its heart is an Arduino Uno and an Adafruit Motor Shield v2. The green laser is turned on and off by the Arduino through a transistor. But the part that makes this really a fun machine to watch at work are the two stepper motors and two mirrors that reflect the laser in the X and Y directions. The mirrors are rectangles cut from a hard disk platter, which if you’ve ever seen one, is very reflective. The servos tilt the mirrors at high speed, fast enough to make the resulting projection on the wall appear almost a solid shape, depending on the image.
He’s even written a Windows application (in C#) for remotely controlling the projector through bluetooth. From its interface you can select from around sixteen predefined shapes, including a what looks like a cat head, a heart, a person and various geometric objects and line configurations.
There is a sort of curving of the lines wherever the image consists of two lines forming an angle, as if the steppers are having trouble with momentum, but that’s probably to be expected given that they’re steppers controlling relatively large mirrors. Or maybe it’s due to twist in the connection between motor shaft and mirror? Check out the video after the break and let us know what you think.
The video’s in three parts: looking at the laser beams in action as you’d see them on a dance floor, then watching the projected images while looking at an insert of the Windows application, and then watching the steppers and mirror doing their rapid movements.
This project completes the series of my articles about the Arduino analog I/O with the aim to use it as a controller of small automation systems.
In control systems of the industrial plants it is always advisable to isolate both the inputs and the outputs coming from the field. This prevents disturbances caused by power surges, lightning strikes or other EMI sources and also by ground potential differences.
Arduino Uno, or systems based on the ATmega328 chip has no a true analog output, but it may be realized using a PWM output averaged with a low-pass filter.
The use of an averaged PWM signal with 8-bit setting is not comparable with a real DAC, but in the insulation case presents undoubted advantages of simplicity since it is sufficient to use an optocoupler for isolating the PWM digital signal. Recently I designed another circuit to generate a 4-20 mA current with Arduino, that experience gave me the idea for this new project.
Yahya Tawil over at All About Circuits has published an article on Arduino UNO’s electronic design and better understanding of its hardware:
This article explains how Arduino works from an electronic design perspective.
Most articles explain the software of Arduinos. However, understanding hardware design helps you to make the next step in the Arduino journey. A good grasp of the electronic design of your Arduino hardware will help you learn how to embed an Arduino in the design of a final product, including what to keep and what to omit from your original design.