Sawppy Takes A Road Trip To Bay Area

Over the past few months Sawppy and I have been attending events in the greater Los Angeles area spreading our love of DIY Mars rovers. But now it’s time to go to the flagship Maker Faire Bay Area 2019 event. This will be a multi-day event away from home and that brings in a new set of concerns.

The first and most obvious concern is the multi-day length. Every previous public appearance was no more than an hour’s drive away from home, where I had all of my tools and parts to repair any problems at the end of the day. I could pack some tools and replacement parts but I can’t pack everything. It would be sad if Sawppy broke partway through the event in a way I couldn’t repair. On the upside, Maker Faire Bay Area would be the event to be where I could borrow or buy tools and components. Or even time on someone’s 3D printer to print replacement parts!

The second concern is the trip itself. I typically place Sawppy on a car seat however it can fit, and didn’t worry overly much about placement because the ride is short. Now Sawppy is looking at over six hours of driving, with associated six hours of bumps from the road. Would all the repetitive stress break something on Sawppy? To help alleviate this problem, I used my luggage suitcase to fill in the rear seat footwell creating a relatively flat surface for all six wheels to sit at even heights. To constrain Sawppy’s front-back movement, the battery tray and router was removed so everything fit cozily between the front and rear seat backs. To constrain side-to-side movement, the rear seat center armrest was lowered so Sawppy fit cozily between it and the door.

Over seven hours later, Sawppy arrived in the bay area and I was eager to see if everything still worked. My quick test was to reinstall the battery tray, router, and power up Sawppy to verify all components functioned. I was very relieved to see Sawppy start driving around as designed, seemingly unaffected by the long trip and ready to meet the crowds of Maker Faire.

Mounting Bracket For Sawppy Wireless Router

A natural part of a project like Sawppy the Rover is a long “to do” list. While its ever-growing nature might imply otherwise, things actually do get done when faced with motivation. For Maker Faire Bay Area 2019 my primary motivation was to get a wired controller up and running as backup in case of overcrowded radio frequencies. And now that I have a working (if imperfect) wired controller, I wanted to come back and tidy up the wireless side of the house.

After that initial episode of fighting on crowded 2.4 GHz band, Sawppy received a wireless router upgrade in the form of a dual-band Asus RT-AC1200. (Selected via the rigorous criteria of “It was on sale at Fry’s that day.”) Not only did this gave Sawppy greater range when operating on 2.4 GHz, it also meant Sawppy could operate on the 5 GHz band where there are far more channels to go share in crowded environments.

So that was good, and a wired controller backup is even better, but there’s a neglected part that I wanted to address before taking Sawppy in front of a big crowd: when I initially hooked up that Asus router, I connected all the wires and placed it in the equipment bay. No mount, just gravity. I intended to integrate the router properly some day and today is that day.

Sawppy wireless router

I want to mount this to the rear of Sawppy above most of the equipment bay, because that’s where real Mars rover Curiosity housed its communications equipment. Ever since I had a WiFi router at home, they seemed to have stayed roughly the same shape and size even though electronics have generally gotten smaller and more power efficient. So the first question I checked was whether the box is mostly empty space and we could transfer compact internals onto the rover?

Opening the lid did unveil some empty space, but not as much as I had thought there might be.

Sawppy wireless router opened

Furthermore, it doesn’t look like the antennae are designed to be removable. They’re firmly fixed to the enclosure, and their wires are soldered to the board.

Sawppy wireless router PCB

Seeing how unfriendly this design is to a transplant operation, I aborted the idea of extracting internals. We’ll use the case as-is, starting with designing and printing a base for the router. I originally intended to fasten the base using original router enclosure screws, but changed plans to using M3 screws like rest of Sawppy after I dropped one.

Sawppy wireless router new base

This base has two dovetails which can then fit in brackets that clip onto Sawppy’s extrusion beams.

Sawppy wireless router mounted

And voila! A rigid mount for my wireless router rigidly mounting it to Sawppy chassis instead of letting it bounce around in a tangle of wires like I’ve been doing the past few months. This is much more respectable to present to other attendees of Maker Faire Bay Area.

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.

Input Jack For Sawppy Wired Controller

I’ve got my handheld wired controller built and assembled, now it’s time to work on the other end and add a control input jack for Sawppy the Rover.

Again I wanted something relatively robust, I don’t want a tug on the wire to tear apart Sawppy internals. Fortunately the whole “tugging on wire” issue is well known and I could repurpose someone else’s solution for my project. In this particular case, I’m going to deploy the wire and jack salvaged from a Xbox 360 steering wheel. This cable formerly connected the foot pedal unit to the main steering unit. The foot pedal unit is subject to a lot of stomping abuse, which can shift the position of these pedals and result in tugs on this wire. It appeared ideal for handling the stresses I want it to endure in my application.

The jack has strong resemblance to standard landline telephone cable and may actually be the same thing, but because I salvaged both the jack and compatible wire for my project it didn’t matter if it was actually the same as phone jacks and lines. Using calipers I measured the jack’s dimensions and created a digital representation in Onshape CAD. I then modeled the rest of the bracket around that jack and printed its two parts.

Sawppy joystick jack printing

Here’s the mounting bracket front and back pieces along with salvaged jack, whose wires now have freshly crimped connectors for interfacing with LewanSoul BusLinker debug board.

Sawppy joystick jack unassembled

When assembled, the bracket grabs onto one of Sawppy’s aluminum extrusion beams. Tugs on the wire should transfer that force to aluminum beam instead of pulling wires out of the board.

Sawppy joystick jack assembled

I installed this jack between two major pieces in Sawppy’s structure. This ensures that it will not slide when tugged upon, which should help with strength.

Sawppy joystick jack installed

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.)

Sawppy Will Be At Maker Faire Bay Area 2019

I’ve been taking my rover Sawppy to various events, from small school science fairs to large exhibit hall of Southern California Linux Expo. One of these stops was the Downtown Los Angeles Mini Maker Faire. A Maker Faire is the right kind of environment to attract the right kind of crowd that is perfect for a motorized model of Mars rovers.

From the official Maker Faire website I learned that “Mini” in “Mini Maker Faire” is not necessarily a comment on the scale of an event. The “Mini” signifies a community event that is organized and held by local entities, like the Los Angeles Public Library in the case of DTLA Mini Maker Faire. Maker Media, who has the registered trademark and associated legal rights, allows such communities to call their events a Mini Maker Faire and share some infrastructure if certain guidelines are followed.

So what about events curated and produced by Maker Media? They are the Flagship Maker Faires. And the original one of them all is Maker Faire Bay Area held in San Mateo, California. When exhibit applications opened up, I was tempted but also intimidated about submitting Sawppy in an application. It is not just a Maker Faire, it is the Maker Faire! This intimidation kept me from submitting by the early deadline, but a few encouraging pushes (Thanks Jasmine! Thanks Emily! Thanks Glen!) got me past my psychological barrier to submit my application.

I was very excited when I received a notification telling me Sawppy had been accepted. It is amazing to see Sawppy listed on the event’s “Meet the Makers” page. And I have my own Maker Sign that I will display on Sawppy during the event. I was intimidated before, but now I’m looking forward to the event!

Sawppy Sign MFBA19 69882

Sawppy Builders

I started my Sawppy project in March 2018. By May 2018 I had my first rolling chassis but it was fragile. Every time my rover broke, I learn a little more about mechanical design, and Sawppy improved over the following months. I also started writing assembly instructions and supporting documentation to help any other interested people build their own Sawppy, not knowing if anyone would take me up on my offer. It was extremely gratifying to see other people have indeed accepted my invitation!

On my Hackaday.io project site I’m going to start recognizing those who have embarked on their own Sawppy adventures, roughly in the order of when I learned about their efforts. Sometimes I learn about their ambitions before they got started, sometimes I learn about it only after their rover had been completed. Given this, it is likely there are other Sawppy builders out there I don’t know about at all! But that’s fine, I just love the fact there are more Sawppy rovers running around.

I used to list a few Sawppy builders on my Sawppy project description text, but the list has grown too long to fit in that space. I’m going to track Sawppy builds by continually updating a project log entry created for the purpose, editing it as I go to add more rovers as they come online. I don’t know if there’ll ever be a day when even this would become too unwieldy to track all the Sawppy builds out there… but as far as problems go, that’s one I would be very happy to have.

To everyone who decided my project was worth your own time and money and effort to build: Thank you.

It’s my privilege to link to all those Sawppy rovers in one place.

New MP1584 Regulator Consolidates VFD Project Power Supply

Driving a vacuum fluorescent display (VFD) requires multiple power planes: we needed 2.5V AC for the filament, 30V DC for grids and segments, and 5V DC for a voltage bias between filament and grid/segment as well as driving all electronic logic. In our first test, these three power planes came from three different sources, for an unwieldy mess of three power plugs going to three transformers feeding into our circuit.

While we were working on debugging our control system logic, we also worked on consolidating the power supplies. From the start our 2.5V AC came from a AC transformer that was extracted from the same device we salvaged our VFD from, so we knew it was capable of supplying all the other power planes as well.

Using the same transformer to provide our 30V DC was relatively straightforward, but we had trouble with our 5V DC plane that took some head-scratching. We eventually determined the 5V DC plane couldn’t supply enough power to all the components on the plane because we had our priorities backwards: the highest amperage draw device (the Raspberry Pi 3) was furthest from our 5V voltage regulator when it should have been the closest. Our 5V power sagged to a little over 4V when our Pi was desperately trying to suck enough power through our convoluted nest of wires.

Unfortunately, while trying to move our 5V supply closer to the Pi, we made a wiring error and destroyed the regulator. Oops! Fortunately, these MP1584 modules were very inexpensive and it wasn’t a big deal to bring in a replacement. We just had to wait for a follow-up SGVHAK work session. [Emily] found enough room on our prototype PCB to fasten the regulator with a few soldered header pins so the module doesn’t have to dangle on wires. In hindsight we would have rearranged our layout to make sure there’s room for this regulator, but this is why we build prototypes.

Now our regulated 5V DC supply is first connected to the header pins that supply power to our Raspberry Pi, and from there to the PIC, before finally putting a voltage bias on our filament. This makes far more sense than the other way around, and gave us an electrically reliable system all fed from a single transformer.

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!

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.

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.

Sawppy Field Repair Kit: Backup Electronics

About a month ago Mars rover Curiosity’s computer system had a hiccup and reset itself, causing its management team here on Earth to switch to its alternate computer. These two computers – referred to as Side-A and Side-B, allow Curiosity to run on one while mission team diagnoses the other. Initial reports indicate a problem with Curiosity computer’s on board data storage systems.

My rover Sawppy is modeled after Curiosity, and it’s only be a matter of time before Sawppy emulates its big brother with a data storage problem too – the microSD card on a Raspberry Pi 3 computer is a notorious point of failure. But Sawppy doesn’t have a redundant computer system on board that can be switched remotely. Since I’m typically not far away, I can walk up to my rover and perform replacement manually.

But I could only walk up and replace it if I had a replacement handy! This is growing in importance as Sawppy started getting booked for public appearances. When it’s just a hobbyist project it’s not a big deal if Sawppy encounters a problem, I just pack it up until I can get home to my workbench. But if we’re starting to get into situations where Sawppy is actually a featured item, we need to know how to make sure The Show Must Go On.

Thus the latest addition to Sawppy’s field repair (“first aid”) kit: Highest priority is a copy of Sawppy’s microSD card already configured with all necessary software. A microSD card is very small and light, so there’s no excuse not to have one always on hand.

Lower priority, for times when there’s space to spare, is a backup Raspberry Pi 3.

And lowest priority is a LewanSoul servo USB to half-duplex translation board required to operate LewanSoul servos. And while I’m at it, pack a replacement servo as well!

Sawppy backup electronics

Sawppy Flag Pole Now Mounted Magnetically

One of the problems I didn’t foresee in designing Sawppy was that some children might see a fun challenge in doing running jumps over my rover. I first saw this unwelcome behavior when I brought Sawppy to Long Beach, and I knew it’d only be a matter of time before a child would misjudge their jump and smash Sawppy into a pile of broken rover pieces.

Clearly I need to find some way to discourage this behavior, but I also can’t do anything that physically harms misbehaving children. This eliminates straightforward solutions such as a Samurai blade pointing straight up. I would also like this countermeasure to be stealthy and not call attention to its anti-jump purpose otherwise some would see it as a challenge.

The answer came while preparing for this year’s Southern California Linux Expo (SCaLE 17x). I was scheduled to host the Hackaday x Tindie Birds of a Feather meetup, and I was also slated to co-present a talk with Lan Dang. For publicity purposes I decided Sawppy can be a rolling billboard, as SCaLE is exactly the right audience of people who would pay attention to a 3D-printed rover running about. I pulled out a yardstick I had on hand and started planning how to use it as a flag pole, and I immediately knew I had my anti-jumpover countermeasure as well. Two birds, one stone.

Sawppy Scale 17x Sat 1 - Roving billboard

As previously mentioned, I didn’t want this flag pole to be too rigidly attached. If someone bumps my sign, or if someone decides to try jumping over my rover anyway, the flag pole must break away cleanly without damaging the person or the rover. For SCaLE I used a zip tie that was arranged so there is tension holding the yardstick flag pole in place, but pops free when stressed.

This mostly worked, but as it was built on a balance of opposing forces, it was finicky to reinstall. At Caltech Science for March, a curious toddler yanked off the flag pole and the toddler’s supervising elderly adult tried to reinstall the pole. But grandpa had no idea what he was doing, blindly stabbing inside Sawppy’s equipment bay with the yardstick applying more force as he grew more agitated. After two attempts at saying “Don’t worry, I’ll put it back myself” while I watched in horror at Sawppy electronics getting pummeled, I forcibly grabbed the yardstick from his hands in order to save Sawppy from being stabbed to death.

A better solution must be found.

In preparation for Sawppy’s appearance at Yuri’s Night, I decided to try a magnetic mounting system. Originally rejected because I thought it wouldn’t be strong enough, I thought it was worth a second look. I had a stack of these powerful little magnets and a single pair wasn’t able to hold the pole. But four pairs of them might be strong enough for the task.

For this test, four magnets were held on to chassis beam via packing tape. Two on upper beam, two lower.

Sawppy magnetic flag mount

Matching sets were held to yard stick flag pole with more tape.

Sawppy magnetic flag mount with pole

With updated camera mast and flag pole mount, Sawppy was ready for its next public appearance at Yuri’s Night Los Angeles! That event got crowded at times and there were a few accidental bumps that triggered a clean separation followed by quick re-installation. And while this adult-focused event had few children about, there were plenty of drunken misbehaving adults. The flagpole did not discourage all misguided behavior, but it has worked well enough to become a permanent fixture of my future Sawppy public appearances.

Sawppy with new camera and flag pole

(Cross-posted to Hackaday.io)

Sawppy Mount For Kinect V1

When Sawppy first started running around, I wanted something to sit atop a camera mast where the real rover has a camera and sensor array. It is the anthropomorphic head of the rover and it looks slightly wrong without one. (Like a chicken running around without its head.) The first iteration of camera mast sensor array enlisted a standard USB webcam sitting alongside a Google AIY Vision kit. It was mostly for appearance because there wasn’t much software behind it.

The webcam was fun for entertaining children and occasional longer distance driving, but not immediately useful for autonomy. The AIY Vision box is optimized for classification tasks. I thought there might exist code useful for robotic visual localization but if it’s out there I have yet to find it.

The most promising tool at hand for rover localization is my Kinect sensor bar running RTAB-Map or some similar software. So Sawppy will inch towards autonomy by getting a camera mast upgrade to my Kinect V1 sensor bar and see if we can integrate that into rover systems in a useful way.

I went looking for a good way to mount a Kinect bar to Sawppy. I disassembled its base looking for a good mounting mechanism, but there weren’t convenient existing fasteners for me to use and there weren’t good places for me to drill and tap new ones. It was surprisingly crowded in there! I knew there was a motor for up/down tilt but I underestimated size of the motor gearbox inside.

Kinect v1 base disassembled

I then reassembled the base and went with plan B: a simple flat platform for attaching my Kinect sensor bar with double-sided foam tape.

Printing Sawppy Kinect v1 platform

Kinect sits slightly offset camera mast center for two reasons.

  1. The Kinect sensor bar is very wide and if mounted centrally it overhangs to the right. I worry about it hitting obstacles so I wanted to bring it closer to the middle.
  2. By offsetting sideways, I could expose the top of the pipe used as camera mast and run Kinect’s wire down the middle for cleaner wire management.

Sawppy Kinect v1 installed on platform

At the moment this Kinect is no more functional for autonomy than the previous configuration… in fact, for its first public appearance at Yuri’s Night 2019 it is not even electrically connected to anything. It’s just a matter of taking one step at a time.

(Cross-posted to Hackaday.io)

Sawppy at Yuri’s Night LA 2019

Yesterday Sawppy attended Yuri’s Night Los Angeles 2019 as a roaming exhibit to help entertain the audience who all have an enthusiasm for space and science. As part of the volunteer event staff, we had to arrive at event venue California Science Center an hour ahead to get checked in. I noticed the signs and logos actually combined the second and third words into “California ScienCenter” but it’s not clear if this is just a bit of artistic license in graphic design or if they’re actually working to rename themselves.

Yuris Night 2019 01 - Sawppy arrives at California ScienCenter

Once checked-in, Sawppy’s assignment was to roam and entertain guests waiting in line to enter.

Yuris Night 2019 02 - Sawppy mingles with entrance line

Sawppy was not the only robotic entertainment present.

Yuris Night 2019 03 - Sawppy and R2-D2

Sawppy was occasionally stopped in its tracks when challenged by an Imperial AT-AT.

Yuris Night 2019 04 - Sawppy and AT-AT

I was surprised to learn this was sold as a popcorn bucket sold at Disneyland. The owner gave it additional surface treatment and added LEDs, but he said almost all of the physical detail (including legs that could be posed) were part of the original bucket. Sadly, it was not motorized and did not walk.

Once people in line got in and the front entrance crowd thinned out, Sawppy went visiting other front entrance displays. Largest by far was Mister Fusion, which I first saw on TV in the first episode opening of Amazon’s The Grand Tour. There, and also on its web page, it was advertising for iHeartRadio. It is now advertisement for a mixed-use development project in Las Vegas called Area 15. The sales pitch for this “experiential retail and entertainment complex” sounded interesting, once it opens it might be worth a stop on my next Vegas visit.

Yuris Night 2019 05 - Sawppy and Mister Fusion

Model of real Earth probe sent to space meets model of fictional Martian probe sent to Earth: Sawppy and a very shiny UFO.

Yuris Night 2019 06 - Sawppy and UFO

At one point there was discussion of a display of Star Wars cars, which was the context of how I originally got involved with my RXBB8. That was removed from the plan at some point, but Sci-Fi cars still had representation with one of the Back to the Future DeLorean replicas.

Yuris Night 2019 07 - Sawppy and DeLorean

Main space for this event was in the Space Shuttle Endeavour room, where photography was difficult but I wanted a picture of Sawppy with a real spacecraft.

Yuris Night 2019 08 - Sawppy and Endeavour

Lots of people loved Sawppy and asked many interesting questions about Mars rovers. The event had everyone from “I don’t know much about the Mars rovers but I want to hear about them” to JPL engineers who are actively working on building the Mars 2020 rover. My discussion topics with people fluctuated wildly to suit.

At the end of the night, guests for the event were directed through the kelp forest tunnel to exit.

Yuris Night 2019 09 - Sawppy in Kelp Forest

After a full night hanging out with other space fans, Sawppy headed home.

Yuris Night 2019 10 - Sawppy Heads Home

Making Neato Robot ROS Package More Generally Usable

Neato mini USB cable connection to laptopNow that I have some idea of what happens inside ROS package neato_robot, and modified it to (mostly) run on my Neato vacuum, I thought I’d look in its Github repository’s list of issues to see if I understand what people have said about it. I didn’t have to look very far: top of its open issues list is “Robot compatibility.”

The author agrees this is a good idea but it has to be done by someone with access to other Neato units, pull requests are welcome. This comment was dated four years ago but my experience indicates no pull requests to improve compatibility were ever merged into this code.

But even though modifications were never merged back into this branch, they are still available. I just had to be pointed to know where to look. That comment thread referenced this particular commit which eliminates those problematic fixed arrays of expected response strings. Now it will read a Neato’s responses without trying to match it up against a preset list. Of course, if a specific response is still required (like LeftWheel_PositionInMM and RightWheel_PositionInMM) all it could do is ensure code will not hang, it is not capable of inferring requested data from other robot responses.

But possibly more interesting than code changes is this comment block:

This driver reads responses until it receives a control-z. Neato Robotics has
documented that all responses have a control-Z (^Z) at the end of the
response string: http://www.neatorobotics.com.au/programmer-s-manual
CTRL_Z = chr(26)

That URL implies it was a link to some type of a programmer’s reference manual, but unfortunately that link is now dead. Still, this claim of control-Z termination (if true) gives me ideas on how I would approach talking to a Neato with my own code.