Slowing Sawppy Response For Smoother Driving

When I first connected my cheap joystick breakout board from Amazon, its high sensitivity was immediately apparent. Full range of deflection mapped to a very small range of physical motion. It was very hard to hold a position between center and full deflection. I was concerned this would become a hindrance, but it wasn’t worth worrying about until I actually got everything else up and running. Once Sawppy was driving around on joystick control, I got my own first impressions. Then in the interest of gathering additional data points, I took my rover to a SGVHAK meet to watch other people drive Sawppy with these super twitchy controls.

These data points agree: Sawppy’s twitchy controls are problematic to drive smoothly and it’s actually running between points fast enough for me to be worried about causing physical damage.

There were two proposed tracks to address this:

First thought was to replace the cheap Amazon joystick module with something that has a larger range of motion allowing finer control. [Emily] provided a joystick module salvaged from a remote control aircraft radio transmitter. Unlike arcade game console joysticks which demand fast twitch response, radio control aircraft demands smoothness which is what Sawppy would appreciate as well. The downside of using a new joystick module is the fact I would have to design and build a new enclosure for it, and there wasn’t quite enough time.

So we fell back to what hardware projects are always tempted to do: fix the problem in software. I modified the Arduino control code to cap the amount of change allowed between each time we read joystick values. By dampening the delta between each read, Sawppy became sluggish and less responsive. But this sluggishness also allowed smoother driving which is more important at the moment so that’s the software workaround in place for Maker Faire.

This code is currently in Sawppy’s Github repository starting with this code change and a few fixes that followed.

Sawppy and Makey

The mascot for Maker Faire is Makey the Robot. (Or possibly Mr. Makey to me…) As part of Sawppy’s Maker Faire experience, I wanted to make sure I got a good picture of Sawppy with Makey. I thought the mascot would surely be everywhere and it wouldn’t be hard to get a picture. The thought was not wrong… but finding one of the appropriate size and sitting in the right angle for sunlight and not otherwise swarmed with people proved to be a challenge.

The biggest and most promising Makey was a standing statue that [Emily] found and pointed out to me. Unfortunately the sunlight angle was not the best but we had fun with it. I started with an easy standard pose.

Sawppy and Makey 1

I went low to the ground to achieve a dramatic upwards camera angle.

Sawppy and Makey 2

Then [Emily] had a brilliant idea to pose Sawppy with Makey. She put one of Sawppy’s front wheels up on Makey’s pedestal, and turned the Kinect sensor bar with googly eyes to face the camera. This is a great picture.

Sawppy and Makey 3

After this picture, I looked for a smaller Makey closer to Sawppy’s size, and the best I found was on this sign directing people to something or another. The two robots are closer in proportion but it doesn’t have the energy of [Emily]’s pose.

Sawppy and Makey 4

And finally, when I passed the workshop area I also saw a partially disassembled Makey on display. It felt like a stage set up for something but is currently empty. But there was no time for question! I looked around, caught a brief gap in passing crowd, and snapped a picture of Sawppy here.

Sawppy and Makey 5

Meeting of Rovers at Maker Faire Bay Area 2019

The primary goal of taking Sawppy to Maker Faire Bay Area 2019 was to spread word of DIY Mars rover models to the greater maker community. But that was certainly not the only goal! There were many secondary goals, one of which was to meet [Marco] who has already received the word and built a Sawppy of his own.

Through Sawppy’s project page on Hackaday.io I learned of a few other rover builders who have built their own creations on top of my design. They are spread all around the world but I had never met one in person until Maker Faire. Even though we knew each other would be present, it brought a great big smile to my face when I saw [Marco]’s bright yellow Sawppy roll up to greet mine. We had hoped that we might see more rovers by builders that never communicated with us, but if any were present they had escaped my notice.

When walking through the area dedicated to educational maker groups, I had expected to see some sign of the JPL Open Source Rover but came up empty handed. If any completed rovers were rolling around I didn’t see them, and if any partial rovers were on table display I missed them. Though to be fair, I visited that building during one of the harder downpours so almost every attendee packed the indoor spaces making it hard to see everything with a rover underfoot.

But I did find members of the NorCal Mars Society rover project with a different focus than my project. They did not prioritize building a chassis that looked like Mars rovers, instead focusing on the control systems. There’s a camera feed for a remote operator and control system to run simulated Mars missions. Still, we were all part of the greater family of Mars rover enthusiasts and it was fun to have all the rovers meet up.

A Raincoat for Sawppy

Maker Faire Bay Area takes place at the San Mateo Event Center with both indoor and outdoor exhibits. As the dates got closer this year, weather forecast called for rain. This is probably not a good thing for attendance of the event and corresponding finances, but it’s also a concern for exhibitors as well. I, for one, did not design my roaming exhibit Sawppy for rainy weather.

The first and most obvious idea was to design and 3D print an umbrella mounting bracket for Sawppy. But I was worried about the umbrella catching wind to topple over the little rover. I was also worried about wind-driven wind flying sideways and landing on components. And lastly, carrying an extra umbrella is bulk I would rather do without.

Thus I moved on to the second idea: craft a raincoat out of plastic (garbage bags, basically) that I can secure more tightly against Sawppy’s equipment bay via magnets. Aluminum extrusion beams are not magnetic, but the M3 bolts are! This should offer marginally superior protection from the elements, and less bulk to carry around.

The project started with a large black garbage bag that I had cut open to create a single sheet. [Jasmine] (who had generously hosted [Emily] and myself Thursday night) thought the opaque cover was a shame and brought out a large clear plastic bag. This way people could still see inside Sawppy even when wearing the raincoat. I continued using the black bag as a trial run, and then used it as a template to cut Jasmine’s gift to form the final raincoat.

Sawppy raincoat template creation test

This custom-fitted raincoat only covered Sawppy’s equipment bay. To protect the rest of Sawppy, sandwich bags were placed over four corner steering motors, and a hotel shower cap was put over Sawppy’s head. Everything wrapped up nicely around Sawppy’s neck with a strip of velcro, again from [Jasmine]’s workshop. This compact arrangement was lighter and more compact than an umbrella when folded. And when deployed, Sawppy could go outdoors and romp in the rain.

Sawppy raincoat stowed

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

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.

Old Couch Teardown

And now, something a little different from the usual fare. Today’s teardown project has no electronics in it whatsoever. It is an exploration into an entirely different category of home consumer merchandise: furniture.

This old couch had been in service for several decades and long overdue for retirement. The default option was to treat it as bulk waste and call for pickup, but let’s see what we can learn from its deconstruction.

We start with seat bottom cushion which were easily removed. Some coins were found but there were little else of value trapped within. Too bad – we once found a lost cell phone in here, but not today.

Couch Teardown 02 - bottom cushion removal

Unlike the bottom cushions, this couch’s back cushions were attached and had to be cut off for disassembly.

Couch Teardown 03 - back cushions cut off

Each armrest cushion were held by four of these rivet-like structures, two inside and two outside of each armrest. It was easiest to cut fabric around each rivet than trying to unfasten them.

Couch Teardown 04 - armrest cushions

Those armrest cushions were the final pieces of soft padding material. Everything that remained are fabric and rigid structure.

Couch Teardown 05 - all soft padding removed

Fabric panel cutting started with the bottom-most sheet. This sheet is not typically visible, made of a thin and partially transparent material that is also very tear-resistant.

Couch Teardown 06 - tear resistant bottom

This sheet was fastened by staples. The decision was made to cut instead of pull to avoid staples flying everywhere possibly puncturing tires and feet.

Couch Teardown 07 - evil staples

Seat springs were visible once that bottom fabric panel was cut away. We’ll be back for those springs later. For now focus is still on removing pieces of fabric so we proceed to cut back panel.

Couch Teardown 09 - cutting back panel

We can see more of the wooden frame once the back panel was removed. These wood beams were surprisingly irregular in their dimension. Each segment might be a little wider or thicker than its neighbors. Not that a great deal of precision was necessary – pieces were held to each other with copious amounts of staples. This construction method does not demand dimension accuracy. It’s possible this flexibility allowed the couch to be built using scrap wood left from manufacturing other things.

Couch Teardown 10 - back panel removed

Cutting off the back panel also exposes these metal strips. These were used to cover up fabric seams. When installed properly, they are not visible and thus preferable to staples.

Couch Teardown 11 - fastening strips

With the removal of each fabric panel, the couch looks less and less like a couch.

Couch Teardown 12 - side panels cut off

Returning to the bottom, a bolt cutter helps cut off the springs. With the first cut I discover they are bent in a direction to support weight. This discovery was accompanied by reinforcement that it’s always good to stay back when cutting metal things to minimize chances of injury.

Couch Teardown 13 - cutting springs

By this point all loose fabric panels have been cut free, as has metal springs. Most of the remaining parts are wood and fabric glued to panels of wood. It is time for the reciprocating saw to make its entrance.

Couch Teardown 14 - all fabric panels cut off

A reciprocating saw made quick work of wood pieces. A few cuts, and the couch back is gone.

Couch Teardown 15 - seat back wood cut off

After a few more cuts, the couch is no longer recognizable as a couch at all. These easily managed pieces can now be disposed as regular household landfill and do not require special bulk waste procedures.

Couch Teardown 16 - no longer recognizable as couch

The Continued Rising Cost Of SF Bay Area May Squeeze Out Maker Faire

The San Francisco Bay Area, home of technology companies galore and the legendary Silicon Valley, was put on the history map from the gold rush. And in a way, the gold rush has never stopped. The concentration of opportunities has continued to draw people there for decades. Growing number of people competing for… well… everything has driven the cost of living ever higher.

When I graduated from college with a computer science degree, most of my classmates went to the Bay Area to build their career. I decided to go to the Seattle area instead, because I felt the Bay Area was too expensive and it was only a matter of time before that bubble collapsed. And while that bubble has deflated a few times, I have been proven wrong time and time again as things kept growing.

Basic economics say when the price exceeds what the market will bear, the market will adjust. While there hasn’t been enough adjustments to offset everything else, I do see things getting priced out of existence.

What’s the latest potential casualty of ever increasing cost of the Bay Area? San Francisco Chronicle published a doom-and-gloom article outlining difficulties faced by the flagship Maker Faire Bay Area. While the maker movement has continued to grow, attendance and sponsorship at this event has not kept pace with growth in cost. The increasing numbers of licensed Maker Faires outside of San Francisco and New York (like the Downtown Los Angeles Mini Maker Faire) is also a dual-edged sword: It spreads the Maker Faire love, but it gives people less reason to spend the money necessary to congregate at the flagship event.

I will be sad if this is the last Maker Faire Bay Area, but if so I’ll try to take some comfort from getting to see it before it goes.

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.

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 controller.zip. 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 LobotServoController.zip. 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).