Panasonic UJ-867 Optical Carriage (Briefly) Under A4988 Control

Once I extracted the optical assembly carriage of a Panasonic UJ-867 optical drive, the next step is to interface it with a Pololu A4988 driver board. And just as with the previous optical drive stepper motor, there are four visible pins indicating a bipolar motor suitable for control via A4988. However, this motor is far smaller as befitting a laptop computer component.

Panasonic UJ-867 70 stepper motor connector

The existing motor control cable actually passed through the spindle motor, meaning there were no convenient place to solder new wires on the flexible connector. So the cable was removed and new wires soldered in its place.

Panasonic UJ-867 80 stepper motor new wires

Given the fine pitch of these pins it was very difficult to avoid solder bridges. But it appeared to run standalone so I reinstalled into the carriage. Where it still ran – but was very weak. Hardly any power at all. When I tilted it up so the axis of travel is vertical, the carriage couldn’t win its fight against gravity. Since the job is only to move an optical assembly, I didn’t expect these carriages exert a great deal of force. But I’ve seen vertically mounted slot loading optical drives. I thought it should at least be able to fight against gravity.

A Dell laptop charger delivers 19.2V. I’m not sure how many volts this motor intended to run at, but 12V seemed reasonable. Then I increased current beyond the 50mA of the previous motor. Increasing both voltage and amperage seemed to help with more power, but it remained too weak to overcome gravity.

As I’m tilting the metal carriage assembly in my hand, I started noticing it was warming. Oh no! The motor! I checked the temperature with my finger, which was a mistake as it was hot enough to be painful to human skin. I shut down my test program but it was too late, the carriage never moved again.

Lessons learned: don’t get too overzealous with power and check temperature more frequently.

And if I want to continue these experiments, I’ll need another stepper motor assembly.

Panasonic UJ-867 Optical Drive Carriage Extraction

The Panasonic UJ-867 is a slot loading optical drive. This particular unit was salvaged from a dead Dell XPS M1330 previously featured when I pulled its power port, and disassembled its battery, plus trying to use its AC power adapter to charge a Neato vacuum. A web search indicated this drive was better known as a drive used in certain models of Apple MacBooks. An optical drive typically has a carriage for its laser assembly driven by a stepper motor, and that carriage is my target for further stepper motor experimentation.

Panasonic UJ-867 20 Norton inside

When the lid was removed, the age of this device was clear: it still held a disk! The Windows edition of Norton AntiVirus confirms this was not from a MacBook. The year also spoke to the vintage of this drive.

Panasonic UJ-867 30 mechanicals top

With the disk removed, we can see all the mechanical linkages. This was far more than I had expected, because I had never taken apart a slot-loading drive before. Many of the pieces were involved in the slot loading mechanism, which is in the “disk inserted” position. (The Norton disk was not properly ejected – I removed the lid and popped it off!) Various mechanisms in this position block fasteners making it difficult to take apart.

Panasonic UJ-867 40 eject motor

Tracing through the mechanical bits, I guessed this motor is the heart of the drive loading and ejection mechanism. It is a simple DC motor so I should be able to put power on these pins to move the mechanism to their eject state. However, there are a few parts nearby that I might bump into if I powered from the top, so to be safe I soldered some pins from the bottom.

Panasonic UJ-867 50 eject motor wired

Applying power to this motor did indeed run through the ejection sequence, even though I’ve already removed the disk. Now it became fairly straightforward to take apart the drive.

Panasonic UJ-867 60 eject motor gearbox

Almost all of the pieces are specifically tailored to this usage, making reuse unlikely. But I do enjoy seeing the eject motor gearbox run. This is a distraction, though. The optical carriage was the goal and that was removed for the next step: connecting it to my Arduino + A4988 test breadboard.

Resuming Pololu Stepper Driver Adventures with Arduino and A4988

By the time I got around to playing with homing switches on a salvaged industrial XY stage, it was getting late. I only had a few minutes to perform one experiment: connect the normally open homing switch to X_LIMIT_PIN (GPIO02 as per cpu_map.h), set HOMING_CYCLE_0 to X_AXIS in config.h, and sent command to home X-axis. The motor moved right past the switch into the hard stops, so I turned off the ESP32 marking an unsatisfying end to the work session.

I wanted to be able continue learning Grbl while at home, away from the salvaged hardware, so I dug up the A4988 motor control board I’ve played with briefly. It’s time to get a little further in depth with this thing. Motivated by my current state in the XY stage project, the first goal is to get a stepper motor to activate a homing switch. If I could get that far, I’ll think about other projects. People have done some pretty creative things with little stepper motors controlled by Grbl, I could join that fun.

Rummaging through my pile of parts, the first stepper motor I retrieved was one pulled from an optical drive. This particular stepper motor had only the drive screw, the carriage has been lost. But with four exposed pins in two groups of two, it is a bipolar motor suitable for an A4988 motor control board. I just had to solder some wires to make it usable with a breadboard.

Since this stepper motor was a lot smaller than the one used in my previous A4988 stepper motor experience, I thought this was a good opportunity to learn how to tune the current limits on these modules by following instructions published by Pololu and using an Arduino as a test controller running code published on this page. I started with a limit of 100mA, but the motor got quite toasty at that level after running for a minute. I turned it down to 50mA, and it no longer got hot to the touch running that Arduino sketch.

This is a good start, but a motor with just a drive shaft is not useful for motion control. The next step is to find something that could push on a limit switch. I don’t seem to have anything handy, so it’s time to start digging into salvaged hardware.

XY Stage Position Detection Switches

When I built my prototype Grbl ESP32 controller on a breadboard, I thought I would get X and Y axis to start moving before looking at other parts of the system. Once I got X moving, though, I changed my mind. Instead of getting Y to run, I wanted to make sure I understand more of X. Which meant learning about limit switches and homing routine in Grbl.

But first, a look at the actual hardware, which meant picking up the other wiring harness leading inside the linear actuator. There were nine wires, only six of which were connected from its previous usage. Three of the six were connected together resulting in a total of four unique pins.

On the assumption the three wires twisted together is a common ground, I probed between it and the remaining wires. I found two of them were closed circuit and the remaining one was open. This is consistent with a homing switch and two limit switches. The homing switch is normally open and, during homing operation, the controller looks for that switch to close. When that happens, the controller knows where home is. The limit switches are normally closed because that allows them all to be wired together in series. If any limit is reached, the circuit opens, and the controller stops. For the purposes of machine protection, it didn’t really matter which limit was reached, as long as it was detected.

With the ZETA4 unplugged, the stage could be moved by hand. Watching the output from a meter wired up to these pins, I looked for positions where these switches were tripped. The initial results were very disappointing! The limit switches would trip when there were still over ~10cm of travel remaining, and the home switch is ~5cm further inside of that range. This severely constrains the usable area to a very small subset of total area. When I reported this finding to the rest of SGVHAK, I was told “Oh. Why don’t you move them, then?”

Move them?

I didn’t know these switches are adjustable to fit specific installations. In its previous life, this tables only needed to deliver a small range of its overall motion and were set appropriately. An allen wrench was all I needed to remove the cover and look inside: I saw three devices labeled Hamlin 59135, still in production and available from Digi-Key for $7.48 in single quantities. Each of these is a reed switch with a normally-open and normally-closed wire in addition to their common wire.

This explains the nine wires in the bundle: three wires for each of the switches, and the previous installation only used the common wire plus one of the other wires, leaving the remaining unconnected.

I loosened the screws holding these reed switches in place, and move them as far to the ends as I could push them with existing wiring. This still leaves approx ~3cm on either end, but I’m content to leave them as safety margin. The physical size of the home reed switch meant it couldn’t get within ~4cm of the limit switch. I don’t know if this is a problem yet. Next step: figure out how to interface these switches into Grbl.

Successful First Commands From Grbl ESP32 To Parker ZETA4

Once I could bring my breadboard prototype Grbl ESP32 controller into the shop where the salvaged XY stage lives, I was eager to hook up some wires to see if anything moves. While I put provisions for two axis on my breadboard, it felt like a good idea to start with just the X axis. It moved, but not accurately, because I had not configured the two components to match.

These stepper motors have 200 steps per revolution. ZETA4 controllers can easily handle full steps, but there are a lot of options for microsteps configurable with switches. The headache here is the lead screw: it is an old Imperial unit with a pitch of 5 revolutions per inch, but Grbl is a metric minded piece of software with everything in terms of millimeters. Using a conversion rate of 25.4 millimeters per inch, the most obvious ZETA4 microstep option that divided evenly is 25,400 steps per revolution.

The good news is that Grbl ESP32 appears fast enough to generate pulses at this speed, which is orders of magnitude beyond what I can generate with AccelStepper on an ATmega. But even with tests along a single axis, the system would halt at various times and I don’t always understand why. For example: one of the halts gave an error of “Door Open” but Grbl configuration file explicitly said to ignore the door sensor switch, so why is it stopping motion? There are more to this system I don’t yet understand.

So for the sake of eliminating potential problems, both the ZETA4 and ESP32 were configured for 2000 steps per revolution, or 10 micro steps in between whole steps. We know this is easily within the timing capabilities of the chip and, while it may introduce some error converting between Imperial and metric, it’s not the biggest problem right now so we’ll deal with it later.

These intermittent errors will likely continue as I run this system, and I will have to diagnose and debug as I go. In parallel with this, I’ve changed my plan: as my next step I will not connect the Y axis step/direction motion control pins. Instead, I will continue to refine X axis operation by getting position homing to work.

ESP32 Grbl Controller Breadboard Prototype

An ESP32 plus Grbl motion control software seems like a good candidate for running an old industrial XY table, definitely promising enough to move forward with prototyping. I had originally intended to use an Olimex ESP32 DevKitC, as it was equipped with two rows of sockets. This is easy to connect with jumper wires while not leave pins exposed to risk of short circuits.

This plan was short lived, because I quickly ran into a problem: The ATmega at the heart of an Arduino is a beefy 5V part that can supply up to 40 mA per pin. In contrast, the ESP32 is rather delicate 3.3V part that should not exceed 12 mA per pin. The data sheet for the ZETA4 controller I want to connect to this board expects a minimum of 3.5V to signal step and direction, which means I need external components to shift the ESP32 voltage level up to what the ZETA4 expects. When I made this discovery I was momentarily tempted to switch back to an ATmega solution, but the siren call of higher performance carried me forward.

Since I would need external components, the project brain switched to my HiLetgo ESP32 development board which is mostly identical but came equipped with two rows of pins appropriate for a breadboard. Four level-shifting units were installed, each built around a 2N2222A transistor. They were connected to the step and direction pins for X and Y axis, and each received a LED (and corresponding current-limiting resistor) to indicate activity.

Staying consistent with the system I used for Glow Flow, red LEDs indicate X axis activity and green LEDs indicate Y. These LEDs allowed me to perform a quick test to verify the presence of blinking activity. Next step: connected them to ZETA4 controller to see if the motors move as commanded.

Evaluate Grbl For XY Stage

I considered driving an old industrial XY table from a 3D printer controller board. I have a Melzi board on hand to use but its onboard stepper drivers were too well integrated to be easily adapted to this project. I considered running Marlin on an Arduino directly, but if I’m going to start building my own control board instead of one already tailored for Marlin, it makes sense to look at other options. Given the popularity of the Arduino platform, there’s more than one motion control project out there for me to consider.

Enter Grbl.

Unlike Marlin, which is primarily focused on 3D printing, Grbl offers a more generalized motion control platform. Provisions already in the code include pen plotting, laser cutting, and 3-axis CNC milling. All of which could be done with Marlin as well, but with different amount of code modifications necessary.

But an even bigger advantage in favor of Grbl is the existence of an ESP32 port. Marlin’s development team is working on a 32-bit hardware abstraction layer (HAL) to take it beyond ATmega chips. It looks like they’re up and running ARM Cortex boards and have ambition to bring it to ESP32. But a Grbl ESP32 port is available today and stable enough for people to use in their projects.

The headline feature is, of course, speed. While AccelStepper topped out around 4 kHz pulses, Grbl on ATmega is good for approximately 30 kHz. Grbl on ESP32 claims “at least 4x the step rates” which is likely a very conservative claim. After all, we’re comparing an 8 MHz 8-bit chip to a 240 MHz 32-bit chip. Though running on the ESP32 does incur more overhead than bare-metal code running on an ATmega, which is important in time-sensitive applications like motion control.

There are upsides for this real time operating system (FreeRTOS) overhead, as it allows the ESP32 to handle things beyond motion control. The best part employs its WiFi module to present a web-based control interface. A control interface would have required additional hardware in a Grbl machine built around an ATmega, but with Grbl on ESP32 I just need a web browser to start testing.

And since I already have an ESP32 development board on hand, this looks like a great venue to explore. Let’s try running this XY stage with an ESP32 running Grbl.

Evaluate Retired Melzi Board for XY Stage

In an effort to put a salvaged industrial XY table back to work, the Arduino AccelStepper was used as a quick test to see if the motors and controllers still respond to input signals. Things moved, which is a good sign, but the high precision of the Parker ZETA4 controller demanded step pulses at a far higher frequency than what AccelStepper could deliver.

The search then moved on to something that could generate the pulses required. I’m confident the hardware is capable of more, as AccelStepper topped out at less than 5 kHz signal on a 8 MHz chip. Pulsing a pin isn’t a task that requires over 1,000 instruction cycles. Given familiarity with the 3D printer world, I started looking at Marlin which runs on Arduino hardware.

The problem with running Marlin on my Arduino Nano is that I would have none of the associated accessories. No control panel, no SD reader, etc. However, I do have a full control board retired from one of my 3D printers. This board called itself a Melzi Ardentissimo and a search led to the Melzi page of RepRap wiki. Thanks to the open nature of this design, I could trace through its PCB layout. Much to my disappointment, the step and direction signals connected straight from the tiny pin on the main processor to the motor driver without surfacing in an easily tapped fashion. The intent of this board is integration and it’ll be quite some work to defeat that intent in order to decouple the processor from its integrated stepper driver.

Fortunately, I’m not limited to the world of AVR ATmega chips, nor Marlin software. There’s another very capable processor on hand waiting for such project… an ESP32 running Grbl software.

Arduino AccelStepper Under The Scope

The standard Arduino library includes a stepper motor control library. The external AccelStepper library adds the capability for acceleration and deceleration curves. I thought that would be important for driving industrial equipment as the large pieces of metal impart far more momentum than what I’m familiar with in a 3D printer.

As it turns out, I was worrying about the wrong thing. I connected my bargain oscilloscope to the output pins of my (knockoff) Arduino Nano and watched the pulses go by as I issue different commands to AccelStepper. As I issued commands for faster and faster speeds, I could see those pulses come closer and closer together until they were almost but not quite 0.2 ms apart. Running a test program in a tight loop, an Arduino running AccelStepper is indeed failing to reach 5 kHz pulse speed.

A little web search indicated this is roughly comparable to what others are saying online. AccelStepper is good for roughly 3-4 kHz and things get dicey beyond that. For the ZETA4 controller, configured to 25,000 microsteps per revolution, this is simply not fast enough to get decent speed out of the box.

How does this happen? Further web search indicated this is because all the timing for AccelStepper is done in software. Perhaps for the goal of leaving the very precious hardware timer resources for other user programs? That’s merely speculation of the design decisions involved. But one thing is certain – AccelStepper limits meant it is not sufficient for generating high frequency pulses required to drive this particular salvaged XY motion control table. I’ll have to look at something more specific for motion control, possibly a 3D printer control board.

Old Industrial XY Stage Moves Again On Arduino AccelStepper

A decades-old piece of industrial equipment has failed and been retired, but its motion control table was still good and salvaged for a potential future project. It is a far cry from the kind of motion control equipment I see on a hobbyist 3D printer. Much more rigid chassis, more precise linear guides, finer pitch thread, far beefier motor, under the command of a much more capable control box. One example: the A4988 stepper motor popular in 3D printers features the capability to generate up to 16 microsteps in between whole steps of a stepper motor. In contrast this Parker ZETA4 unit features up to 255 microsteps.

Pulling from the electronic hobbyist world, I set up my Arduino to run the AccelStepper library generating stepper motor direction and pulse signals. It was connected to one axis of the XY stage for the first test. It was exciting when the motor started turning, but it was very very loud! I doubted it was supposed to sound like that. A bit of examination found two problems: the ZETA4 was configured to take whole steps — no microsteps — which is always noisy. And I amplified this mistake by accidentally choosing a speed that caused a resonance.

Once the ZETA4 was configured to its default of 125 microsteps, things were much quieter and smoother. It also slowed down significantly, because each pulse on the step pin moved 1/125 as far as it did before. (And a full revolution of the motor was only 200 steps.) The obvious answer was to increase frequency of those pulses, but I seemed to top out at around 5,000 pulses per second. This surprised me: The ATmega328 chip on board an Arduino is running at 8MHz. I would have expected it to easily generate pulses faster than 5 kHz. Time to put this guy under the oscilloscope and see what we see.

New Project: XY Stage

The next project seizes upon the opportunity to work with a piece of industrial equipment whose price tag is far too high for me to justify spending on a hobbyist project. It is a combination of two linear stages bolted together at right angles to each other, allowing precise motion control along two axis. A configuration like this usually ends up handling the X and Y axis, so I’m going to call this the XY Stage project.

It formerly controlled the movement in some sort of inspection machine. The machine is decades old and, when the ancient DOS PC running everything died, the machine was retired rather than repaired. The old computer, associated software, and camera system were not interesting: the world has long since moved beyond their capabilities. The XY stage, however, is still perfectly functional and was salvaged for potential use in a project. Its capabilities has not been entirely outdistanced by its modern counterparts.

The control logic entry point for the system are these Parker ZETA4 Drive Compumotor modules. The design has long since been retired. However, machines built on them are still running and there’s still a market for those modules. Available new for around two thousand US dollars, they are also available used for several hundred dollars. On the side of this module is an imposing looking chart detailing all the ways it can be configured. But if we can temporarily set them aside, we see the method of control are two pins: one for direction, and another for step.

ZETA4 step dir

That makes it a lot less intimidating! Control protocol for this big box is basically the same as the A4988 stepper motor driver boards popular in hobbyist 3D printers. From a system architecture perspective, this is “merely” a larger, more expensive, more durable, more precise, and more powerful cousin to the little fingernail-sized circuit boards in my 3D printer control box. It is completely within our capabilities to command such a device.

I don’t know what we might be able to do with a XY stage, but I know it is too good to be gathering dust. I want to see if I can get it to do my bidding, and once I have a better understanding of its strengths and weaknesses, I’m confident a suitable project will arise.

A Day At CRASH Space LA

Visiting CRASH Space LA has been on my to-do list ever since I was introduced to Barb and Jay at Maker Faire 2018. We’ve seen each other at numerous events since then and it was pretty ridiculous that I see them more often in San Mateo than our home town. The problem is that they are on the far side of the basin. Going to Culver City in the context of infamous LA traffic meant a visit is not “I’ll just stop by.” It is a day trip kind of expedition! Finally Emily and I visited during their “Mega Take Apart & Swap Meet” day this month.

I brought some things but Emily brought more, and they were more interesting. She tore into some sort of retired dental surgery tool with components indicating high voltage operation. We’re not sure why a dentist would need high voltage in our mouths, and we didn’t much care. (Or chose not to think about it.) What’s inside is far more interesting.

I dug into another box Emily had brought. Some sort of power supply that had all appearance of being an one-off homebuilt project.

After the take-apart event Emily went off to visit friends living in that part of town. I stuck around CRASH Space for their Video Dim Sum event where I learned there are a lot of very odd things available on YouTube. I expected this, so it was a 100% success on that front. However my taste rarely aligned with the people who submitted videos so my overall entertainment-to-time ratio was pretty poor. I did learn some interesting things that I would not have otherwise, so it was still a fun thing to try at least once.

Out of all the videos that were shown, just one of them were memorable and compelling enough for me to go find and rewatch. Here it is, my personal winner of Video Dim Sum:

Raspberry Pi Web Kiosk Boots Faster On Raspbian Than Ubuntu Core

My adventures into the lightweight Ubuntu Core operating system was motivated by a 14-year old laptop with Intel CPU. By multiple measures on the specification sheet, it is roughly equivalent to a modern Raspberry Pi. (~1 GHz processor, ~1GB RAM, ~30GB storage, etc.) As a test drive, I had tried setting it up as a web kiosk and failed due to incomplete graphics driver support. (Though I did get it working on a modern laptop.)

Which leads to the next question: how well does Ubuntu Core perform on a Raspberry Pi performing the exact same web kiosk task? And how does that compare to doing the same thing on Raspbian OS? They’re both variants of Linux trimmed down for less powerful hardware. Raspbian is packed with features to help computing beginners get started, and Ubuntu Core has almost no features at all to offer a clean baseline.

My workbench is not a comparison test lab so I didn’t have many copies of identical hardware for a rigorous comparison. Two monitors were close but not quite identical in resolution. (1920×1080 for the LG, 1920×1200 for the Dell.) The two Raspberry Pi should be identical, as should the microSD cards, but they’re not powered by identical power supplies. To establish a baseline, I set them both up for Raspberry Pi web kiosk using my top search hit for “Raspberry Pi Web Kiosk”. Then launched them side-by-side a few times to see how close their performance were from power-up to rendering a web page. (For this test, the Hackaday.com site.) This took approximately 40-45 seconds, sometimes one is faster and sometimes the other is faster. For some runs, the two systems were within one second of each other, sometimes they were almost 5 seconds apart. Establishing the fact this comparison method has a measuring error of several seconds.

With an error margin established, I removed one of their microSD cards and installed Ubuntu Core for Raspberry Pi 3 on it. Once initial configuration were complete, I installed snaps for the web kiosk tutorial I followed earlier for the Dell laptops. I was very curious how fast a stripped-down version of Ubuntu would perform here.

The answer: not very, at least not in the boot-up process. From power-up to displaying the web page, Ubuntu Core web kiosk took almost 80 seconds. Double the time necessary for Raspbian, and that was even with a full install of Raspbian Buster with zero optimizations. There are many tutorials online for building a Raspbian-based web kiosk with stripped-down list of components, or even starting with the slimmer Raspbian Buster Lite operating system which would only get faster.

There may be many good reasons to use Ubuntu Core on a Raspberry Pi (smaller attack surface, designed with security in mind, etc.) but this little comparison indicates boot-up speed is not one of them.

Ubuntu Core 18 Web Kiosk Experiment on Dell Inspiron 11 3180

While experimenting with Ubuntu Core 18 on a 14-year old Dell Latitude X1, I ran into problems and wanted to verify it was a hardware support issue and not a mistake on my part. So I brought my much younger Inspiron 11 (3180) up on Ubuntu Core 18 as well. It verified the issue was indeed hardware support and not my mistake, hampering functionality on the Latitude X1.

After I got my answer, I thought since I’ve already got this Inspiron 11 up and running, I might as well continue experimenting on it. I proceeded to follow through the rest of the steps in the tutorial for setting up a web kiosk on Ubuntu Core. Since this machine had recent hardware, I encountered no hardware issues and got a dedicated web kiosk machine up and running.

Browsing a few web sites, basic browser functionality seem to be present. The first missing functionality I noticed was a lack of sound. A little poking confirmed that Linux audio system ALSA is not installed as part of Ubuntu Core. If someone wants sound on their Ubuntu Core machine, they’ll have to install it. This is fits with my expectation for a bare minimum “Core” OS.

Another feature I noticed is the lack of persistent state. As far as I can tell, everything is ephemeral and lost upon reset. No cookies are preserved across sessions, and it appears the cache is flushed as well. Whether this is a bug or a feature depends on application. It would be desirable for public use web terminal where we really want to wipe everything and start over for every new user.

And it isn’t intended to be a general use web browser, anyway. The cursor can be hidden and so can the navigation bar. I enabled the navigation bar expecting a normal browser tool bar, but it is actually a very minimalist bar with a few buttons like back and refresh. There is no URL input field, as appropriate for a kiosk dedicated to serving specific pages.

Sometimes this is exactly what I would need making Ubuntu Core an ideal bare-minimum OS for an Intel-based machine. But in this day and age, those aren’t our only options. Projects along these lines are also commonly built with a Raspberry Pi. How well does Ubuntu Core work on a Raspberry Pi, compared to Raspberry Pi’s standard Raspbian OS?

Dell Latitude X1 Running Ubuntu Core 18: No Graphics But CH341 USB Serial Works

It was a pleasant surprise to see the Ubuntu Core 18 up and running on a 14-year old Dell Latitude X1, even more pleasant to see it is lightweight enough to be speedy and responsive on such old and slow hardware. But given its age, I knew not to expect everything to work on the stock i386 image. There’s no way they can package a comprehensive set of device drivers on such a compact package. I speculate it was not the intent, either. Ubuntu Core is targeted to embedded projects where it is typical to generate an OS image custom tailored to the specific hardware. So the fact it mostly works out of the box is a tremendous bonus, and the missing hardware support is not a bug.

That said, I’m not terribly interested in generating the custom device tree (or whatever mechanism Ubuntu Core uses) to utilize all peripherals on this Latitude X1. I’m more interested in working with what I already have on hand. During initial configuration I already learned that the wireless module did not work properly. What works, and what doesn’t?

Again I’m not interested in an exhaustive list, I just wanted to find enough to enable interesting projects. Getting this far meant text output and keyboard input functions in addition to wired networking. The next thing to try is to activate the graphics subsystem and mouse input. Looking on Ubuntu’s tutorial web site, I found the web kiosk example which would test hardware necessary to offer a useful set of web-related functionality.

Following the tutorial steps, I could get the machine to switch display modes, but it never got as far as showing a web browser, just a few lines I didn’t understand. At this point I wasn’t sure if I followed the procedures correctly or if the hardware failed, so I duplicated the steps with Ubuntu Core 18 running on my modern Dell Inspiron 11 (3180) laptop. I saw a web browser, so the procedures were correct and the hardware is at fault. Oh well.

Comparing what’s on screen after starting mir-kiosk on both machines, I see the gibberish lines on the X1 actually resemble the mouse arrow but distorted and scattered across interleaved lines. Lending to the hypothesis that video support on stock Ubuntu Core 18 i386 image needs some tweaks before it can support the video hardware on board a Latitude X1. The fact some lines showed up tells me it’s close, but I’m choosing not to invest the time to make it work.

The next idea is to test USB serial communications. I plugged in an Arduino Nano knockoff with the CH341 USB-serial chip and ran dmesg to learn the device was picked up, understood, and assigned a ttyUSB device path. This particular Arduino was already flashed with a sketch that sent data through the serial port, and as a crude test I used cat /dev/ttyUSB0 to see if anything comes up: it did! This is wonderful news. The Latitude X1 can act as high-level processor counterpart to a lower level controller communicating over USB serial opening up project possibilities. I’ll have to think on that for a while.

Baby Fix-It Robot Stand for Amazon Echo Dot (3rd Generation)

I loved the 1987 film * batteries not included. Upon the 30th anniversary of its opening, I posted to Facebook introducing the film to friends who might not have heard of it. A friend who shared my love for the film commented that the little smart home speakers look just like the baby robots in the film. Thus was planted the seed of an idea.

This past weekend there was a sale on Amazon Echo Dot. It brought the price tag down to $22, well into my impulse buy territory, and I decided to turn that idea into reality almost two years after the original conversation.

The project goal was to create a 3D-printed stand holding the speaker along with a pair of googly eyes. The shape will not copy any of the three baby robots, but must be immediately recognizable as a design inspired by them. I also decided to keep it simple, resist temptation of scope creep. This robot will not be motorized. It will not articulate. I wanted it to be printable on any printer without supports, so I will break up the design into a few pieces that should be easily assembled. I’m not going to put any surface details (greeble) on the robot, instead opting for simple cartoony lines.

These decisions to keep things simple made it possible to hammer out the CAD design in a single evening. The basic pieces are simple geometry on Onshape. Generous use of chamfer and fillet gave it the illusion of a more organic shape, especially in the body and around the eyes. I started printing with a small test piece to verify I measured dimensions for the speaker correctly. The first leg did not snap into place correctly and neither did the first pair of arms so they had to be revised. This is actually an unusually low number of iterations required relative to most of my 3D printed projects.

Baby Fixit Base Echo parts

My friend Sophi Ancel who made the original comment loved the result enough to ask for a variant designed for Google Home Mini speakers that she actually owns. Giving this little Amazon Echo robot a sibling seems like a worthwhile follow-up project. For now, I’ve created project pages on both Hackaday.io and Thingiverse.

Dell Latitude X1 Now Running Ubuntu Core 18

About two years ago, an old friend was returned to me: a 2005 vintage Dell Latitude X1. It struggled to run desktop software of 2017 but speed wasn’t the point – the impressive part was that it could run software of 2017 at all. It was never a speed demon even when new, as it sacrificed raw performance for its thin and light (for its day) construction. Over the past two years, I would occasionally dust it off just to see it still running, but as software got more complex it has struggled more and more to act as a modern personal computer.

When an up-to-date Ubuntu 16 LTS desktop edition takes over 10 minutes to boot to the login screen, I had to concede it’s well past time to stop trying to run it as a desktop computer. I hate to give up on this oddball hobby to keep an old machine running modern up to date operating systems, but an interesting idea came up to keep things going: How about running a lighter-weight text-based operating system?

The overburdened desktop Ubuntu was erased to make room for Ubuntu 16.04.6 server. This is a much lighter-weight operating system. As one point of measure, it now takes only about 55 seconds from pressing the power button to a text login prompt. This is much more tolerable than >10 minutes to boot to a graphical login screen.

After I logged in, it gave me a notification that Ubuntu 18 server is available for upgrade. I’ve noticed that my desktop Ubuntu took longer to boot after upgrading from 16 to 18, and I was curious if the text-mode server edition would reflect the same. Since I had no data on this machine anyway, I upgraded to obtain that data point.

The verdict is yes, Ubuntu 18 server takes longer to boot as well. Power button to login prompt now takes 96 seconds, almost double the time for ubuntu 16 server. Actually more than double, considering some portion of that time was hardware initialization and GRUB boot selection timeout before the operating system even started loading.

That was disappointing, but there is an even more interesting experiment: What if, instead of treating this old computer as a server, I treat it as an embedded device? After all, its ~1 GHz CPU and ~1 GB RAM is roughly on par with a Raspberry Pi, and its ~30GB HDD is in the ballpark of microSD cards used in a Pi.

This is the new Ubuntu Core option for bare-bones installations, targeting IoT and other embedded projects. There is an i386 image already available to be installed on the hard drive of this 14-year old Dell laptop. Since Ubuntu Core targets connected devices, I needed a network adapter for initial setup. It looks like the Latitude X1’s WiFi adapter is not supported, but fortunately its wired Ethernet port worked.

Once up and running, I timed its boot time from power switch to login prompt: 35 seconds. Subtracting non-OS overhead, booting Ubuntu 18 Core takes almost half the time of Ubuntu 16 Server, or approaching one quarter of Ubuntu 18 Server. Very nice.

Ubuntu 18 Core makes this old laptop interesting again. Here is a device offering computing power in the ballpark of a Raspberry Pi, plus a display, keyboard, and mouse. (There’s a battery, too, but its degraded capacity barely counts.) It is far too slow to be a general desktop machine, but now it is potentially a viable platform for an embedded device project.

The story of this old workhorse is not yet over…

Very High Capacity Emergency Escape Stairs at IKEA Burbank

A luxury of living in the Los Angeles area is having my choice of IKEA furniture stores. Loved worldwide, many fans have to make a long drive to their nearest IKEA (some of them crossing national borders to do so) but I have several within easy driving distance to choose from.

I typically get my IKEA fix at their Covina location, but recently I had some time to kill near their Burbank location and decided to stop by and check it out. “IKEA Burbank” moved from another building within the past few years to this new building. I’m sure this meant updates conforming to the latest building codes, but nothing stood out in the interior. It felt much like any other IKEA from the inside.

There are a few interesting notes outside, though. The parking lot featured ample wheelchair access and other modern amenities like electric car charging stations. Sadly the latter were occupied by selfish people who parked their non-electric cars in those spots. A roundabout managed traffic at the entrance, hopefully not too confusing to American drivers.

But what really caught my eye were the emergency escape stairways. Most emergency escape stairs are narrow and steep affairs that, in the best of times with no pressure, would be challenging to traverse. I hate to imagine who would get trampled on those stairs when flooded with panicked people in a rush.

These stairs, in contrast, are gigantic. Easily at least triple the width of any other escape stairways I’ve ever noticed outside of buildings. I associate stairs of this size more with prime locations within Disneyland, who are masters at crowd flow management. These stairs are wider than associated doorways, which makes sense as people can go through doorway faster than they can walk down stairs, requiring wider stairways to accommodate the same volume of bodies. Everything looks well set up for a speedy and orderly evacuation from this showroom warehouse.

It looks like a great contingency that most visitors will never notice, and as much as I’m fascinated by this design, I hope we never need to test the emergency evacuation capacity of this IKEA.

Documenting Glow Flow Online

My Pixelblaze (and its sensor board) demonstration project Glow Flow is now complete. Well, maybe not “complete” but I’ve decided to stop here instead of exploring other ideas to continue evolving project. For now I’ll keep Glow Flow as-is, but before I shift attention to other projects, I should finish documenting this one before I forget everything.

First thing to do is to create a Hackaday.io project page, with links to all the other resources. Then I gathered all the video I’ve shot through the project and edited them all together into a YouTube video. (Embedded below.) I personally prefer to read about projects, but I acknowledge that some prefer video and I want them to enjoy Glow Flow as well.

The Github repository where I had been tracking my Pixelblaze pattern code revisions also got an updated README.md. So anyone who encounters the project on Github will have links to all the other resources I’ve put online. And like every other file I’ve created on the free tier of Onshape, Glow Flow CAD data is publicly available too.

As an experiment I put Glow Flow on Hackster.io as well. It’s not terribly different from a Hackaday.io project page, with one notable exception: I’m expected to upload a schematic for a project before publishing it. This meant I had to fire up KiCad and re-learn its schematic editor to create a rudimentary schematic detailing how Glow Flow electronics components are connected. I didn’t think it was a very sophisticated circuit, but my judgement is not to be trusted as everything is still fresh in my mind. Chances are good I’ll forget details in the future and appreciate the schematic is available. I’ve also uploaded the schematic to the Github repo so it is saved in at least two different places.

This should be enough information for someone (including future me) to understand and build another Glow Flow if they so desire.

Glow Flow Project Complete

With an upgraded power system, Glow Flow can now run continuously at full brightness. This completes Glow Flow as a self-contained portable demonstration of Pixelblaze LED controller. I plan to leave it in this configuration for the foreseeable future, but the flexibility of Pixelblaze and the 3D-printed snap-together construction means it’d be easy to reuse the core components for another project in the future. The Pixelblaze is in no shortage of storage space for other patterns, and the LED strip wound around a cylindrical core can easily accept a different external “sleeve” tailored to a different design.

People have suggested some other visual patterns, some would work better with different LED diffuser exterior:

  • Illusion of a lantern, complete with a flickering flame inside.
  • Illusion of a fish tank, with colorful fishes swimming inside.
  • Glowing lava, matching my original plan.
  • Animated Jack-o-Lantern for Halloween.
  • Glowing green like a bucket of radioactive slime.
  • Glowing purple/pink like the Energon Cubes in Transformers cartoons. Of course, they’re supposed to be cubes and not cylinders.

Any of those are within the means of a Pixelblaze, but depending on specifics of a pattern, power requirements may different. Dramatically increased power draw would demand an upgraded power system as well, something to keep in mind.

There were two fascinating ideas to improve interactivity:

  1. Make colors flow past each other as in a lava lamp. This is similar to earlier suggestions of making different color pixels swirl and mix. This requires a substantial investigation into how to run a computational fluid dynamics simulation in a Pixelblaze pattern. I’m currently ignorant on CFD math so that will be a significant undertaking.
  2. Make the diffuser touch-sensitive so the illuminated pattern on LED cylinder can react to user touch. This is a significant upgrade to interactivity than merely reading an accelerometer. Experimentation with simple touch sensors imply smaller touch area is better. It would be challenging to make the entire exterior surface of the cylinder touch-sensitive, but the results would be worth the effort.

These are all great ideas for a future interactive LED project. When I’m bored with Glow Flow, I’ll remove the diffuser panel and their support ribs. Extract the core cylinder and do something else. It would still be a Pixelblaze project, but it would no longer be Glow Flow.

For now, I’ll keep the illusion of glowing liquid flowing inside a cylinder.