Packing Bubble Squish Test

I wrote down my first impressions of Node-RED Dashboard, here I describe the project I used to explore and exercise my new tools in the Node-RED toolbox. It is a silly little thing that tests the squishiness of a plastic air bubble used as packing material. The bubble isn’t important, the main objective was to build my first nontrivial Node-RED flow and have it interface with my two recent hardware projects: the 3-axis motion control chassis of a retired Geeetech A10 printer, and the load cell kit mounted where the printer’s build plate used to be.

Both of these hardware components use USB connections that show up on the computer as serial ports, which made it easy to interface with Node-RED via node-red-node-serialport. Once installed, I had three new nodes on my palette. “Serial in” is what I needed to read the stream of data coming in from the Arduino handling the HX711 reading the load cell strain gauges. “Serial request” is what I needed for bidirectional data transfer with the 3D printer control board: sending G-code commands and reading status like position. (The third one, “Serial out”, is not applicable to this project.)

To keep the project simple, my X- and Y-axis motion are hard coded and I only hooked up a few Dashboard buttons to control my 3D printer motion in the Z-axis. This allowed me to fine tune the height of the carriage. I added buttons to remember two set heights A and B, and a toggle to automatically cycle between those positions.

I set my plastic bubble test subject down on the platform and used my flow to make the machine repeatedly press down on the bubble. Pressure reported by the load cell is sent to a Node-RED chart to graph its change over time.

Fast and Easy UI via Node-RED Dashboard

In addition to JSONata, there’s another very important project that is technically not part of core Node-RED. But it is rare to see one without another, and I’m speaking of the Node-RED Dashboard add-on module.

Every single Node-RED project I’ve seen makes use of the Dashboard module to build a HTML-based user interface. Which was why when I started learning Node-RED tutorials I was confused there were no mention of how to build an user interface. It took some time before I realized the Dashboard is not considered part of the core system and had to be installed separately. Once installed, there were additional nodes representing UI and additional editor interface. (Some UI to build UI…)

Once I finally realized my misconception and corrected it, I was able to build a functional interface in less than ten minutes, an amazingly short time for getting up and running under a new user interface construction system. Basic input controls like buttons and sliders, basic output controls like gauges and charts, they all worked just by connecting nodes to feed data.

However, the layout options are fairly limited. While it is extremely easy to build something closely resembling what I had in mind, I see no way to precisely adjust layout details. The rest of Node-RED reminds me of snapping LEGO pieces together, but the Dashboard exemplified the feeling: I can quickly snap together something that resembles the shape I had in mind, but if a distance is not an even number of LEGO stud spacing, I’m flat out of luck.

But even if I don’t see options for custom layout, I found instructions for building my own display widgets. Node-RED Dashboard is built on AngularJS a.k.a. Angular 1.x. I’m not sure I want to invest the time to learn AngularJS now. I can probably pick up enough AngularJS to do a custom widget if all I want is that single widget and reuse everything else. But AngularJS is currently on long-term support status receiving only security updates. Fortunately the fact Node-RED Dashboard is an add-on means people can (and have) built their own dashboard using other UI frameworks by hooking into the same extensibility mechanisms used by Dashboard. So if I want precise control over layout or other custom mechanism, I can do that while still using Node-RED as the underlying engine. I’m impressed we have that extremely powerful option.

But those dreams of grand expansion and customization are for the future. Right now I still need to build experience working with the system, which means putting it to work on a simple test project.

JSONata Reduces Need For Node-RED Function Nodes

Node-RED is built on sending messages from one node to the next. While there are some recommended best practices, it is really a wide-open system giving users freedom on how to structure the relationship between their nodes. As for the messages, they are JavaScript objects and there’s a convention to structuring them within a Node-RED project. While I can always fall back to writing JavaScript to work with messages, for the most part I don’t have to. Between the Cookbook and the Best Practices document, there are many methods to accomplish some commodity programming flow control tasks without dropping to a JavaScript function node.

But the built-in nodes have limited data manipulation capabilities. So I thought anything that requires actual data manipulation requires dropping to code. I was pleasantly surprised to find I was wrong: simple text changes and similar manipulation can be done without dropping to a JavaScript function node, they can be done with a JavaScript-based query and transformation language called JSONata.

JSONata appears to be an independent project not directly related to Node-RED, but it fits in very well with how Node-RED works and thus widely supported by many property fields of nodes. Any JavaScript string or data manipulation that could fit within a line or two of code can probably be expressed in JSOSNata, and thus accomplished directly in a standard Node-RED field without requiring dragging in a fully fledged JavaScript function node.

JSONata is yet another novelty in my exploration of Node-RED. I can vaguely sense this can be tremendously powerful, and I look forward to experimenting with this capability for future projects. But there’s another technically-not-core Node-RED feature that I will definitely be using, and that is the Node-RED Dashboard.

Node-RED Recommended Best Practices

Learning a new programming language, especially one with an entirely different paradigm, is confusing enough without having to worry about best practices. But after climbing enough of the learning curve, things quickly start getting chaotic and a little structure would help. I found this to be even more true for flow-based programming in Node-RED because a growing collection of nodes and wires connecting them can quickly grow into spaghetti code in a more literal sense than what I’ve been used to. A blank and pristine Node-RED flow doesn’t stay neat and pristine for long.

Fortunately, Node-RED documentation has a section called Developing Flows to help poor lost souls like me. It collects some basic recommendations for keeping flows manageable. And just like the Cookbook, it made more sense for me to read them after getting some hands-on experience building a bird’s nest of crossed wires and scattered nodes.

I felt sheepish to learn that I can have multiple tabs in the editor workspace. I should have noticed up top with a shape surrounding the name “Flow 1” and the plus sign to its right, but I had missed it completely. Each tab is a flow and when the project is deployed, all tabs (flows) execute simultaneously in parallel in response to their respective messages. This inherent parallelism does indeed remind me of LabVIEW.

Obviously multiple tabs make it easy to have unrelated features running in parallel, but what if they need to communicate with each other? That’s where I can use the link-in and link-out nodes. The set of link-in and link-out nodes with matching names act as wires connecting those nodes together.

They can also be used to declutter wires within a single flow. They still act the same way, but when one of the nodes is clicked, a dotted line representing the wire is visible on screen to make it easy to trace flow. Once unselected, the dotted line disappears.

A set of nodes can be combined together into a single “subflow“. In addition to decluttering, a subflow also aids in code reusability because a single subflow can be used multiple times in other flows and they all execute independently.

And finally, multiple adjacent nodes within a flow can be associated together as a group. The most obvious result is visually identifying the group as related. The editor also allows moving all the nodes in the group as a single unit. Beyond that, I don’t know if there are functional effects to a group, but if so I’m sure I’ll find them soon.

As an ignorant beginner, my first thought to flow organization most closely resembled groups. Which is why I was a little surprised to read it was added only very recently in 1.1.0. But once I read through the best practices recommendation in this Developing Flows section, I learned of all the other aspects of keeping flows organized, and I can see why groups hadn’t been as critical as I originally thought.

On the other side of the coin, as I explored Node-RED I found several other software modules that are deeply ingrained in many Node-RED projects, but aren’t technically a part of Node-RED. JSONata is one of these modules.

Node-RED Cookbook Was More Useful After Some Experience

The Node-RED User’s Guide helped me get started as a beginner on a few experimental flows of my own, slowly venturing beyond the comfort of JavaScript functions. But it was a constant process of going back and forth between my flow (which is not working) and the user’s guide to understand what I was doing wrong. I had fully expected this and, as far as beginner learning curves go, Node-RED is not bad.

On the Node-RED Documentation page, a peer of the User’s Guide is the Cookbook. I thought its subtitle “Recipes to help you get things done with Node-RED” was promising, but as a beginner I could not make use of it. It listed some common tasks and how to perform those tasks, but they were described in Node-RED terminology (‘message’ ‘flow’) which I as a beginner had yet to grasp. I couldn’t use the recipes when I didn’t even understand the description of the result.

Continuing the food preparation analogy: If I didn’t understand what “Beef Wellington” was, I wouldn’t know if I wanted to cook it, or be able to find the recipe in the book.

So to make use of the Node-RED cookbook, I had to first understand what the terms mean. Not just the formal definition, but actually seeing them in practice and trying to use them a few times on my own. After a few hours of Node-RED exploration I reached that point, and the Node-RED cookbook became a powerful resource.

I don’t know how the Node-RED Cookbook could make this any easier. It’s the kind of thing that was opaque to me as a beginner, but once I understood, everything looks easily obvious in hindsight. I stare at the cookbook descriptions now, and I don’t understand how I couldn’t comprehend the same words just a few days ago. I wish I could articulate something useful and contribute to help the next wave of beginners, because that would be amazing. But for now I can only be the beginner, consuming existing content like a Best Practices guide.

Node-RED Function Nodes Are A Comforting Fallback

Node-RED beginners like myself are given some hand-holding through two tutorials, creatively titled Creating Your First Flow and Creating Your Second Flow. After that, we are dropped into the User’s Guide for more information. The Using Node-RED section of that page covers fundamentals to get up to speed on how to work in a Node-RED project. Within that section, the page I found most instructive and informative is Using the Function Node.

Part of this might just be familiarity. A function node is a node that encapsulates a JavaScript function for doing whatever the author can write JavaScript to do. Because I’m familiar with languages like C and Python, I’m comfortable with the mentality of writing functions in source code to do what I have in mind. So seeing the function node and all I can do within it is comforting, like seeing a familiar face in a new crowd.

And just as in real life, there will be some level of temptation to stay in the comfort zone. It is probably possible to write any Node-RED program with just three nodes: an input node, a single Function node with a lot of JavaScript code, and an output node.

But writing all my logic in a single JavaScript function node would be ignoring the power of the platform. Flows allows me to lay out my program not in terms of functions calling one another, but in terms of messages flowing from one node to the next. Each node is an encapsulated representation of a feature, and each message is a piece of information that was generated from one node to inform another node on what to do next.

This is a different mentality, and it’ll probably take a bit of practice for me to rearrange my thinking to take advantage of the power of the platform. But while that transition is taking place, I expect to get occasionally stuck. But I know I can unblock myself by resorting to little pieces of JavaScript programming inside a big data flow program, and that’s a good confidence builder for me to proceed building some hands-on experience with Node-RED. I needed that experience before I could understand additional Node-RED resources like the Cookbook.

Brief Look At National Weather Service Web API

I’ve started exploring Node-RED and I like what I see. It’s a different approach to solving some problems and it’s always nice to have tools in the toolbox that would serve specific needs better than anything I had available before. The second tutorial introduced interacting with REST APIs on the web by querying for earthquake data, which was fun.

But while interesting and informative, there’s nothing I do differently after seeing earthquake data. Weather data, on the other hand, is a different story. As of this writing we’re living through a heat wave, and knowing the forecast daily highs and lows does affect my decisions. For example, whether to use my home air conditioning to pre-cool the house in the morning, which supposedly helps reduce load on the electric grid in the peak afternoon hours.

So I went looking for weather information and found a lot of taxpayer funded resources at the National Weather Service (NWS). Much of which is available as web service APIs. But in order to get data applicable to myself, I first need to figure out how to identify my location in the form of their grid system.

After a few false starts, I found my starting point (literally) in the points endpoint, which returns a set of metadata relevant to the given longitude and latitude. The metadata includes the applicable grid type as well as the X and Y coordinates corresponding to the given latitude and longitude. There are a lot of ways to get usable lat/long values, I went to the Wikipedia page for my city.

Once armed with the gridId, gridX, and gridY values, I could use them to query the remaining endpoints, such as asking for weather forecast for my grid. There’s a wealth of information here that can be a lot of fun for a future project, possibly for a smart home concept of some sort, but right now I should set aside this distraction and return to learning Node-RED.

New Exploration: Node-RED

While researching LabVIEW earlier, I came across several forum threads from people asking if there’s a cheaper alternative. I haven’t come across any answers for a direct free open source competitor, but a few people did mention that LabVIEW’s data flow style of programming had some superficial similarities to Node-RED. With the caveat they are very different software packages targeting different audiences.

Still, it sounded interesting to look into. This was reinforced when I saw Node-RED in a different context. An enthusiastic overview on Hackaday, with a focus on home automation processing data distributed via MQTT. My current project is focused on a single machine and not distributed across many network nodes, so I’m not going to worry about MQTT for the time being, but the promise of an easy way to consume, process, and visualize data is quite alluring. I’ll use my newly assembled load cell as a data source and learn how to integrate it with Node-RED.

But before that can happen, I need to install Node-RED and run through the beginner tutorials. There are many options but the easiest way for me is to install Node-RED is a community-contributed plugin for FreeNAS. This gives me an one-click procedure to install Node-RED into a FreeBSD Jail on my FreeNAS home server. And if I decide I didn’t like it, it is also a one-click cleanup.

The simplicity of setup, unfortunately, also means a lack of choice in basic configuration. For example, I have no idea how to properly secure a Node-RED instance installed in this manner.

But that’s not important right now, because the one-click plugin install has fulfilled the purpose of having Node-RED up and running for me to try beginner tutorials elaborately named “Create your first flow” and “Create your second flow“. Though partway through tutorials I got distracted by the National Weather Service web API.

Compacting Load Cell Electronics

After being pleasantly surprised by the performance of a low cost strain gauge load cell built from a kit sold on Amazon, I decided it was worth the effort of making a more compact version of the circuit. Small enough so it can be installed on the Y-axis carriage of a Geeetech A10 chassis alongside the strain gauges being read.

First of all, the prototyping breadboard had to go. It is far too large and bulky and serves no purpose once the wiring scheme has been confirmed and would actually be a source of failure if jump wires fall out. I don’t need the Arduino Nano mounted on that breadboard, either. It has two full rows of pins which I won’t need. I could spend the time to desolder those pins, but it is much easier to pull a new unit out of its box as they come without the pins. I can solder wires directly to the vias matching what I need for power, ground, data, and clock.

I did, however, need to desolder the four pins on the HX711 interface board, they are no longer necessary. Once they were removed, I could put the Arduino Nano and the HX711 board side by side and the four short wires between them.

Finally, a small 3D-printed bracket whose only purpose was to hold the two PCBs together, removing any strain from the four wires connecting the two PCBs. The idea is that I may want to explore different ways to mount this assembly, but I always need to have the two boards next to each other. Thus the motivation for a separate bracket for actual mounting to Y-axis carriage.

The Y-axis carriage clip didn’t work as well as I had hoped, but for the moment I’m not going to worry about redoing it. A little tape is enough for me to move on to the next step: feeding its data output to a computer system.

Surprising Precision and Consistency from Load Cell

I got far enough with my low cost load cell project to start receiving readings. Advertised to measure up to 200kg, I doubted it would be very precise when measuring the light weights I expect to be placed on my former 3D printer. I would have not been surprised if it consistently returned “less than 1kg” and no further. Every measurement instrument has an optimal range where it works best. Grossly exceeding that range can sometimes result in irreparable damage, but the situation usually isn’t as dire for going under. However, we shouldn’t expect very useful answers.

The test setup was far from helpful for this. I 3D-printed four rectangular blocks of plastic to hold the four strain gauges, and a thin sheet of acrylic is placed on top of them to act as surface. It was crude, but like everything else in the setup, it was just to get an idea of feasibility.

I didn’t even worry very much about accuracy. The HX711 library has various capabilities for calibration and scaling, but I skipped all of that and just dumped the raw value without conversion to any actual units. This is all I need to start characterizing behavior of this load cell. Plotting those values out on a graph, I was not surprised to see the value was pretty noisy measuring analog values within a very narrow range. However, for the most part it does stay within a certain range.

I placed the small PCB ruler I used earlier on the surface, wondering if its addition would be lost in the noise. I was surprised to see its presence was clearly visible. This item was only several grams and I did not expect it to be so clearly visible on a 200kg scale! Bringing my kitchen scale into the picture, I tried various household items to get a better feel of its sensitivity.

Empirically, values must be at least 5 grams before it would stand out from the noise, and differences should be at least 15 grams before they are reliable. This is not bad at all. However, I foresee a lot of challenges with trying to correlate raw ADC values to real units because of its sensitivity to other factors. Strain gauge readings are affected by temperature and this is especially noticeable in the middle of a heat wave. As my home heats up in the afternoon and cools down in the evening, the strain gauge average value moves in sync.

That problem might be solvable, but it’s only the first of many problem with this low cost load cell. I also observed that, at unpredictable times, the reading would be wildly (several orders of magnitude) out of range. I don’t have a good explanation, but I’m willing to tolerate it given the low price point. This is helped by how extreme those values are, making it a simple matter to ignore them.

Happy with the performance of the load cell, and satisfied that the problems I see up front is manageable, I proceeded to move the circuit off of a prototyping breadboard and onto something smaller and more permanent.

HX711 Library on Arduino Nano via PlatformIO

I’m building a strain gauge load cell kit that used a HX711 chip, and found publicly available code to interface with a HX711 in the form of a PlatformIO project. This motivated me to investigate PlatformIO. Installation was straightforward from with Visual Studio Code. I brought up the extensions marketplace, searched for PlatformIO, clicked install, and a few minutes later I was ready to go. This was a very promising start.

But while I’ve found PlatformIO to largely live up to its advertised ease of use, there were a few bumps climbing the learning curve. I typed in the simple Arduino introductory tutorial to blink the on board LED and hit Build All. That took almost half an hour as PlatformIO downloaded a whole bunch of tools and then executed them, even though they seemed completely irrelevant to my project.

After the excessively long procedure completed, I scrolled back to investigate what happened. I eventually figured out building everything meant building my Arduino sketch for every piece of hardware PlatformIO supported for use with Arduino framework. So it didn’t just build for the ATmega328P chip on my Arduino Nano, it also downloaded tools and built for SAMD-based Arduinos. Then downloaded and built for ESP32 Arduino. Then NXP, etc. So on and so forth.

And to add insult to injury, it didn’t even build for the specific Arduino I wanted to use. A little web sleuthing found this forum thread, where I learned I needed to add platform descriptor for an Arduino Nano with the “new” bootloader. But once I figured it out, I could build just for my board (taking only a few seconds this time) and upload for a blinking LED.

With that procedure figured out, I moved on to the HX711 project. Adding an entry for Arduino Nano with “new” bootloader, I was able to get it up and running to read values from my load cell.

There are a lot of other PlatformIO features I want to come back and explore later in more depth. The most exciting of which is debugger support, something sorely lacking in Arduino IDE. It also has support for ESP32, a dev board I want to spend more time exploring. Not just compile and upload, either, but infrastructure like unit test and debugging, the latter as long as I have a JTAG adapter and I don’t use the associated pins for something else.

But that is in the future. For now, this is enough of a detour into PlatformIO. With the HX711 talking to the Arduino, attention returns to the machine work surface project because I want to better understand all this data now flowing from the HX711.

HX711 Interface Library as Introduction to PlatformIO

Whenever the goal is to find something quick and easy to talk with a piece of hardware, the standard operating procedure is to search for an Arduino library for that hardware. Hence after I soldered connectors for a HX711 board my search landed at the page for an Arduino HX711 library.

There was, however, a minor twist: this Arduino library is not in the form of an INO sketch or a downloadable ZIP file for the “Libraries” folder of the standard Arduino IDE. It uses an alternative in the form of a PlatformIO project. Normally requiring a new piece of software would make me hesitate and maybe continue searching for an alternative, but PlatformIO had been on my to-do list for some time and I thought this is a good place to dip my toes in.

PlatformIO is available in several different forms, the most appealing for me is as an extension to Visual Studio Code. I’ve already been using VSCode for a few projects, even a few Arduino projects! In a strictly workaround sort of way, that is. There have been a few instances where an Arduino project got too annoying to use in the limited Arduino IDE so I copied the source file into VSCode, did my work, then copied it back into Arduino IDE for compilation and upload.

With PlatformIO installed as a VSCode extension, I shouldn’t need to do that convoluted workaround. I can build and upload directly from within VSCode. That sounded really promising earlier, but not quite enough for me to pause my project the first time. Now that PlatformIO and I have crossed paths again, I’ll take a pause for a closer look.

Connecting HX711 Amplifier ADC Board

After I finished wiring the strain gauge array for a load cell, I pulled the bundled circuit board out of its anti static bag. According to the product listing, this is built around a HX711 amplifier and analog-to-digital (ADC) converter. All that information I read earlier about putting excitation voltages into a Wheatstone bridge to interpret small changes in strain gauge resistance? All that magic is done inside this chip.

The bundle included some classic 0.1″ pitch pins to solder to the circuit board, but I thought I had a better idea. I pulled out my JST-XH connector kit and used the six-position wire-to-board unit for my strain gauge array connection. JST-XH is polarized to help ensure I don’t plug it in backwards. However, it is bigger than plain unadorned headers so it didn’t fit with the surface mount components already on the board, requiring that I mount it to the flat backside instead.

I didn’t perform the same JST-XH replacement for the digital data connection, because I wanted the flexibility to use jumper wires to connect this board to something I can use to read data from a HX711. Looking around for software libraries online, I found a HX711 library for Arduino so I pulled out my prototyping breadboard with an Arduino Nano already on board. This is as good of a starting point as any.

Four jumper wires were needed: power, ground, data, and clock. The hardware is ready to go, so I switched gears to software and today’s little plot twist of PlatformIO.

Start Simple With Low Cost Load Cell

I now have ambition to give my project machine’s work surface the ability to act as a weight/pressure sensitive scale. The first stop, as always, is Wikipedia which filled in the fundamental knowledge of a strain gauge load cell plus links to associated topics like the electronic design called Wheatstone bridge used to read the values of such contraptions. Seeking a little more detail, a web search found a page on All About Circuits that clarified a few fuzzy points.

With a basic understanding of what such a project would entail, I headed over to Amazon to see my load cell options (*). I knew industrial-grade precision load cells can sell for thousands of dollars, but electronic bathroom scales are sold for less than $20 USD. With such a wide range I wasn’t sure what to expect to see for a hobbyist friendly load cell kit. The answer: under $10 USD! (*)

This price is low enough I’m not tempted to try salvaging components from an electronic bathroom scale, I bought that kit and went to work. The advertised weight range up to 200 kilograms is an appropriate range for a bathroom scale. That is far more than I expect to (intentionally) put on my machine, but it is the cheapest option. I suspect the measurement granularity/precision would be pretty crude at the range I expect to encounter, but hey, it’s cheap and a good first step into this world of sensors.

Soldering the four strain gauges together into a Wheatstone bridge network wasn’t difficult, just tedious and involved a lot of double-checking to ensure I’ve connected the wires properly. But I was not able to verify the circuit with my multimeter. The strain gauge change resistance in response to load, but the change is far too small for my multimeter to pick up. All I could check is to verify I haven’t accidentally short circuited anything or left an open circuit somewhere.

So while I prefer to verify a circuit before powering it on, in this particular case I didn’t have the right tools to do so. The cheapest option is to proceed with hooking it up to the companion circuit board and hope for the best.


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

A Weight And Pressure Sensitive Work Surface

I’m thankful I was gifted a retired and incomplete Geeetech A10 3D Printer, and I regard the missing pieces as features not bugs. Their absence meant I’m more likely to think of interesting ideas beyond the world of 3D printing. This was certainly the case when I looked at the Y-axis carriage where a heated print bed used to be.

The machine will still need a work surface of some sort, and whatever it is will still needs to be mounted and I felt there was an opportunity here. Some of my first thoughts were to make it motorized so I could dynamically control its angle. And while a fancy auto bed leveling (or deliberately non-level) mechanism might be an interesting challenge, it was not bold enough of a step away from the shadow of its previous life as a 3D printer.

Thought then moved away from mechanical actuation output and towards some sort of sensing input. I have many ideas for a 3-axis motion control chassis, and the visual measurement device was just the first idea I tried. What kind of smarts are worth exploring for a flat horizontal surface?

Being a technology geek, my thoughts went immediately towards touchscreen monitors and how I might turn the whole surface into a touch pad that can report events and their X,Y coordinates. While this would indeed be exciting, a little research indicates this wouldn’t be a very easy and I should scale down my ambitions for a first draft.

The answer came to me during my morning routine, stepping on to the bathroom scale: I can incorporate a strain gauge load cell like those inside electronic body scales. (Or postage scales, or kitchen scales…) This collapses the grand concept of a large touch pad reporting X,Y coordinates down to a single reading distributed across the entire area, but it should be an interesting starting point to have a work surface that can report weight or pressure upon it.

Old Machine Needs A Work Surface

My first prototype of a video-based measurement instrument was a bit of a bust, as I discovered my motion control precision was poor and my camera can’t resolve to the level of detail I wanted. But there’s another problem: I don’t have a working surface on this former 3D printer. For the initial test, I taped a ruler to the Y-axis carriage and that was enough to get some data, but the Y-axis carriage is not an adequate working surface given how it has protrusions from bolts holding Y-axis rollers and the ends of the Y-axis belt.

In a fully functioning Geeetech A10 3D printer, there is a heated print bed bolted to the Y-axis carriage. However, I got this machine in a partially disassembled state and I do not have that print bed or any of the associated hardware. Since I don’t intend to use this as a 3D printer, I don’t need a full-on replacement heated bed. So my replacement surface doesn’t need an electric heater. I don’t yet know if it’ll be useful to have adjustments to level the bed, it will likely depend on the precision required by whatever project happens to be at hand.

To take the next step, I need something relatively flat that is approximately the correct size. Digging through my graveyard of past projects, I found my candidate: the front panel from the first draft of my FreeNAS box project. Easily removed, as it was only taped in place. And since it had a rectangular slot cut in the middle already, it was easy to break off at the slot to form a roughly rectangular piece of acrylic at approximately the right size.

The pandemic has cut off my access to a laser cutter, so I could not cut holes for mounting bolts. Drilling brittle acrylic requires specialized drill bits or risk shattering the piece. While contemplating alternative ways to support this work surface, I started thinking it would be cool if these supports could be more than just spacers. What might I do to make it a little smarter and more interesting?

Quick Print Xbox One X Vertical Stand

Reorganizing my video game console area, I’ve decided to reorient my Xbox One X so it stands vertically to take up less table area. The console was designed to handle this scenario for the most part. There is even a designed hint on which side of the console to use: only one of the two sides is flat enough for standing. However, it is not quite as simple as turning the console on its side, because there is an open cooling vent grille on that side.

Side of Xbox One X showing cooling vents

In order to elevate the console so air can still flow through those holes, a stand is needed. There are official stands available… but where’s the fun in that? I could 3D print something and there are several stands already on Thingiverse. But I didn’t think that was any fun, either. I much rather design and print my own, but how will my contribution be different? I focused on simplicity and print time. My design should be faster to print than the others.

I focused on designing while keeping the print path in mind. It is one continuous curve that can be printed with only perimeters. No infill, no top layer, no bottom layer, no retractions. And no supports, either.

MatterControl slicer showing the design sliced as continuous curve.

I will need to print two of them.

Two copies of the design were printed, one for front and one for back.

The installation position doesn’t have to be exact, since the grille doesn’t seem to be covering anything in a particular pattern that would require that I keep the nearby holes clear. I think it should be OK to flow around these feet.

The two stands installed on Xbox One X, covering minimal cooling vent area.

The single loop design means the stand is not completely rigid but slightly flexible. The upside of this flexibility is that it will sit nicely on surfaces that are not perfectly flat. The downside of the flexibility is that the console may wobble a bit if bumped. Such is the tradeoff.

Xbox One X sitting on vertical stand.

Now my Xbox One X can stand vertically without completely blocking its cooling intakes. If someone wants to tinker with this design, the Onshape CAD file is a public document here. If someone wants to use the design as-is, it has been published to Thingiverse.

APC RBC Battery Module Teardown

I have a few UPS (Uninterruptible Power Supply) units to keep my electronics running through short blinks in household electricity, something more likely in a heat wave as neighborhood air conditioning units demand power from the grid. Historically I’ve preferred UPS made by APC as they’ve worked well for me, but over the past few years I’ve heard grumblings from unhappy APC users. The claim is that quality of their consumer line has gone down since their acquisition by Schneider Electric in a misguided effort to compete on price. I can confirm the price premium is less than it used to be, but it still exists. And as to the quality… all I can say is that my units are still working. I’ll post an update if any of the newer APC units fail.

I saw some of the complaints were of dead lead-acid batteries after some years, but I do not consider that a failure on APC’s part. Just like the lead-acid batteries in our cars, batteries are wear items expected to need replacement after some number of years. The guidelines for mission-critical UPS is to replace the battery modules after 2-3 years of active service, but that is being cautious. Batteries on long term standby (like those in a UPS) can last much longer. It’s just a matter of luck.

My luck ran out after five years, when my UPS started beeping at me with an error code. I bought the official replacement battery APCRBC123 (*) but I was curious: Superficially it appears to be two commodity 7Ah 12V modules connected together, are they actually that? Once the new module was installed and working, I took the old module outside to see if my suspicion was correct. The modules were held together by plastic sheets with adhesive backing, complete with convenient tabs where I could start peeling.

Once tape was removed (surprisingly cleanly) I could split the module apart and see it is indeed a pair of commodity form factor lead-acid batteries. Two of them, connected in series via a proprietary adapter in the middle.

So now I know: for the next replacement, it is possible to buy commodity batteries and rebuild the module myself. It wouldn’t have saved me much money this time: the APC module costs roughly in line with the average selling price of two 7Ah batteries. (*) Besides, who knows how long those zero review lowest-bidder batteries would last. But in a few years my new battery module will wear out and require another replacement. If there is a significant price premium on authentic APC replacement modules — or if they are no longer available at all — I have a fallback option.


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

Virtual Lunar Rovers May Help Sawppy Rovers

Over a year ago I hand-waved a grandiose wish that robots should become smarter to compensate for their imperfections instead of chasing perfection with ever more expensive hardware. This was primarily motivated by a period of disillusionment as I wanted to make use of work by robotics research only to find that their published software tend to require hardware orders of magnitude more expensive than what’s feasible for my Sawppy.

Since then, I’ve noticed imperfection is something that’s coming up more and more frequently. I had my eyes on the DARPA Subterranean Challenge (SubT) for focusing researcher attention towards rugged imperfect environments. They’ve also provided a very promising looking set of tutorials for working with the ROS-based SubT infrastructure. This is a great resource on my to-do list.

Another interesting potential that I wasn’t previously aware of is NASA Space Robotics Phase 2 competition. While phase 1 is a simulation of a humanoid robot on Mars, phase 2 is about simulated rovers on the moon. And just like SubT, there will be challenges with perception making sense of rugged environments and virtual robots trying to navigate their way through. Slippery uneven surfaces, unreliable wheel odometry, all the challenges Sawppy has to deal with in real life.

And good news, at least some of the participants in this challenge are neither big bucks corporations nor secretive “let me publish it first” researchers. One of them, Rud Merriam, is asking questions on ROS Discourse and, even more usefully for me, breaking down the field jargon to language outsiders can understand on his blog. If all goes well, there’ll be findings here useful for Sawppy here on earth! This should be fun to watch.

Micro-ROS Now Supports ESP32

When I looked wistfully at rosserial and how it doesn’t seem to have a future in the world of ROS2, I mentioned micro-ROS appeared to be the spiritual successor but it required more powerful microcontrollers leaving the classic 8-bit chips behind. Micro-ROS doesn’t quite put microcontrollers on a ROS2 system as a first-class peer to other software nodes running on the computer, as there still needs to be a corresponding “agent’ node on the computer to act as proxy. But it comes closer than rosserial ever tried to be, and looks great on paper.

Based on the micro-ROS architectural overview diagram, I understand it can support multiple independent software components running in parallel on a microcontroller. This is a boost in capability from rosserial which can only focus on a single task. However, it’s not yet clear to me whether a robot with a microcontroller running micro-ROS can function independent of a computer running full fledged ROS2. On a robot with ROS using rosserial, there still needs to be a computer running the ROS master among other foundational features. Are there similar requirements for a robot with micro-ROS?

I suppose I wouldn’t really know until I set aside the time to dig into it, which has yet to happen. But the likelihood just increased. I knew that the official support for micro-ROS started with various ARM Cortex boards, but reading the system requirements I saw nothing that would have prevented the non-ARM ESP32 from joining the group. Especially since it is a popular piece of hardware and it already runs FreeRTOS by default. I have a few modules already on hand and I expected it was only a matter of time before someone ported micro-ROS to the ESP32. Likely before I build up the expertise and find the time to try it myself.

It appears that expectation was correct, a few days ago an announcement was posted to ROS Discourse that ESP32 is now officially part of the micro-ROS ecosystem. And thus another barrier against ROS2 adoption has been removed.