Off-The-Shelf Hacker: Ygor Hand Me That BeagleBone
While mulling over the audio/text-to-jaw synchronization challenges and being able to run Hedley the robotic skull on portable power, it hit me… Why not use a BeagleBone Black board, in place of the Raspberry Pi 3?
Why not indeed? The BeagleBone has a number of features that lend themselves to supporting an effective brain transplant, for Hedley:
- Debian Linux (for the ARM platform) runs from a 4GB on-board flash-storage module, as the default. You can boot and run Linux from a micro-SD card or a USB stick as an option. Boot-up takes about twenty seconds.
- The board is powered from a USB cable or a barrel connector if you don’t want to go the USB route.
- When the USB cable is plugged into a Linux notebook, it automatically creates a network connection over USB and you can ssh into the Bone from the notebook.
- The board has a ton of general purpose input/output (GPIO) pins.
- There are two built-in programmable real-time units (PRUs). These are sort of like a pair of Arduinos hooked up to the main processor. These might solve my flapping jaw-audio issues if I can figure out how to program them.
- It’s nowhere near as power hungry as a Raspberry Pi 3.
- Any board with “bone” in its name is a no-brainer, for a skull project and will make great material for our next conference tech-talk stand-up routine.
Let’s swap the BeagleBone Black in place of the Raspberry Pi 3 and see if it lives to be good… or descends rapidly into evil.
Uuwwaa-ha-ha-ha-haaaaaa!
Is the Patient Ready?
Replacing Hedley’s Raspberry Pi 3 with a BeagleBone Black board isn’t very difficult.
After powering everything down on the skull, I disconnected the Pi and put it aside. The bolt patterns are different on the Pi and the Bone, so I added a couple of new brackets to the micro-controller frame. It made sense to just cut a couple of pieces of 1/4-inch x 1/16-inch brass flat stock, solder them into place, then drill the holes to fit the BeagleBone. The old brackets were left in place in case I wanted to switch back to a Pi. Prototypes can usually tolerate a few extra parts.
One thing I do is use 4-inch x 3/4-inch long brass screws with very short lengths of bright green tubing, to mount and hold the boards to the brass frame. This technique saves a lot of time, over screwing everything together with nuts and washers. Just push the tubing down onto the screw with needle-nose pliers and you’re done.
Orienting the USB connector to the front made sense because I’ll occasionally run the skull hooked up to a Linux notebook and having it this way allows easy access. Also, I plan to plug in a barrel connector for power most of the time and will just run the wire along the base to the back. I’m not sure how often Hedley will be hooked up to a wired network, although it’s there if it’s needed.
On the back side are the micro-HDMI and USB 2.0 connectors. Since there’s only one USB port on the Bone, connecting to the JeVois sensor and using a wireless keyboard/mouse-pad required a USB hub. Hedley already had a hub bolted on the back, since the JeVois device needs two USB 2.0 ports for power. The wireless keyboard micro-fob doesn’t use much juice, so I just plugged it into the four-port hub. The other end of the hub cable connects into the USB port on the BeagleBone.
Also, the Raspberry Pi uses a full-sized HDMI connector at both ends. A micro-HDMI connector plugs into the Bone and uses a full-sized plug at the big-screen end. You needed both cables in your maker lab inventory anyway.
Different Brainwaves
There are slight differences in the software on the BeagleBone and the Raspberry Pi.
My BeagleBone Black is about three years old. As a consequence, it’s running a somewhat dated version of Debian Linux. For the purposes of our experiment, Hedley and I could live with that fact.
All I did was run ‘apt-get update’ and ‘apt-get upgrade’ to get the latest available version of the applications for this release of Debian. I didn’t spend much time tweaking Linux, because all we really need for Hedley’s skull pan function is a working version of guvcview.
Take the case of the latest version of guvcview on the Raspberry Pi and my Xubuntu Linux notebook. They were both at version 2.0.4. We were way back at version 1.5.3 on the BeagleBone.
This difference highlights one of the dirty little secrets of working in the Linux environment. With so many desktops choices, applications and hardware platforms, it’s inevitable that nobody runs exactly the same configuration within board families, Linux brands or even within vendors. It’s just a fact of the Linux lifestyle.
To me, this isn’t a huge problem, because Linux concepts are pretty universal. Usually, it’s just a matter of digging around in the details to find out what’s different between your version and another setup, then figure out what needs to be tweaked to fit your needs.
For example, the BeagleBone Debian version of guvcview didn’t have some of the features I had grown accustomed to in the very latest Raspberry Pi Raspian version of Linux.
One thing was that I couldn’t run guvcview from the command line without a graphical interface using the ‘-g’ option. While this isn’t a big deal, it makes using the program remotely over ssh a little easier and faster, since you don’t have to worry about a display window.
The point is that when experimenting with different boards in your projects, you may have to make minor adjustments to get all your features to work the way you want. Sometimes, you may not have an option in one version that you have in another.
On the other hand, running guvcview on the BeagleBone worked great out-of-the-box. The video feed window came up without issue and the image updated in near real-time. I’ve had startup troubles with guvcview on the Raspberry Pi 3. Earlier versions may have fewer features and less complicated code. It’s simpler to operate and fewer things can mess up, in other words. Something happened along the way, on the Pi, where the application wouldn’t come up at all on the screen. I eventually found that restarting the JACK server, then starting guvcview solved the problem. How does that relate?
As a matter of fact, I actually used the webcamoid program for the Hedley talk at OSCON, because I wasn’t sure that guvcview would behave properly when we were up on stage. I’m confident that I could trust guvcview working reliably on the BeagleBone in front of the audience right now.
And guess what? Later, I found that webcamoid didn’t show up in the list of available applications on my older version of Debian Linux, on the BeagleBone.
It’s Alive
Being able to swap out nano-Linux boards in your project, is a good thing. It gives you the ability to optimize features and capabilities for your particular application. In this case, the BeagleBone looks like it will use a little less power and will have a more consistent operation for our particular set of requirements.
Keep in mind too that broad interchangeability is just now really starting to mature. You never had the choices five or even three years ago, that you have today. That applies to hardware, software, price, availability, vendor and a myriad of other factors.
And, the best part. It’s all “off-the-shelf” easy.
