Beaglebone

Roger Cheng

My BeagleBone Boards Returning to Their Box

I have two BeagleBone boards — a PocketBeagle and a BeagleBone Blue — that had been purchased with ambitions too big for me to realize in the past. In the interest of learning more about the hardware so I can figure out what to do with them, I followed the lead of a local study group to read Exploring BeagleBone, Second Edition by Derek Malloy. I enjoyed reading the book, learned a lot, and thought it was well worth the money. Now that I am better informed, I returned to the topic of what I should do with my boards.

I appreciate the aims of the BeagleBoard foundation, but these boards are in a tough spot finding a niche in the marketplace. Beagle boards have a great out-of-the-box experience with a tutorial page and Cloud9 IDE running by default. But as soon as we try to go beyond that introduction, all too quickly we find that we’re on our own. The Raspberry Pi foundation has been much more successful at building a beginner-friendly software ecosystem to support those trips beyond the introduction. On the hardware side, Broadcom processors on a Pi are far more computationally powerful than CPUs on equivalent beagles. This includes a move to 64-bit capable processors on the Raspberry Pi 3 in 2017, well ahead of BeagleBoard AI-64 that launched this year (2022). That last bit is important for robotics, as ROS2 is focused on 64-bit architectures and there’s no guarantee of support for 32-bit builds.

Beyond the CPU, there were a few advantages to a Beagle board. My favorite are the more extensive (and usable) collection of onboard LEDs and buttons, including a power button for graceful powerup / shutdown that is still missing from a Raspberry Pi. There is also onboard flash memory storage of known quality, which makes their performance far more predictable than random microSD cards people would try to use with their Raspberry Pi. None of those would be considered make-or-break features, though.

What I had considered a definitive BeagleBone hardware advantage are the programmable real-time units (PRU) within Octavo modules, capable of tasks with timing precision beyond the guarantee of a Linux operating system. In theory that sounded like great teaming for many hardware projects, but in Exploring BeagleBone chapter 15 I got a look at the reality of using a PRU and I became far less enamored. Those PRU had their own instructions, their own code building toolchain, their own debugging tools, and their own ways of communicating with the rest of the system. It looked quite convoluted and intimidating for a beginner. Learning to use the PRU is not like learning a little peripheral. It is literally learning an entirely new microcontroller and that knowledge is not portable to any other hardware. I can see the payoff for highly integrated commercial industrial solutions, but that kind of time investment is hard to justify for hobbyist one-off projects. I now understand why BeagleBoard PRUs aren’t used as widely as I had expected them to be.

None of the above sounded great for my general use of BeagleBoard, but what about the robotics-specific focus of the BeagleBoard Blue? It has lots of robot-focused hardware, crammed onto a small board. Their corresponding software is the “Robot Control Library”, and I can get a good feel for its capabilities via the library documentation site. Generally speaking, it looked fine until I clicked on the link to its GitHub repository. I saw the most recent update was more than two years ago, and there is a long backlog of filed issues few people are looking at. Those who put in the effort to contribute code in a pull request could only watch and sit them gather dust. The oldest PR is over two years old and has yet to be merged. All signs of an abandoned codebase.

I like the idea of BeagleBone, but after I took a closer look, I’m not terribly enthused at the reality. At the moment I don’t see a project idea niche where a BeagleBone board would be the best tool for the job. With my updated knowledge, I hope to recognize a good fit for a Beagle board if an opportunity should arise. But until then, my boards are going back into their boxes to continue gathering dust.

Roger Cheng

Notes on “Exploring BeagleBone” by Derek Molloy

As an electronics hobbyist I’ve managed to collect two different BeagleBone boards, but I’ve never done anything useful with them. In the interest of learning enough to put them to work, I bought the Kindle eBook for Exploring BeagleBone, Second Edition by Derek Molloy. (*) I dusted off my PocketBeagle from the E-ALE hardware kit and started following along. My current level of knowledge is slightly higher than this book’s minimum target audience, so some of the materials I already knew. But there were plenty I did not know!

The first example came quickly. In chapter 2 I learned how to give my PocketBeagle access to the internet. This is not like a Raspberry Pi which had onboard WiFi or Ethernet. In contrast, a PocketBeagle’s had to access the network over its USB connection. At E-ALE I got things up and running once, but SCaLE was a Linux conference so I only received instructions for Ubuntu. This book gave me instructions on how to set up internet sharing over USB in Windows, so my PocketBeagle could download updates for its software.

Chapter 5 Practical Beagle Board Programming is a whirlwind tour of many different programming languages with their advantages and disadvantages. Some important programming concepts such as object-oriented programming was also covered. My background is in software development, so few of the material was new to me. However, this chapter was an important meta-learning opportunity. Because I already knew the subject matter, as I read this chapter I frequently thought: “Wait, but the book didn’t cover [some related thing]” or “the book didn’t explain why it’s done this way”. This taught me a mindset for the whole book: it is a quick superficial overview of concepts that give us just enough keywords for further learning. The title is “Exploring BeagleBone”, not “BeagleBone in Depth”!

On that front, I believe the most impactful thing I learned from this book is sysfs, a mechanism to allow communication with system hardware by treating their various input/output parameters as files. This presents an interface that avoids the risks and pitfalls of going into kernel mode. Sysfs was introduced in chapter 2 and is used throughout the text, culminating in the final chapter 16 where we get a taste of implementing a sysfs interface in our own loadable kernel module. (LKM) But there are many critical bits of knowledge not covered in the book. For example, sysfs was introduced in chapter 2 where we were told the sysfs path /sys/class/leds/beaglebone:green:usr3/brightness will allow us to control brightness of one of BeagleBoard’s onboard LEDs. That led me to ask two questions immediately:

  1. If I hadn’t known that path, how would I find it? (“What is the sysfs path for an onboard LED?”)
  2. If I look at a /sys/ path and didn’t know what hardware parameter it corresponded to, how would I find out? (“What does /sys/[blah] control?”)

The book does not answer these questions. However, it taught me that sysfs interfaces were exposed by loadable kernel modules (LKM, chapter 16) and that LKMs are loaded for specific hardware based on device tree (chapter 6). Given this, I think I have enough background to go and find answers elsewhere.

The book used sysfs for many examples, and the book also covered at least one example where sysfs was not enough. When dealing with high-bandwidth video data, there’s too much overhead for sysfs so the code examples switched to using ioctl.

My biggest criticism of this book is a lax attitude towards network security. In chapter 11 (The Internet of Things) instructions casually tell readers to degrade their GMail account security and to turn off Windows firewall. No! Bad book! Bad! Even worse, there’s no discussion of the risks that are opened up if a naive reader should blindly follow those instructions. And that’s just the reader’s email account and desktop machine. What about building secure networked embedded devices with a BeagleBone? Nothing. No discussion at all, not even a superficial overview. There’s a running joke that “The S in IoT stands for security” and this book is not helping.

Despite its flaws, I did find the book instructive on many aspects of a BeagleBone. And thanks to the programming chapter and lack of security information, I’m also keenly aware there are many more things not covered by this book at all. After reading this book, I pondered what it meant for my own BeagleBone boards.

UPDATE: I was impressed by this application of sysfs: show known CPU hardware vulnerabilities and status of mitigations: grep -r . /sys/devices/system/cpu/vulnerabilities/

(*) Disclosure: As an Amazon Associate I earn from qualifying purchases.

Roger Cheng

Taking Another Look at BeagleBone

I like the idea behind BeagleBone boards, a series of embedded Linux devices. BeagleBone hardware are built around modules from Octavo Systems, which are designed for easy of integration into custom embedded hardware. BeagleBone are merely one of many Octavo-based devices, but (as far as I know) the only one focused on building an easy on-ramp for learning and hobbyist use. From that aspect they resemble the Raspberry Pi lineup, but sadly they have not found the same degree of success.

One advantage of a BeagleBoard are the onboard LEDs available for experimentation. A Raspberry Pi has onboard LEDs as well, but they already have jobs indicating power and microSD activity and it takes work to reallocate them for a quick experiment. But my favorite BeagleBone advantage is a power button for graceful shutdowns, something that’s always been missing from the Pi since the first version. Even though they are now on the Pi 4, the Raspberry Pi foundation seems uninterested in solving this problem. I’ve read claims that SD corruption from ungraceful shutdowns are rare, but it still makes me grumpy.

I personally own two BeagleBone devices. The first was a PocketBeagle I bought with the intention of taking the E-ALE (Embedded Apprentice Linux Engineer) course that premiered at SCaLE 16X. Unfortunately, between my lack of foundational knowledge and the rough nature of their first run, I didn’t absorb very much information from the course. But I still have the PocketBeagle and Bacon Bits cape that went with the course.

The second was a BeagleBone Blue that I bought after a conversation at SCaLE with Jason Krider, one of the people behind BeagleBone. He saw my Sawppy rover and told me about BeagleBone Blue which was designed with a focus on robotics. He asserted a Blue should be much more suitable for Sawppy than the Raspberry Pi I had been using. I ordered a board and, as soon as I took it out of the box, I knew I had a problem. The physical size of BeagleBone boards is designed to fit in an Altoids mint tin. In order to follow that precedence and cram onboard all the robotics-related output, the Blue used many fine-pitched connectors that aren’t in my usual toolkit of connectors. I looked into either paying for pre-made wiring bundles with the connectors already crimped, or tools to crimp my own, and balked at the cost. I decided to think it over, which stopped my momentum, and it’s been sitting ever since.

Which is a shame, because on paper these are nifty little devices! Now motivated by a local study session meetup, I decided to buy an eBook to help me get a better understanding of BeagleBone. I’m still not comfortable with public gatherings, but I can follow along at home as the study group went through chapters of Exploring BeagleBone, Second Edition by Derek Molloy.

Roger Cheng

BeagleBone Blue And Robot Control Library Drives eduMIP

My motivation to learn about the BeagleBone Blue came from my rover Sawppy driving by the BeagleBoard foundation booth at SCaLE 17x. While this board might not the best fit for a six wheel drive four wheel steering rocker bogie mars rover model, it has a great deal of potential for other projects.

But what motivated the BeagleBone Blue? When brainstorming about what I could do with something cool, it’s always instructive to learn a little bit about where it came from. A little research usually pays off because the better my idea aligns with its original intent, the better my chances are of a successful project.

I found that I could thank the Coordinated Robotics Lab at University of California, San Diego for this creation. As teaching tool for one of the courses at UCSD, they created the Robotics Cape add-on for a BeagleBone Black. It is filled with goodies useful for robot projects they could cover in class. More importantly, with quadrature input to go along with DC motor output and a 9-axis IMU on top of other sensors, this board is designed for robots that react to their environment. Not just simple automata that flail their limbs.

The signature robot chassis for this brain is the eduMIP. MIP stands for Mobile Inverted Pendulum and the “edu” prefix makes it clear it’s about teaching the principles behind such systems and invite exploration and experimentation. Not just a little self-balancing Segway-like toy, but one where we can dig into and modify its internals. I like where they are coming from.

eduMIP 1600
Photo of eduMIP by Renaissance Robotics.

BeagleBone Blue, then, is an offering to make robots like an eduMIP easier to build. By merging a BeagleBone Black with the Robotics Cape into a single board, removing components that aren’t as useful for a mobile robot (such as the Ethernet port) we arrive at a BeagleBone Blue.

Of course, the brawn of a robotics chassis isn’t much use without the smarts to make it all work together. Befitting university coursework nature and BeagleBoard Foundation’s standard procedure, its peripherals software now called Robot Control Library are documented and source code available on Github.

I could buy an eduMIP of my own to help me explore the BeagleBone Blue, and at $50 it is quite affordable. But I think I want to spend some time with the BeagleBone Blue itself before I spend more money.

Roger Cheng

Window Shopping BeagleBone Blue

Sawppy was a great ice breaker as I roamed through the expo hall of SCaLE 17x. It was certainly the right audience to appreciate such a project, even though there were few companies with products directly relevant to a hobbyist Mars rover. One notable exception, however is the BeagleBoard Foundation booth. As Sawppy drove by, the reception was: “Is that a Raspberry Pi? Yes it is. That should be a BeagleBone Blue!”

Beaglebone Blue 1600
BeagleBone Blue picture from Make.

With this prompt, I looked into BBBlue in more detail. At $80 it is significantly more expensive than a bare Raspberry Pi, but it incorporates a lot of robotics-related features that a Pi would require several HATs to reach parity.

All BeagleBoards offer a few advantages over a Raspberry Pi, which the BBBlue inherits:

  • Integrated flash storage, Pi requires a separate microSD card.
  • Onboard LEDs for diagnosis information.
  • Onboard buttons for user interaction – including a power button! It’s always personally grated me a Raspberry Pi has no graceful shutdown button.

Above and beyond standard BeagleBoards, the Blue adds:

  • A voltage regulator, which I know well is an extra component on a Pi.
  • On top of that, BBBlue can also handle charging a 2S LiPo battery! Being able to leave the battery inside a robot would be a huge convenience. And people who don’t own smart battery chargers wouldn’t need to buy one if all they do is use their battery with a BBBlue.
  • 8 PWM headers for RC-style servo motors.
  • 4 H-bridge to control 4 DC motors.
  • 4 Quadrature encoder inputs to know what those motors are up to.
  • 9-axis IMU (XYZ accelaration + XYZ rotation)
  • Barometer

Sadly, a BBBlue is not a great fit for Sawppy because it uses serial bus servos making all the hardware control features (8 PWM header, 4 motor control, 4 quadrature input) redundant. But I can definitely think of a few projects that would make good use of a BeagleBone Blue. It is promising enough for me to order one to play with.