Sawppy Roving With Wired Handheld Controller

I now have a basic Arduino sketch for driving Sawppy using a joystick, I’ve built a handheld controller using an Arduino Nano and a joystick, and an input jack for interfacing with Sawppy. It’s time to put it all together for a system integration test.

Good news: Sawppy is rolling with the new wired controller! Now if there’s too much electromagnetic interference with Sawppy’s standard WiFi control system, we have a backup wired control option. This was the most important upgrade to get in place before attending Maker Faire Bay Area. As the flagship event, I expect plenty of wireless technology in close proximity at San Mateo and wanted this wired backup as an available option.

This successful test says we’re in good shape electrically and mechanically, at least in terms of working as expected. However, a part of “working as expected” also included very twitchy movement due to super sensitive joystick module used. There is very little range of physical joystick movement that maps to entire range of electrical values. In practice this means it is very difficult to drive Sawppy gently when using this controller.

At the very minimum, it doesn’t look very good for Sawppy’s to be seen as jittery and twitchy. Sharp motions also place stresses on Sawppy’s mechanical structure. I’m not worried about suspension parts breakage, but I am worried about the servos. Steering servo are under a lot of stress and couplers may break. And it’s all too easy to command a max-throttle drag racing start, whose sudden surge of current flow may blow the fuse.

I had wanted to keep the Arduino sketch simple, which meant it directly mapped joystick movement to Sawppy motion. But it looks like translating the sensitive joystick’s motion directly to overeager Sawppy is not a good way to go. I need to add more code to smooth out movement for the sake of Sawppy’s health.

Sawppy Wired Controller Enclosure

I now have an assembly of circuit boards that has all the electronics I needed to create a wired controller for Sawppy the Rover. Now I need an enclosure to make it easy to hold, protecting both my skin against punctures by header pins and also protecting the soldered wires from damage.

The first task is to measure dimensions and iterate through design of how I would hold the assembly using 3D printed plastic. It evolved into two separate pieces that mate up with left and right sides of my prototype circuit board.

The next step is to design and print two small parts to hold on to the wire. The idea is to have it take some stress so tugs on the wire do not rip my 4-pin JST-XH connector from my circuit board. And finally, an exterior shell to wrap all of the components.

Sawppy handheld controller unassembled

The exterior shell was an opportunity to play with creating smooth comfortable hand-conforming organic shapes. Designing this in Onshape was a bit of an square peg in round hole situation: standard engineering CAD is tailored for precision and accuracy, not designing organic shapes. That’s the domain of 3D sculpting tools, but I made do with what I had available in Onshape.

Given a bit more time I could probably incorporate all the design lessons into a single 3D printed piece instead of five separate pieces, but time is short and this will suffice for Maker Faire Bay Area 2019.

Now that I have one end of my wired serial communication cable, it’s time to look at the other end.

Sawppy handheld controller assembled

Arduino Nano Forms Core Of Sawppy Wired Controller

At this point in the project, I have an Arduino sketch that reads an analog joystick’s position and calculates speed and position for Sawppy’s ten serial bus servos to execute that command. Now I turn my attention back to the hardware, which up until this point is a collection of parts connected by jumper wires. Good for experimental prototyping, not good for actually using in the field.

The biggest switch is from using an Arduino Uno clone to an Arduino Nano clone. The latter is far smaller and would allow me to package everything inside a single hand-held assembly. Both Arduino are based on the same ATmega328 chip and offers all the input and output I need for this project. Typically, beginners like to start with an Uno because of its selection of compatible Arduino Shields, but that is not a concern here.

This specific Arduino Nano will be mounted on a prototype perforated and plated circuit board. It is placed on one end of the board in order to keep its USB port accessible. Two other components were soldered to the same prototype board: a 4-pin JST-XH connector for power and serial communications, and an analog joystick module.

My mess of jumper wires were then replaced by short segments of wire that are soldered in place for greater reliability. This is a relatively simple project so there aren’t very many wire connections, and they all easily fit on the back.

Arduino nano with joystick on PCB back

In theory the Arduino sketch can be seamlessly switched over to this board. In practice I saw bootloader errors when I plugged in this board. It turns out, for this particular clone, I needed to select the “Tools” / “Processor” / “ATmega328P (Old Bootloader)” option in Arduino IDE. As a beginner I’m not completely sure what this meant, but I noticed sketch upload speed is significantly slower relative to the Uno. My source code was unchanged and it all still worked. A few test drive sessions verified this little hand held assembly could drive Sawppy as designed.

Next step: an enclosure.

Prototype Arduino Wired Controller For Sawppy

Once I had basic control of LewanSoul LX-16A serial bus servo via analog joystick with an Arduino Uno, it was time to write code to perform trigonometry math necessary to calculate Ackerman steering angle and speed for each of Sawppy’s six wheels. Conceptually this is a port of code I wrote for the SGVHAK Rover project. However, that had the benefit Python, a high level friendly language.

The first concern came from reviewing Arduino Language Reference page. Under Trigonometry section it lists cosine, sine, and tangent functions but I didn’t see their counterparts arccosine, arcsine, and arctangent which I needed. I was never worried that I might have to reimplement my own math library: surely one would exist! They’re too useful and the Arduino ecosystem is too large for them not to.

It turned out I didn’t have to go very far in my search: underneath all the beginner-friendliness the board still runs an ATmega328 chip of the AVR microcontroller product line. And Arduino has not deviated from core language for programming that chip, so I could pull in the standard AVR <math.h> library to gain acos(), asin() and atan() functions.

I only had to duplicate the math for an Arduino counterpart, I didn’t try to replicate all the features of my Python code since some of them relied on the nature of Python for their flexibility. Still, even with the simplifications (or possibly because of them?) the code was different enough for some bugs to slip in. I ended up retracing through my steps using pen and paper to debug a few problems.

Once debugged, I had a crude wired controller for Sawppy. An analog joystick connected to my Arduino Uno with jumper wires provides user input. My freshly written code translates the joystick position to four corner steering angles and six wheel velocities, and sends out commands to all ten LewanSoul serial bus servos using Arduino’s UART TX pin connected to LewanSoul BusLinker via another pair of jumper wires.

Next task: make this Arduino wired controller more compact and more reliable with soldered wire connections to replace these jumper wires.

(Code for this project is publicly available in the arduino_sawppy subdirectory of Sawppy Rover’s Github repository.)

Arduino Control Of LewanSoul LX-16A Servo Via Joystick Commands

Once I climbed a few early steps on the Arduino IDE learning curve, I was off and running writing code. Fortunately the underlying code for programming an Arduino is still the C++ I’m familiar with. I picked up where I left off earlier with the analog joystick tutorial, now shuffled off to its own C++ class. I then looked over the sample code released by LewanSoul for controlling LX-16A servos in the form of a single flat Arduino sketch file.

I don’t plan on using most of the functionality of that sketch, but I thought it was easiest to lift the code wholesale rather than putting time into extracting just the parts I wanted to use. The code was written as flat top-level APIs, but it wasn’t difficult to write a small class that exposed a few methods which called into the two API I cared about. One to make a LX-16A move to a specific position, the other to make it rotate continuously.

There were a few rounds of experimentation on how exactly to communicate intent across this API. Using values as directly dictated by LewanSoul would have worked fine for this one case, but I didn’t want to be tied to one specific servo. Like my SGVHAK Rover software project, I wanted this code to be adaptable to multiple motor implementations which meant a more general description of motor action.

I tried percentages for both, ranging from -100% to +100%. For position servo, this would mean -100% is full deflection left, 0 is center, and +100% is full deflection right. And for continuous rotation, -100% is full speed reverse, 0 is stopped, and +100% is full speed forward.

Speed worked well but position did not: different servo will have different ranges of motion, so full deflection would mean different angles for different servos. So that was changed to angle in degrees. In the case of LewanSoul, -120 degree to +120 degree.

This was enough to let me control two servos with an Arduino, based on position of the connected analog joystick. This is sufficient control for my standard “rover wheel on a stick” test case, a good milestone before proceeding onwards.

(Code for this project is publicly available in the arduino_sawppy subdirectory of Sawppy Rover’s Github repository.)

Additional Source Code In Arduino Sketches Are Tabs Not Files

Being an electronics hardware tinkerer, there was no way for me to be ignorant about Arduino, but it never quite seemed to fit what I needed for a project: if I wanted computing power I used a Raspberry Pi, and if I wanted inexpensive low-level microcontroller I used a PIC. But I wanted to make Sawppy friendlier to beginners, and that was my motivation to finally start learning about the Arduino ecosystem.

I understand Arduino’s success is largely credited to how its creators underwent a clean-sheet examination at physical computing with the specific goal of making things easy for beginners to get started. A clean-sheet approach meant that tenure was meaningless. If the creators felt it was not helpful to beginners, it was gone regardless of whether it was a long standing tradition. I read this philosophy repeatedly as I was learning about Arduino, one example among many was this statement from Arduino API design style guide:

Some of these run counter to professional programming practice. We’re aware of that, but it’s what’s made it possible for so many beginners to get started with Arduino easily.

After I felt I had done enough reading to feel like I was properly oriented, I embarked on my project to started writing code for driving Sawppy using an Arduino. It didn’t even take 5 minutes before my well-worn habits ran into a collision with The Arduino Way. I wanted to put joystick tutorial code in its own header (*.h) and source (*.cpp) files instead of putting it in the top level sketch (*.ino) file… and I couldn’t do it.

I selected “File”/”New” in the Arduino IDE, but that created a new Arduino sketch (*.ino). I poked around in various options on the file creation dialog, hoping to see a “create new header file” or similar, but saw nothing dealing with file types. I could see how file types might be confusing to beginners, so it’s Arduino design in practice: avoid file types even if it disorients long time computer programmers.

And I was definitely disoriented. I was so stuck in my old ways I couldn’t figure out what might have replaced it in Arduino IDE. I eventually found my answer by downloading an existing Arduino project with multiple source files and opening it in the IDE: additional source files are tabs! In the Arduino IDE, a “document” is a complete sketch with all its parts. If source code is spread across multiple files on disk, they are represented as tabs when the document was opened.

So in order to create a separate set of files for my joystick code, I need to select “New Tab” and give it the filenames I intended. One tab for joydrive.h and one for joydrive.cpp.

My relationship with Arduino is off to a rocky start, but I’m sure we’ll work it out.


Learning How To Write Arduino Libraries and Tutorials

For small software projects like a typical beginner Arduino sketch, we can get away with putting everything in a single *.ino file. This was the way LewanSoul served up their Arduino sample code for controlling LX-16A serial bus servos. But as a software project grows in size, proper organization of software modules become more important.

While I don’t intend to tackle the task of writing a big Arduino sketch, I did want to get an idea of how to write my Arduino code in a way that can be reused in their own installable Arduino library. That’s a powerful part of Arduino’s software ecosystem, but I don’t want to just consume other libraries… I want to get a little practice in so I have the option to write my own libraries later.

I started by reading about the mechanics of creating an Arduino library. As expected of the world of low power microcontrollers, programming is done in C and a library has, at a minimum, a *.h header file and a *.cpp implementation file. This was all in order, an Arduino-specific twist is the IDE integration with keywords.txt. That I didn’t expect. Everything is packed in a ZIP file.

Next I moved on to Arduino’s API design style guide. This is less about the mechanical details, and more about how to structure an Arduino API. This passage caught my attention:

Some of these run counter to professional programming practice. We’re aware of that, but it’s what’s made it possible for so many beginners to get started with Arduino easily.

This might be what caused some of my irritation with Arduino code – design decisions that ran counter to my professional practice, but now I understand there’s a well-meaning reason for it.

From there reading moved to the Arduino style guide for how to structure tutorials that accompany code, then I went back to see the analog joystick tutorial I had referenced earlier, this time as an example of Arduino tutorial style.

Examining LewanSoul Arduino Library

When I first built Sawppy using LewanSoul LX-16A serial bus servos, I was not interested in using their PC software which was tailored to running pre-scripted sequences of motion. At the time I was not using an Arduino, either, so I wrote my own serial communication driver in Python based on LewanSoul’s PDF documenting their serial communication protocol.

This time around, I am using an Arduino and eager to take advantage of already prebuilt software to cut down on development time. In the same Dropbox where I found my LewanSoul Bus Servo Communication Protocol.pdf reference document, there was a file LSC series communication routines of Now that I’ve seen Arduino libraries packaged in a zip file, I looked inside to verify the structure of having *.cpp and *.h source files. It turns out they were packaged inside that zip file as another file This zip file within a zip file looked like an Arduino library, with LobotServoController.h header file and LobotServoController.cpp source, a keywords.txt for Arduino IDE syntax highlighting, and a few *.ino sketch files inside an example directory.

It all looked very promising at first glance but a closer look deflated the initial enthusiasm. The API only had commands for servo position, nothing for continuous rotation mode which is how Sawppy’s six wheels roll on the ground. And looking under the hood inside the code, the serial communication header is in the wrong format. The first two bytes are LewanSoul identifiers 0x55 0x55 as expected, but the third byte is length, not servo ID.

Digging a little deeper, I realized despite its location in the LX-16A Bus Servo subdirectory of LewanSoul’s Dropbox, this Arduino library was not for controlling LX-16A devices. They are, as the file name stated (but I overlooked) intended for their LSC line of controller boards for standard RC servos, not the serial bus servos.

Sadly, this promising-looking Arduino library will not help me.

Code for LX-16A servos actually lived in a different folder: bus servo communication routines held Arduino sketches matching the expected protocol. However, they were written as individual one big flat *.ino file, and not written as an Arduino library.

This is fine for sample code, but not well suited to be part of a larger project. It looks like I’ll need to learn to how to write an Arduino library after all, either to convert this LewanSoul sample code into a library or create my own from scratch (again).

Taking An Arduino Crash Course

Now that I’ve got the first few basic experiments up and running on my Arduino compatible board, I should invest a little time into learning what I’m dealing with here. Fortunately there is no shortage of informative pages on the web to take me beyond the simplistic “Hello World” blinking LED demo for an Arduino Uno. At the end of that tutorial, Arduino point the user towards to either further practice with the desktop IDE or go browse the project hub. I found the former lacking in technical information I desire and the latter was mostly irrelevant to the project idea I have on hand.

I then turned to one of my favorite resources: Adafruit’s extensive tutorials. Specifically their Arduino learning center. To get a grounding on what’s actually on an Arduino Uno board, “Lesson #0” orientation is a great start. For a little more advanced information on Arduino Uno hardware (and how it has evolved since the initial release) their hardware tips, tricks, and techniques was quite informative.

But the computing hardware was never the core strength of the Arduino platform, it was the extensive ecosystem of code libraries. These libraries allow users to assemble code modules together like LEGO pieces to build projects. People don’t have to know every nut and bolt of how to write software for everything, because it has already been done and available as an Arduino library.

The selection of Arduino libraries has grown enough there’s a dedicated library manager to keep things under control, and of course Adafruit has a walkthrough for the library manager as well. At this point I already saw how to interface with a simple potentiometer joystick, and I knew there exists a servo library for controlling standard RC servos. I also saw LewanSoul offers Arduino library to control the LX-16A servos. In theory, these code libraries should let me build an Arduino-based Sawppy controller with minimal coding. Let’s find out if the theory matches practice…

Casualty In Debugging 5V Supply for Prototype VFD Driver

Once we had functionality of our prototype VFD driver figured out, we turned our attention to the other problem that cropped up earlier in our initial integration with the original power supply transformer: our 5V rail could support the PIC microcontroller and associated chips, plus putting a voltage bias on the filament. But when put a Raspberry Pi on the circuit, our 5V sagged low enough to put our Pi into a power brown-out reset loop.

Since the MP1584 voltage regulator we used has proven capable of powering a Pi in the past, this was puzzling. So we started quantifying our system starting with measuring the amperage draw of our 5V circuit. It was well within the 3A maximum draw supported by the regulator, so our next thought was a dirty output wave. Putting the output on an oscilloscope, the 5V line looked pretty clean so that was not the explanation.

The next experiment was to isolate the 5V supply chain. Instead of supplying the MP1584 voltage regulator with power from the rectified output of a transformer rail, we’re going to use a two-cell lithium polymer battery. If this worked, we’ll know the problem is upstream in the transformer or rectifier. If it doesn’t, we’ll know the problem is the regulator or further downstream.

Unfortunately the experiment failed due to a wiring error, which destroyed the MP1584 voltage regulator. The title picture shows the entire regulator module with a U.S. quarter dollar coin for scale.

And here’s a close-up of the dead MP1584 chip. The glossy blob in the upper left is plastic that has melted and resolidified. The bump in the middle was a tiny volcano where smoke pushed up through the casing and escaped.

MP1584EN chip with melted hole

Looking on the bright side, we are no longer suspicious of the MP1584 chip’s functionality. We now know for sure it doesn’t work!

Debugging continued with help of a benchtop power supply delivering 5V. Probing with a volt meter through the circuit, and seeing voltage drop along the supply path, we decided our problem wasn’t any single wiring errors in the circuit. We just had too many thin wires and connectors involved in the 5V supply path. We had put our Raspberry Pi at the end of the chain of 5V parts, and it couldn’t draw enough power to run. Not because of any single large obstacle but because of the cumulative effect of lots of little obstacles.

To test this hypothesis, we reversed the chain so our 5V supply entered the system at the Pi then propagated to the rest of the circuit. With this change — and no other change in the circuit — everything started working. This is a valuable lesson to a software person who is used to thinking in terms of digital logic: It’s easy to think 5V rail is 5V as long as there are wires connecting them. This simplification creates a blind spot: the real world is analog and our 5V rail will degrade to a 4V rail when too-thin wires are used!

With that problem solved, we can now start playing with VFD patterns. See what works and see what doesn’t.


Prototype VFD Driver PCB Debugged

We now pick up where we left off narrowing down a problem with our prototype vacuum fluorescent display (VFD) driver board. We had determined that segment H was the key. When segment H was illuminated, everything else works as expected. But when segment H was dark, segments A-G all became dark as well.

ULN2003Since segments A-G were all controlled by a single ULN2003 chip, we started looking closely at every solder joint on that chip. We were looking for an undesirable solder bridge or other electrical connection to any wire relating to segment H, which was managed by another ULN2003 chip.

The two ULN2003 chips were immediately adjacent to each other, meaning A-G were pins 1-7 on one chip, and segment H was pin 1 on the next chip. The densely packed nature of these chips meant pin 1 of segment H was immediately adjacent to the emitter (E) and common (COM) pins of the ULN2003 controlling A-G.

When describing the symptoms, [David] correctly diagnosed the problem must be an electrical connection between segment H pin 1 of one ULN2003, and pin COM of the adjacent ULN2003. Using a probe we verified this was indeed the case – those two pins should have no connection but they are electrically connected. However, we could not find where this connection was taking place. No solder bridges were found and no accidentally soldered wires were found.

Eventually [Emily] devised a hack: because a VFD is not an inductive load, we didn’t really need the COM pin at all. It was only soldered to the board for physical mounting, that solder joint has proven to be more trouble than it was worth. To bypass the undesired connection, wherever it might be, it is easiest to clip off the COM pin from that ULN2003. Maneuvering a cutter within the packed space, [Emily] snipped off the leg.

After that, every aspect of our prototype VFD driver was fully functional as planned. [Emily]’s hack was totally unconventional, but very effective!

Obsolete Arduino Board Is Alive And Reading Analog Joystick

Learning Arduino has finally moved from a back burner to the front, and as a first step I finally unpackaged a years-old purchase of an Arduino Uno compatible board. Enough years have passed that particular board has become obsolete, but the Arduino ecosystem is still going strong so chances are good that I can still use the board to learn.

The first step with new hardware is always testing out some sort of a “Hello World” demo program to make sure the basics are working. When it comes to playing with electronics hardware, the popular choice is to blink a LED. This is such an entrenched thing that Arduino has designed a LED into their boards perfectly suited for the purpose, and my Arduino-compatible board has copied that arrangement.

Following the “Getting Started” guide for an Arduino Uno, I installed Arduino’s Desktop IDE. The basic example blink program was only a few clicks away, and an Arduino Uno was already selected as the target board type. Once I selected the serial port to use for communication, I was able to click on “Upload”. After a few seconds, I could see the test LED blinking on my board. It lives!

Success of that fundamental test gave me confidence to move on and add some hardware. I had bought some small joystick modules for this purposes of building my own Arduino based controller. Like most joysticks, they are built around a pair of potentiometers which made them an easy match for Arduino joystick tutorial.

OSEPP Uno R3 Plus with joystick

As many reviewers warned in that Amazon product listing, these joystick modules are very sensitive to movement. Their electrical range of motion is a surprisingly small subset of their actual physical range of motion. In other words, the potentiometers reach their minimum/maximum electrical values when the stick has only moved barely a third or halfway into its physical range of motion. This will be good for quick reaction movements but not as good for fine pitched movement.

These joysticks might not be the best ones for the job of rover control, but they will work well enough for continued Arduino exploration.

Finally Opening My Arduino Compatible OSEPP Uno R3 Plus

With my newfound motivation to get rolling in Arduino programming, I am finally going to open up the plastic blister pack of my OSEPP Uno R3 Plus. I must have bought this item when it was on sale somewhere, thinking I would get into Arduino programming but ended up letting it sit on a shelf for years.

OSEPP Uno R3 Plus blister pack

Today the product web page lists it as a discontinued product whose production ended almost three years ago in June 2016. The packaging backside pointed buyers to the url which is not even a valid URL anymore and returns a HTTP404 error page instead.

OSEPP Uno R3 Plus specifications

If this had been a proprietary product I would have been worried if I could even use it anymore. But since it was based on Arduino, an open source product, I was not as worried. Based on its name and physical appearance I guess it was a derivative of the Arduino Uno, which is still an active part of the Arduino product line in Rev3 form.


The exterior dimensions of the circuit board look identical, as are the mounting holes, in order to be compatible with the Arduino shield ecosystem. Comparing it against the standard Arduino Uno I see a few modifications elevating this product above a mere clone. The power jack looks the same but the USB connector is different. Its reset button has been moved to make way for a connector labelled I2C. I see four surface mounted LEDs in the same place as the standard Arduino Uno, which will be useful as I recall the Arduino “Hello World” blinks one of them.

The only thing I’m not terribly thrilled about is the fact the processor is a surface mounted chip instead of socketed DIP of the standard Uno. A socketed chip would be easy to replace if I should damage it in some way, with this surface mounted chip I’m pretty confident I’d need to buy a new board.

I see a little bit of manufacturing residue on the circuit board, possibly solder flux that was not completely cleaned off. That and a few other cosmetic blemishes did not worry me in regard to board functionality. It looks ready to go, so let’s plug it in and see what happens.

I Found My Motivation To Enter World of Arduino: Make Sawppy Easier

When talking to people about fun electronics projects, it has come to people’s surprise that I have yet to do anything with an Arduino. It is the platform of choice for introduction to hardware computing and how many people got started in this hobby, but for one reason or another I never went through that phase.

Generally, if I need something with computing power or network connectivity, I use a Raspberry Pi 3. If I need low-level control over precision timing, I use a PIC. Sometimes those two are paired up, like our VFD driver board project. An Arduino’s capabilities fit in between those two platforms, but as I already have proficiency in coding for a Pi and for a PIC, it doesn’t leave much motivation for me to learn Arduino. But it’s something I kept in mind, expecting that one day an Arduino’s beginner friendliness will be an asset for me to build a project with one.

That opportunity has surfaced!

backyard sawppy 1600

As I took Sawppy around to various events, I had many opportunities to talk with people who show interest in a DIY motorized Mars rover model. My own personal ambition is to make Sawppy autonomous, but not everyone shares that goal. I learned that many people would be content with a remote controlled rover. Furthermore, I’ve seen a lot of interest in parents who wanted to gauge if Sawppy is a good project to build with their children. And in this scenario, my SGVHAK rover software running on a Raspberry Pi is far more complex than strictly necessary.

For this audience, a simple Arduino-based rover control system would fit a niche separate from that of a Raspberry Pi rover control scheme. It will be less powerful, but will also be lower cost and more approachable as a learning exercise for beginners.

So for the sake of making Sawppy more accessible to everyone, I’m going to start investigation into an Arduino-based control scheme.

Google AIY System Image Still Fragile

After exploring a Google AIY Voice kit’s capabilities and found it promising for future projects, I thought it was a pretty good deal at the clearance price of $15. Sadly for Google and Target, I still think its original price of $50 is high for what we get in the box. And that’s before I ran into what appears to be a recurring problem with the Google AIY kits: their customized build of Raspbian is very fragile and has a history of failing after system updates.

Google AIY Voice Bonnet

Of course, I didn’t realize the root cause immediately. When I initially booted up my box, with USB keyboard+mouse and HDMI cable attached, I ran through its initial setup procedure which helped me log on to my local network, change the default password to something other than ‘raspberry’, tasks of those nature. One of these steps was whether I wanted to download and install updates. Even though I followed instructions to download the latest system image, as of right now the “latest” is still from this past November and missing quite a few security patches since. I had continued playing with the hardware while updates installed, fiddling with things as I went. Eventually I had to reboot the box and when it came back up, everything has fallen apart.

I was in the middle of playing with aplay and arecord so my first symptom was a complaint of missing sound hardware. Since by then I had already established that they are standard Linux sound devices under ALSA (Advanced Linux Sound Architecture) I started looking up resources online to debug ALSA sound hardware running on a Raspberry Pi. This, I have since found out, is a huge bag of hurt best summarized by the following passage from this StackExchange thread:

However, at no time in history has mankind produced such an amount of useless and dysfunctional diagrams, as for trying to explain ALSA.

That’s just one man’s opinion, of course, but after several hours of banging my head against ALSA brick walls I saw nothing to contradict that opinion. Even Adafruit, typically the benchmark of clear concise tutorials, could only offer this mess which falls far short of their typical standards.

I was almost ready to give up on the whole works when I remembered to run a LED test and found that also failed with an error message Leds are not available on this board. That’s when I finally realized it’s not just the sound hardware, everything on board Voice Bonnet has gone offline. I’m not enough of a Linux expert to understand the details of what went wrong, but apparently certain types of system upgrades would wipe out all the customization required to support Voice Bonnet hardware.

This comment on a Github issues discussion thread suggested running a whole bunch of sudo dpkg-reconfigure commands to bring them all back. This might be worth trying some point later. But for today’s experimentation I re-imaged my microSD card and set up the box again – this time declining to download and install all updates. It’s a very insecure workaround, but today I only need to continue experimenting with the hardware. I’ll have to see if this problem is updated when I want to use this hardware for an actual project.

Bottom line: it’s very disappointing to have Google’s custom AIY version of Raspbian stop working on Google AIY hardware after certain system updates. I’m sure some number of these incidents resulted in the product getting returned to Target under their generous refund policy, which wouldn’t be very helpful to retail success at all.

Examining Google AIY Voice Bonnet LED and Pins

The default demo for a Google AIY Voice kit turns a Raspberry Pi Zero in a cardboard box into a Google Voice Assistant. I wasn’t terribly interested in that at full price, but at clearance discount they were interesting enough to purchase. I had fun looking over its “Voice Bonnet” audio accessory board to verify it is easy to re-purpose to sound-based projects of my own choosing. Once that primary goal was complete, I looked at some of the auxiliary features on that accessory board to see what’s going on.

Google AIY Voice Bonnet

First up is aiy.board which interfaces with the big plastic button. It looks like the kind of button found on an arcade console and I would expect it to be durable for many cycles. The source file has all the code dealing with the messy realities of dealing with a physical button, including logic to handle debouncing.

Next is aiy.leds. When assembling that button, I noticed it had more pins than strictly necessary for a button and it turns out the button also incorporates a RGB LED array. While aiy.board has code to deal with that LED array, comments indicate there’s a better API available elsewhere for the RGB LED in the aiy.leds source file. Indeed there appears to be better support for lighting effects like blinking, pulsing, and color blending.

Finally aiy.pins allows access to the GPIO pins exposed by Voice Bonnet. I had originally thought these were passed through from the Raspberry Pi GPIO bins, but further reading indicates I was wrong. These pins are controlled by the SAM D microcontroller on board the bonnet, and aiy.pins expose them for use in a way compatible with Raspberry Pi’s gpiozero library.

This looks like a pretty decent set of auxiliary functionality available on the Voice Bonnet, certainly enough to handle some simple projects without pulling in additional hardware. Also, the RGB button and auxiliary pins are apparently shared between the Voice and Vision bonnets so common code can drive both. This may prove useful somewhere down the line.

Google AIY Voice Bonnet Will Be Easy To Repurpose

Google’s AIY products were an experiment to bring a hands-on building experience to retail storefronts. It’s the kind of thing one would expect to find at Radio Shack, if Radio Shack were still alive. Sadly, with the AIY Voice kit marked down for clearance at my local Target, the experiment did not appear to be a resounding success. Still it means I now have a Google AIY voice kit to play with.

Just for the sake of seeing how it was supposed to come together, I followed assembly instructions even though I had no interest in building my own Google voice assistant for my home. Or at least, I got it set up far enough to have the mechanical box on my home network. I stopped before completing the steps to sign up for Google Assistant API access and enrolling this piece of hardware.

What it means is that I now have a Raspberry Pi Zero on my home network, coupled with “Voice Bonnet” audio hardware that I can now learn more about.

Google AIY Voice Bonnet

It appears all the code to interface with this Voice Bonnet is documented and available online. I went straight to the APIs to see how one interacts with the audio capabilities. I had expected to find code interfacing with device drivers and hardware registers, I didn’t expect that the source file mostly consists of code that calls out to standard command-line audio utilities arecord and aplay.

I then looked into the default text-to-speech capabilities inside aiy.voice.tts and found much of the same: text is sent out to a command-line utility pico2wave which does all the hard work. It generates a sound file, which is then sent to aplay for playback.

This is great news: this meant it will be trivial to use the audio recording and playback capabilities of this Voice Bonnet for purposes other than interacting with Google voice assistant platform.

Salvaged VFD Power Supply And Debugging

Our first system integration test of a salvaged vacuum fluorescent display (VFD) and our prototype driver PCB was a success. At least going by our initial target of having our VFD segments illuminated and cycling through a test pattern to verify things are not stuck always on or off.

Once we had that basic level of functionality, [Emily] started working on the power supply side of the system. We have an original transformer salvaged from the same device which outputs multiple AC voltages. The first is a 2.5V AC line we could use directly on VFD filament. After that, Emily salvaged a few more components to deliver the ~30V DC we need for control grid and segments, and the ~24V DC we fed into a buck converter to get 5V DC for filament bias and micro controller logic power.

VFD on transformer

We’re very close to a complete power solution for a VFD project, but not quite there yet. When we added a Raspberry Pi 3 to the mix, its power demand was too high for this system to handle. Power sagged to 4.2V and the Pi entered a power brown-out reset loop. We’re not sure what’s wrong with this setup yet, but in the meantime we connected an alternate 5V DC power source to look at how the rest of the system behaves.

This allowed us to see a problem in our prototype driver board. I had a new test pattern generated with the help of my tool created in Google Sheets, but the test program did not display as I expected. After some time sending various diagnostic patterns to the VFD, we figured out the key to the situation is segment H.

NEC VSL0010-A VFD Annotated

Whenever segment H is illuminated, everything else functioned as expected. But if segment H is dark, segments A-G are all dark regardless of commanded pattern. Segment I and J are unaffected.

Once this was determined, we ran a test pattern where H is commanded to be dark and everything else should illuminate. The test pattern is the same for every segment, so the circuit would be at a steady state for us to probe with a meter as the PIC cycled through segments.

Using segment A as an example, we probed to verify its output pin from PIC (RC0) is low as expected. We then traced that signal to the ULN2003, whose corresponding input pin is low as expected. With input low, the corresponding ULN2003 output pin should not be tied to ground. Which means we expect VFD pin for segment A to be sitting at near 30V DC due to a pull-up resistor.

This is where we went off script, for VFD pin A has been pulled low. Unplugging the wire between ULN2003 and VFD allowed the segment to illuminate. This narrows down the scope of our problem: it has something to do with that ULN2003 chip, but we ran out of time for tonight’s SGVHAK session before we could narrow it down any further.

To be continued!

Hello Google AIY Voice Kit

As someone who have played with electronics modules purchased online for a wide variety of projects, I was fascinated by Google’s AIY projects a.k.a do it yourself artificial intelligence line of products. Here in the United States, Google is not doing it alone. The products themselves are not enough if it isn’t in front of people’s faces, so there was also a partnership with the retail giant Target to have these kits on the shelves of Target stores. I didn’t think there is large enough of a market for these products willing to pay the prices it would take to justify a retail presence, but I admire the willingness to put up the money for an experiment to find out.

There were two kits: the AIY Voice kit and the AIY Vision kit. The vision kit costs roughly double that of the voice kit ($90 vs. $50) but it was far more interesting with an onboard Pi camera and a TensorFlow processor designed to accelerate machine vision tasks. When the vision kit became available at my local Target, I immediately purchased one so I could play around with its default demo software. Sadly my TensorFlow knowledge is still too weak for me to make the vision kit do my own bidding.

As for the voice kit, I knew it was also built around a Raspberry Pi Zero with a hardware accessory board, but that board was focused on audio capture and playback not significantly different from a sound card. I was not aware of any audio processing capability on board, so I expected the audio to be recorded and uploaded to Google for processing. This capability was not interesting enough for me to buy one at $50.

It’s been over a year since the retail experiment began, and my local Target has marked the AIY Voice kit for clearance sale at $15 each. (I later found out Micro Center was even more aggressively clearing them out at $5 each.) I guess this means we have an answer to that experiment. I’m a little sad to learn of this, because I would have loved to be proven wrong. If there was indeed a market for a successful product in this area that would have meant more interesting products for me to purchase locally. Alas, it looks like I’ll continue to buy esoteric little electronics gadgets online.

Still, right now I could pick up an AIY Voice kit for $15. The Raspberry Pi Zero at the heart of the device has a retail value of roughly $10 all by itself. Add in the microSD card and we’re pretty close to $15 before considering the rest of the kit. I passed on the AIY Voice kit at $50, but I’m willing to buy them at $15. Worst case scenario, I will have a Raspberry Pi Zero W and matching microSD card.

Here’s what I saw when I opened the box:

Google AIY Voice Kit

There were no surprises. Aside from the expected Raspberry Pi Zero W and microSD card, we have the hardware accessory called a “Voice Bonnet”.

Google AIY Voice Bonnet

The remaining hardware components are a single speaker and a big button (that turned out to have LEDs in it) and they plug into this bonnet.

Let’s see what this kit has to offer.

Adafruit Spooky Eyes On Raspberry Pi

[Emily] and I were first exposed to Adafruit’s “Spooky Eyes” in the context of their HalloWing given out to all Superconference 2018 attendees. We think it looks like a lot of fun and thought it would be nice to make it available on other hardware platforms. We looked under the hood to see how it has been packed tightly for low power microcontrollers, but as a result of its simplicity it was a fairly simple task to translate encoded Spooky Eyes data into PNG image files. This would make the image data more easily usable on less constrained hardware like a Raspberry Pi.

But as it turned out, Adafruit was way ahead of us. They already offer Spooky Eyes running on a Raspbbery Pi! I thought I had looked for this earlier but if so I had missed it.

Adafruit Raspberry Pi Eyes

Reading the details of that tutorial, a few interesting items of note:

  • Just like the HalloWing, there’s provision for light reactivity. However, a HalloWing has an onboard light sensor but a Raspberry Pi does not. The user would have to install a photocell.
  • By default the eyes move randomly, but there’s also provision for a joystick to steer their gaze direction. Again this is an analog joystick the user would have to install.
  • By default the eyes blink at random intervals, but there’s also the option to add buttons to trigger eyelid blinks.
  • Even though the product image shows a Raspberry Pi zero, the documentation says A Raspberry Pi 3 or Pi 2 is highly recommended. The code will run on a Pi Zero or other single-core Raspberry Pi boards, but performance lags greatly.
  • It is designed for Adafruit’s little display units, but the code could just as happily render to a Raspberry Pi’s standard HDMI output. Bypassing all the Adafruit hardware is possible as described in the Using Just the Software section.

Browsing through the source code repository, I see it uses quite a few Raspberry Pi specific code libraries. In addition code dealing interfacing the Adafruit display units, there’s also GPIO code to handle the joysticks and buttons above. And lastly, rendering is handled by the pi3d library to take advantage of a Raspberry Pi’s GPU. If I wanted to make Spooky Eyes run on, say, my Linux laptop, all those pieces of code would require modification.