Micro Sawppy Beta 1 Steering

I had decided to use micro servos, converted to continuous rotation, to drive the wheels of my micro Sawppy beta 1. (MSB1) The next challenge was to design a way to steer the four corner wheels.

Given my fixation on using ball bearings to shoulder workloads in rover designs, it shouldn’t be a huge surprise that the first thing I worked on was a method to incorporate a ball bearing into my design.

Mounted at the bottom of a suspension arm with a single M3 screw into plastic, it will bear the weight of the rover and define this corner’s axis of rotation. It will also become the fulcrum for any lateral wheel movements pushing against the steering servo.

In consideration of these forces, the servo horn sits at the top of the steering assembly to maximize length of lever arm and minimize stress on servo gearbox.

I oriented the servo such that the wires are pointing towards the body. This seemed like the obvious choice for wire path management. And given that servo wires exit at varying locations from one micro servo manufacturer to the next, I had to design a “funnel” to accept a range of wire positions.

A consequence of this decision is that the steering knuckle is quite wide in order to give enough clearance to the body of the servo. This consumes precious space in such a tiny rover. At the rear of the rover, I wonder if this will clear the body.

At the front of the rover, it limits the amount of space available for a rover robot arm. This front view picture shows the steering knuckle is taking up almost a third of the width between steering servos.

Fortunately, I could shape the structure to minimize impact on wheel ground clearance. These wheels are quite happy to climb over obstacles with little risk of collision with the steering knuckle body. Which is one less thing to worry about as I moved on to designing the suspension bogie for MSB1.

Converting MG90S Metal Gear Micro Servo to Continuous Rotation

By default, remote control hobby servos are tasked to hold a particular rotational angle specified by its given control signal. However, a common modification is to turn them into “continuous rotation servo” where the control signal commands the motor forward or backwards without regard for position. This is useful for tasks like driving a little rover’s wheels.

Performing this modification is done by disconnecting the potentiometer from the output shaft, and replace it with resistors that will result in an unchanging resistance value. Such a servo will think the control shaft is always at center. So when given the command to move to a position off center, its control circuit will fruitlessly spin the motor trying to get to a position it will never reach, giving us our forward/back motor control.

Studying a few micro servos batches sold by different vendors, I’ve established there’s a fair amount of variety among generic micro servos. So these pictures will probably not exactly match whatever might be on hand for your project, but the general concepts should still hold.

This conversion starts with a standard servo with two resistors. The precise value isn’t very important, but they do need to be at least a few hundred ohms (so very little current flows through them) and they need to be as close to identical to each other as practical. I used two 1 kΩ resistors.

In reality, the two resistances will not be equal, and servos at this price range wouldn’t be very precise about voltage measurement anyway. So this conversion method should only be used when we have means to adjust throttle trim (a.k.a. defining the center point) in the control system. If our control system doesn’t have such adjustments, then the potentiometer needs to be preserved to allow physical adjustment. In the case of this project, I have software adjustment, so I could proceed.

Hopefully your micro servos are not glued shut and can be opened up by removing a few screws. In this particular type, removing two screws allow access to both the gearbox and control electronics.

Even though MG90S micro servos are commonly called metal gear servos, I’ve found that some of them don’t actually have all metal gears. They might have metal gear only on the final output shaft or maybe one or two intermediate stages behind that. This particular one is actually all metal, but of course there’s no guarantee on how strong the metal might be. What’s important right now is whether the final output gear has something that prevents continuous rotation. Not all of these servos have one. But if present, it needs to be removed. Hold that output gear securely…

And remove the stop.

Now the servo is mechanically able to rotate continuously, and we can proceed to electronics modification to the position-sensing potentiometer.

Hold the control circuit board securely.

Unsolder the three legs of the potentiometer.

Use the two resistors to build a voltage divider that evenly divides the voltage across either side into an average value on the center pin. This is what the potentiometer used to do at its center position, and now it will read as that position forever.

Reassembling all parts completes the conversion. We are left with a extraneous piece of mechanical stop, and a potentiometer that is no longer used to sense position. Now this motor can be controlled like a small gearmotor assembly with built-in H-bridge, perfect for mounting inside a micro rover wheel steering knuckle.

Micro Sawppy Beta 1 Wheels

Micro Sawppy Beta 1 (MSB1) is the test chassis I built to verify I could miniaturize concepts of my Sawppy rover down to a smaller simpler version built around micro servos. This tour of MSB1 starts at the bottom where the rubber plastic meets the road dirt. These wheels were a simplified version of Sawppy wheels, keeping the 48 grousers inspired by Perseverance rover’s wheels. The six wheels spokes don’t conform to the shape of the real thing, because that required multiple pieces made with 5-axis CNC machining and I wanted a design that is 3D-printable in one piece. But I did keep the curved spiral that also contributes to shock absorption, something also present in bigger Sawppy wheels.

I tried to carry over Sawppy’s wheel axle design, where a metal shaft is responsible for shouldering all the weight of the rover, helped by a few ball bearings. This freed the LX-16A serial bus servos from structural load duty, letting them focus on their job of turning the wheel to drive the rover forward/back. Unfortunately I couldn’t figure out a good way to scale down that design without inheriting all the problems.

Thus these wheels were mounted directly to the servo horn via some self-tapping M1.2 screws. Those fasteners were from an assortment kit of small self-tapping metric screws I found on Amazon (*) but I’m worried whether they are commonly available worldwide.

Fastening the wheels directly to servo horns meant the micro servo gearbox will have to shoulder weight in addition to their responsibility for driving the wheels. This force will be applied perpendicular to its axis of rotation and the micro servo gearbox isn’t optimized to handle that type of force long term. As an attempt to mitigate this, I decided to mount the wheel on the inside surface of the horn, shortening the lever arm by a few precious millimeters.

Despite my misgivings about this design, I decided to forge onward. Perhaps a micro rover is lightweight enough that gearbox wear would not be an issue, and building this prototype will tell me if there were other unforeseen problems with this approach. Before I can drive a rover with these, though, I’ll need to convert them from position control actuators into continuous rotation servos.


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

Micro Sawppy Beta 1

With mechanical foundations established, it took a few weeks of experimentation to get to Micro Sawppy Beta 1. (MSB1) My first running test of a small Sawppy rover, this prototype verified I could make a rocker-bogie rover chassis using micro servos for all electromechanical articulation. It was also my first time veering away from mechanical scale fidelity, altering proportions towards a cute baby rover.

Since the focus was on rocker-bogie suspension design, I didn’t put much effort into the rover body for this chassis, it’s just a minimalist box. This follows the precedence of NASA JPL’s “Scarecrow” rover which was likewise a test chassis for Curiosity rover’s rocker-bogie suspension and has no body to speak of. It also has no onboard computer processing, and this lack of electronic brain is where its “Scarecrow” name came from.

MSB1 similarly has no onboard autonomy, but that matches my Sawppy V1 rover which never got software beyond turning it into a remote control vehicle. In fact, like my Sawppy, MSB1 is also running the software I wrote for SGVHAK rover. Shortly before its public premiere, SGVHAK rover needed software support for a steering hack with remote control hobby servo, and I reused that code base for this micro servo rover. What was slapped together for a single steering servo was expanded to cover servo control for four steering servos and wheels driven by six continuous-rotation servos.

Using SGVHAK rover code, running on a Raspberry Pi 3 with the Adafruit 16-channel PWM/Servo HAT, was the most expedient way to get MSB1 up and running. Following ExoMy’s lead, I had put some effort into wire management, but the end result is a tangled mess because I made a miscalculation somewhere in the scarecrow body box for this rover. It was too small to hold a Pi 3 with the servo HAT, so those two circuit boards were forced to dangle outside the box and now everything is a mess. Ah well, that’s why we do prototypes.

So let’s take a little tour of MSB1 from the ground up, starting with its wheels.

Little Sawppy Rover Intends To Be Adorable

I do tend to catch myself obsessing over tiny mechanical implementation details, and I have to periodically remind myself that they all have to work in service of overall project goals. The primary goal of the little Sawppy rover is to make a DIY motorized 3D-printed Mars rover model accessible to people that would be otherwise excluded by the larger rover. A lower cost to make it within reach of those who found Sawppy too expensive. Fewer parts and easier to build for those who found Sawppy too complex. Which has a side effect of a smaller size for those who found Sawppy too big and bulky.

The smaller size also opened another path that I wanted to explore: not just a little rover, but a cute little rover. Sawppy mostly followed the scale and proportions of Curiosity rover. Most of the deviations came from when I made sacrifices to make parts easier to 3D print. But as soon as I saw the cute rover illustration for JPL’s Mars 2020 naming contest I knew I wanted to make a rover that willingly sacrifices scale fidelity in order to gain physical appeal. This was reinforced when I learned of ExoMy. Which took the designs of ESA ExoMars mission rover Rosalind Franklin, and turned it into a cute rover with a smiling face.

My little Sawppy rover can’t help but look cute next to a full size Sawppy, like a duckling following around mama duck. Rather than putting up any futile effort to fight it, I plan to lean into the cute angle. Aside from just the sheer fun of it, I also hope a cute appearance will make the project appealing and attract an audience who would otherwise be less interested in a mechanically faithful scale model.

From a design standpoint, this means changing around some proportion on the little rover. Adapting counterparts to traits that we humans instinctively associate with young animals. Following ExoMy’s lead, a little rover will start with the following:

  • Replace the mast camera assembly with a larger anthropomorphic face as ExoMy did. This is analogous to how young animals have larger heads relative to their body and big eyes on those heads.
  • Shorten individual segments of the rocker-bogie suspension, corresponding to proportionally shorter limbs of young animals.
  • Wheels that are larger than scale, emulating proportionally larger feet of young animals. However, this is less important than the previous item: once the suspension segments are shortened, the wheels will naturally look larger in comparison even if I don’t make them larger than scale.

But that is only a starting point, there are many other potential ideas along those lines:

  • Faster motors and a drive system that allows it to come across as high-energy relative to more sedate “grown up” rovers.
  • If some sort of vocalization are to be added, the little rover would have a higher pitched voice.

I expect it’ll take several iterations before I get a decent design for a little Sawppy rover. Lessons learned and incorporated as I go, starting with prototype number one.

Accommodate 3D Printer Variation With Crush Ribs

For Sawppy V1 I tried to create a design that would be tolerant of variations between 3D printers, but I failed to overcome two problem areas. Both are where 3D-printed plastic mated up against unyielding metal. One area were holes for 608 bearings used in each axis of rotation, a feature I plan to keep and scale down by using 623 bearings. The other area are holes for heat-set inserts, which has proved problematic in multiple ways and thus something I am now trying to avoid.

To deal with the bearings, I reminded myself exactly why they are a part of my rover designs: smooth rotation. The bearings are to ensure loads are carried through axes of rotation without introducing friction that could bind up. Friction is especially bad in the rocker-bogie suspension system, because it is a completely passive design for distributing weight of the rover across all six wheels. If any of the joints seize up, then the rover’s weight would not be distributed properly.

So smoothness of ball race bearing are the critical feature here, and the fact they have the strength of steel is less important. Weight of a rover is a tiny fraction of the maximum weight capacity of these ball bearings, which means I have the option to mount ball bearings using crush ribs. This is a concept I read about on Hackaday and I think it is appropriate to use for a small 3D-printed rover design. Previously I would allocate a cylindrical cavity to hold a bearing, but that meant the precise diameter of the cylinder became critical for a proper fit. Too large, and the bearing would move about loosely. Too small, and the bearing could not be inserted or perhaps damage the surrounding plastic during installation.

So instead of trying to hit the perfect diameter in a smooth cylindrical cavity, I could design a slightly too-large hole but with a few small ribs inside. When a bearing is inserted, the steel outer race will push little extraneous bits of plastic out of the way and dig itself a cozy home in between these ribs. If a 3D printer prints a little more or less than ideal amount of plastic, the size of those ribs would change but it is easier for a bearing to crush small ribs than to reshape the entire cylinder.

This approach has two problems:

  1. The bearing load is transmitted only through these small contact patches. But again the forces here are small and could be handled by the crushed ribs.
  2. The center of the bearing will end up in an unpredictable location. It will be within a small range but the actual position will depend on which ribs give way more than others. Fortunately, precise location is not critical for a little rover.

These problems make crush ribs unsuitable for most precision metal machining, which demands high precision for metal parts to work together. But we are in the world of 3D printing, where tolerances are quite loose relative to those seen in machining. Crush ribs allow us to turn the problem of loose tolerance into a feature and I can proceed with mechanical design for a cute little rover.

Type 623 Ball Bearing For Small Rover

I want to design a smaller and affordable variant of my Sawppy rover. I’ve been looking over the mechanical and electronic properties of micro servos I intend to use as the little rover’s actuators. They represent the biggest mechanical unknown due to the variations between products in this generic category. Thankfully, consistency is much better in the other mechanical part impractical to 3D-print: ball bearings.

Using ball bearings are apparently “My Thing” when it comes to designing and building rover models. When I reviewed other rover projects earlier, several didn’t use ball bearings at all, and most of the rest only used ball bearings on a subset of rotational axes. I want to put them everywhere I can!

Every rotational axes of Sawppy V1 were supported by ball bearings that went by the designation 608. I first came into contact with this type in the context of rollerblades, and they’re popular in other related wheeled footwear such as roller skates and skateboards. However, 608 bearings would be unnecessarily large for a little rover, so I went back to the well of mass-produced commodity ball bearings to find something suitable for a smaller rover.

My primary criteria is an inner diameter of 3mm, because I thought M3 would be a good fastener to use for the little rover. It is a metric standard commonly available worldwide. M3 fasteners were also used extensively in Sawppy V1, but they were on the small side so I compensated with sheer numbers. That was a design decision I regretted and want to fix in the future. For the little rover, M3 would be relatively big and strong so I would only need a few of them.

There are several different common bearing types with a 3mm inner diameter, and an unscientific poll of Amazon vendors hinted the 623 bearings (*) are the most popular and least expensive among them. I thought it was interesting that they were still more expensive than the batch of 608 bearings I bought (*), and I take this to mean that significantly more 608 bearings are produced than 623. Either that or I have yet to find the right outlets. A little rover can happily use cheap 623 bearings that have failed rigorous quality assurance tests for industrial use, as those “bad” bearings will still be far superior to nothing at all. But for now I’ll be content with the lowest bidder of the day. (*)

Like 608 bearings, the letters and numbers surround 623 designate various other related features, such as how the ball bearings are shielded from the environment. But 623 itself is the important part here, as it describes an inner diameter of 3mm, outer diameter of 10mm, and thickness of 4mm. And generic 623 bearings will follow these dimensions much more tightly than generic micro servos adhere to their mechanical dimensions. Which is one less thing to worry about when I already have to compensate for varying dimensions of 3D-printed plastic that will host these bearings.


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

Notes on Micro Servo Electronics

Examining my batches of micro servos unveiled a lot more mechanical variation than I had initially expected, even before we get into fine details like plastic injecting molding draft angles. But I got enough of an understanding to start pondering how I’d mechanically accommodate designs across the generic spectrum, so I started looking at the electrical side of things. Given the mechanical variations, I now know to expect their electronics to be different, and that was the correct attitude.

Three micro-servos from three different batches, and a casual glance is enough to tell there are three distinctly different control boards. (Plus examples from a fourth batch, in other pictures of this blog post.) Two of them have the motor soldered directly to their PCB, the third example here has a smaller circuit board but then must take the extra cost and assembly processing of motor wires. The three potentiometers are slightly different, but all of the motors are externally identical. Implying a commodity form factor that I am currently ignorant about, but can set aside to investigate later.

In their product listings, all of these micro servos were listed with an operating voltage range from 4.8V to 6.0V. This traces back to the days of hobby remote control receivers, which can operate from 4 Nickel-Cadmium rechargeable battery cells in series. Each cell has a nominal operating voltage of 1.2, so 4 * 1.2 = 4.8V. However, the voltage of a fully charged cell is 1.5V, so servos must be able to tolerate up to 6V.

To explore the low end, I connected a servo tester to these servos and drove them at 4.8V. While all of the SG90 seem to operate well at that voltage, there was a surprising outlier in the MG90S. One batch could work at 4.8V, but just barely. If the voltage drops below 4.8V at all it stops responding. This could happen when the battery cells get low. This could also happen when connected to a servo extension cable, or by the jumper wires I had used.

I found this curious. Does it mean this particular servo design expected higher voltage? For full size servos, it is now fairly common to accept nominal power of 7.4V, which is two lithium chemistry battery cells in series. Perhaps this particular micro servo was designed for lithium batteries? I increased the supply voltage up to 7.4V and it continued to function. But that is nominal voltage — fully charged lithium rechargeable batteries deliver 4.2V per cell or 8.4V for two cells in series.

Supplying this micro servo with 8.4V resulted in an audible pop and a visible flash. This gave me an answer: no, this micro-servo is not designed for lithium rechargeable batteries. Taking a closer look at the control board, I see a hole in the control chip right next to the power supply wire that delivered the killing 8.4V. In this picture a red arrow points to the hole, and I held up another control board from the same batch (without hole) for comparison.

Now that I’ve established 4.8V is too low for reliable operation with certain generic servos, and 8.4V is definitely too high, I’ll aim to supply somewhere in the 5V-6V range. With that electronics baseline established, I switch focus to the bearings I will use for this micro servo Sawppy rover.

Notes on Micro Servo Horn

I had toyed with the idea of 3D-printing parts that would bolt directly onto a micro servo’s output shaft. But after studying the variation in output shaft dimensions from a few different batches, I’ve changed my mind and plan on using the servo horns that come bundled with each servo. These horns will have the best chances of fitting and matching properly.

Even though these servo horns are all plastic, there are differences beyond cosmetic color: they also vary in thickness and strength. Servos sold under the MG90S category usually (but not always) have stronger servo horns than those sold under the SG90 banner. Here I am pushing two servo horns against each other and we can see one deflects much more easily.

The next challenge is the variation between their shapes. All of these micro servos came bundled with three horns, featuring one, two, and four protrusions from their center hub. The smaller protrusions found in the four-point version seem to match, but they wouldn’t have much leverage. I wanted to use the larger protrusions, but here we see variations as well. There appears to be at least two popular profiles, with slightly different shapes, lengths, and number of holes. I don’t know the history here, but I assume there were two popular types at one point and these generic models copy them both. Lacking names I will just refer them as SIX and SEVEN after the number of holes in each profile.

It would be convenient if the holes on SIX lined up with the first six hones on SEVEN, but no such luck. They have slightly different spacing. It also seems popular to have both profiles represented on the four-protrusion variant of the servo horn, making it asymmetric.

This particular SG90 servo has the asymmetric four-protrusion design, SIX on the right and SEVEN on the left. The two-protrusion design is symmetric with SIX on both left and right. For the smallest horn, it decided to go with the SIX profile.

This particular MG90S made similar choices for the two- and four-protrusion horns, but the smallest horn went with the SEVEN profile instead.

This pattern seems to hold with the servos I’ve bought to examine, but I don’t know how far to trust that observation. Are there micro servos out there with SEVEN+SEVEN for their two-protrusion horns? Are there any using symmetric four-protrusion horns? Just because I don’t see them in my batches doesn’t mean they don’t exist. This is all very puzzling to me because I’ve seen designs for 3D printed contraptions that incorporate slots in the shape of these horns. How do they account for these variations?

With all these variables in thickness, strength, shape, length, it’s not obvious how to design a rover that can employ arbitrary generic micro servos. This is a challenge to ponder.

But to end on a bit of happy news, it seems like there’s one final de-facto standard dimension that all these designs adhere to: despite the variation between servo horn thickness and mounting tab thickness, it appears that the distance between the bottom of the mounting tab to the top of the servo horn is fairly consistent. Again there’s no guarantee all the micro servos out there would adhere to this convention, but at least it gives me a starting point on mechanical design as I move on to look at the electronics within.

Notes on Micro Servo Output Shaft

Mounting a micro servo in the chassis is only half the battle, we also need to attach something useful to its output shaft. Historically servo horn is one of those things that aren’t practical for FDM 3D printing due to the precision fine teeth required to engage output shaft splines. I had thought it would be an interesting thing to try if I ever have access to a high resolution resin 3D printer, but after this study session I’ve changed my mind: there’s too much variation between servos and I’ve come to accept that I’ll need to use whatever horn that came bundled with the servo.

Or at least that’s true at this low-cost end of the generic micro-servo market. My previous knowledge came from the market of standard sized servos, where there are two fairly established brands (JR and Futaba) each with their de-facto standards that other servo makers typically emulate. That might be worth investigating for later for a larger rover, but we’ll set that aside and stay focused on the current micro servo rover project.

SG90 servos have a plastic output shaft and MG90S has a metal shaft, but they differ by more than the type of material. The servo horn for a SG90 is fastened with self-tapping screws that cut their own threads into the smooth cylindrical cavity molded into the center of the plastic output shaft. In contrast, the MG90S output shaft has thread already tapped from factory, and we fasten horns to them with a machine screw. Machine screws typically have a stronger holding force, and they will also remain strong through multiple fasten cycles. Unlike self-tapping screws, which tend to wear down their plastic threads more quickly over time and, if reinstalled incorrectly, can destroy the plastic thread outright.

With all the differences above, it was not a surprise that the servo horns are not interchangeable between SG90 and MG90S servos. What was a surprise was that the output splines can differ between different batches. Two of the MG90S batches had servo horns that were similar but not identical. Trying to swap them would result in one arrangement that is far too loose, and the reverse does not fit at all: it split open when I tried to force it on. This discovery of incompatible variations in servo horns is what torpedoed the resin printer idea or anything that deviates from using the bundled servo horns.

Notes on Micro Servo Enclosure

I’ve used a few micro-servos before in earlier projects, but only in the context of quick hack projects where I grabbed one and only had to make that one work. This is the first time I approached these things with the idea of using more of them and in a project that I want others to be able to build as well. So I will invest some study time to better under the micro servos sold under generic names SG90 (plastic gear) and MG90S (metal gear) by buying a few batches from different vendors on Amazon.(*)

First, the good news: From their top view, facing their output shaft, the external dimensions of the case and the two mounting tabs are all very close. As is the position of the output shaft relative to those mounting holes. These appear to be de-facto standard dimensions that generic variants more or less adhere to, so they can all bolt into the same holes.

Rotate the devices 90 degrees to look at them from the side, though, and we see many differences. Based on their names, I had thought the two types differ only in the material used for their gears, but that turns out to be a misconception. The mounting tabs may look the same when viewed from the top, but a side view shows they have different thicknesses. The metal gears are also sometimes accompanied by a bigger and sturdier box around the gears, which pushes the bottom of the servo further out, resulting in a taller overall height. So even if they can fit in the same sized rectangular hole, they might different depths of that hole.

And a rectangular hole would not be enough, because we need to leave room for the servo control wire, which exit at different locations in different variations of the design. I have two batches of SG90 and four batches of MG90S, and they all had slightly different wire locations! At least they all agreed to exit on the side closer to the output shaft. While we’re on the topic of wiring: one of the ways these manufacturers cut cost is skipping strain relief. A few sets of control wires broke at their soldered end just from me handling them during these examinations.

The close-but-not-identical exterior dimensions means I can’t use a snug non-fastened bracket like what I designed on Sawppy V1 for the LX-16A servos. What’s snug for one generic servo might be too loose or too tight for another. I will have to mount these servos by following convention: two self-tapping screw points for the tabs on either side of a rectangular bracket. And that bracket can only be a few millimeters deep on the output shaft side in order to ensure there is clearance for the control wire.

This is enough information to let me get started with designing something that can mount generic micro servos, but mounting the servo is only half the challenge. In order to do anything useful, I have to be able to mount stuff on the output shaft as well.


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

Commodity Micro Servos For Rover Actuator

After I decided to start with a small rover variant, I need to find actuators for a little rover. Since I want my design to be affordable and parts to be accessible worldwide, the most obvious candidates are the micro servos bundled in endless Arduino & STEM kits and used in many other hobbyist robot projects. There are two major categories: The more affordable all-plastic version is commonly sold under the “SG90“(*) name, usually with a blue plastic enclosure. Four of these can be found performing steering duty on the smaller Bricolabs rover. The slightly more expensive variant have metal gears and sold under the “MG90S“(*) name, usually with a brown plastic enclosure. Examples were put to work on Ryan Kinnett’s Micro Rover.

I’m sure “SG90” and “MG90S” started as model names from a specific servo company, but nowadays they have become generic names. I had thought they were all copies of a common original, but that was wrong. I bought a few batches from different Amazon vendors for research and took them apart. It is quite obvious there are multiple similar but not identical designs being manufactured and sold. In one instance, I bought same item number from the same Amazon vendor again (*) and received different units!

That experience taught me vendors treat these as fungible commodities and I need to account for that fact. Unfortunately, as they are similar but not identical, their variation puts an additional layer of complexity to my rover design challenge. It’s one thing to know dimensional tolerances will vary from one manufacturer to another, but here I don’t even know what range I can reasonably expect for those dimensions. Buying servos from different vendors resulted in a few data points, but I won’t know where those sample points lie on the global spectrum of sizes. It’s going to get a little murky!

But on the upside, it is great that we have such an ecosystem of micro servo suppliers, lowering cost and making them available to more people. Ultimately aligning with my goals for the small rover project. So what I need to do is buckle down and study what I will work with.


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

Starting Small For Sawppy Evolution

I’ve decided to tackle the challenge of designing two different Sawppy variants in order to address the needs of different types of aspiring rover builders. However, I am optimistic it would not require twice the amount of work. Despite their different sizes, ideally they would be more alike than different.

As stated earlier, they will both be six-wheel drive, four-wheel steering robot chassis with rocker-bogie suspensions. I want to explore ways to redesign the suspension components in order to move them away from having to cut metal shafts and e-clip slots, preferably in a way that can be scaled up and down to address both rover sizes.

For rover articulation, I’m moving away from serial bus servos. And by doing so, the motors used for six wheel drive can be different from the motors used to perform four corner wheel steering. Building an electrical architecture that can be scaled to both rovers should also make it easier for people who are already trying to build Sawppy variants at different scales.

I expect to experiment with the following types of wheel drive motors, and possibly more to be added later:

  • Brushed DC gearmotors (pioneer: Marco Walther’s Sawppy.)
  • Stepper motors (multiple requests.)
  • Serial bus servos (for those that want to reuse hardware from Sawppy V1)

And the following types of steering actuators, again with more potential additions later:

  • Commodity remote control hobby servos.
  • Serial bus servos. (V1 compatibility.)
  • Stepper motors (require something to sense position. Precedent: homing switches on 3D printers.)
  • Brushed DC gearmotors (also require position sensing of some sort.)

This is not an exhaustive list, they are just the starting point I want to keep in mind as I rework the software side of the system. I want to be able to use the same code base for both rovers’ control software. Hardware interfaces will be code modules that can be swapped out easily to match the type of motors and actuators used. Rover dimensions will be parameters that can be changed to match the physical chassis size. The code should preferably run on either identical microcontroller hardware or in the same family. For example, the current Sawppy running adapted SGVHAK rover software uses a Raspberry Pi 3. Perhaps the smaller Sawppy will run the same code but on a Raspberry Pi Zero to reduce cost. These and other venues are yet to be explored.

I’ve decided to start with the smaller rover for the following reasons:

  1. Smaller rover’s smaller parts are faster to print, so I can iterate through mechanical designs faster.
  2. If I start simpler and cheaper with the smaller rover, I expect it will be easier to scale up to something more complex and expensive for the larger rover rather than doing the reverse.

And the first step for a small rover is to decide on what actuators I will use for it.

Conflicting Requirements Call For Sawppy Variants

At the start of a project it is always useful to write down our mission objectives to ensure we stay on target and not lose sight of what we set out to accomplish. For future Sawppy evolution I have written a list of what I want to improve, and what I am/am not willing to compromise for those improvements. For the most part they look pretty good, but unfortunately I’m left with a set of conflicting requirements.

The first is my desire to make Sawppy easier to modify and experiment. This was actually a Sawppy goal from the start, and I thought leaving the aluminum extrusion beams unmodified would be the best way to do so. Unfortunately that meant using a lot of little fasteners to hold 3D printed parts onto those beams, and the sheer number of fasteners discouraged modification and experimentation as every project became a tedious slog of undoing and redoing fasteners. For the next revision I want to follow the precedent set by 3D printer chassis using these 20mm extrusion beams: drill holes through the middle of the channel to accommodate fasteners that can be larger and therefore we would need fewer of them. Drilling holes are an irreversible modification, but I hoped it would be worth the tradeoff. Unfortunately, drilling these holes accurately are difficult to do by hand and are best done with larger shop tools like a drill press and a vise holding the beam. Adding this requirement would exclude aspiring rover builders without ready access to such tools.

Another problem is that reducing fastener count can only go so far to make Sawppy simpler. Because these rocker-bogie suspension components are larger than the print volume of common 3D printers, these aluminum extrusion beams are required for structure. Building with beams impose a lower limit on parts count: every suspension subassembly would have the beam, the 3D printed connectors on either end, and fasteners to hold them together. The only way to be even simpler would be to eliminate the aluminum beam so we can 3D print Sawppy structures in single pieces, but that means shrinking everything down to the volume of a typical 3D printer. (Which I’m defining as something with print volume of at least 200mm x 200mm x 200mm.)

Shrinking the rover to be printable instead of relying on extrusion beams for structure would drastically reduce parts count, and allow people without access to tools like a drill press to participate in rover building. Such a smaller simpler rover should also be easy to build, with much simpler instructions for construction. Closer to what people expected from a commercial product. But a smaller rover would mean giving up a lot of capability on the high end, including flexibility for adaptation to experiments.

Seeing how a single design would not be able to accommodate the entire spectrum of rover builders, I’m splitting Sawppy into two variants: I’ll revise Sawppy at the current size (or possibly grow a bit larger) for the original audience of tinkerers and experienced robot builders. To accommodate those that would be left behind by the elevated prerequisites of such a design, I’ll also design a smaller variant that is easier and friendlier for beginners to pick up and build.

Summary of Sawppy Requirements

After more than two years of building Sawppy and publishing information for others to build their own, I’ve collected quite a list of things I’d like to change for future revision. I want to make Sawppy more affordable to buy, easier to build, and smoother to run. However, there are a few things I would not give up to accomplish those goals.

Chief among them is the six wheel drive, four wheel steering vehicle chassis employing the rocker-bogie suspension geometry of JPL Mars rovers Curiosity and Perseverance. This includes copying all degrees of articulation including the differential bar across the top of the chassis. A lot of other rover models sacrificed various parts of suspension fidelity to become cheaper and/or simpler. They might have reduced amount of articulation, or used fewer wheels, or driving fewer of them, or not steering them. These are valid tradeoffs but I’m not willing to make them for my project. Sawppy is unnecessary complex for flat ground and does not travel fast. But as a motorized model of Mars rovers, Sawppy will continue to maintain fidelity to all of those traits.

For steering the rover’s four corner wheels, I also want to keep the axis of steering rotation aligned with wheel center. This ensures any steering movement would pivot the wheel in place. It is much easier to build steering mechanisms with an axis of rotation offset from the wheel, but steering with such a mechanism drags the wheel through an arc instead of pivoting in place and I prefer not to do that.

On the construction side, I want to avoid risk of suspension joints binding up, which means ball bearings at as many axes of rotation as possible. I know I can keep using ball bearings for all suspension members, I’m pretty confident I can maintain ball bearings for the four steering axes, but as I simplify and reduce cost, I may have to give up ball bearings on wheel axles.

On the subject of wheel axle design, I still have a preference to maintain Sawppy’s excellent ground clearance, but I am more flexible about this topic as people don’t seem very fussed about compromising it as they modify their rovers. Another item of frequent discussion is the fact Sawppy’s wheels are not well suited to human-friendly floors but again they are accurate to their inspiration so I’ll probably keep them that way on my own creations. Fortunately wheels are relatively easy to modify or replace should other rover builders desire more traction.

I feel pretty good about these two lists: the things I want to change, and the things I don’t. However, putting all of these thoughts down also makes one thing clear: one rover size will not fit all.


[Title image: the Meeting of Rovers at Maker Faire Bay Area 2019]

Summary of Sawppy Update Objectives

Over the past few posts I’ve been describing goals and motivations for future Sawppy evolution. Mostly in terms of my own efforts, but with a few notes reminding me to leave options open for others working on neat stuff like Ardupilot adaptation. This post will be a summary, grouped by common themes with links to individual items. Most of these goals for improvement are the result of feedback from people who have liked my Sawppy design enough to spend their own time and money to build their own rover. I am thankful for every one who have reached out to me with questions, suggestions, and my favorite part: pictures and videos of their rovers roaming about. I always love seeing other Sawppy rovers running around.

Fix Mechanical Shortcomings

I’m thankful this section is much shorter than I had originally expected. I’m not a mechanical engineer and I honestly expected more fundamental mechanical issues than what has cropped up to date.

Make Construction Easier

Everything here can be traced back to feedback from one or more rover builders.

Improve World Friendliness

I’ve learned there’s more to designing a world-friendly rover than just working in metric.

Smoother Rover Operations

In contrast, most of this section were derived from my own experience taking Sawppy around.


That is a pretty long list of things I want to change! And on the way there, I also need to keep in mind of what I would rather not change.

[Title image: Sawppy and I at Sparklecon 2020]

Ardupilot as Sawppy Brain Option

Most of my attention for future Sawppy are focused on mechanical details like part numbers and rotating STLs for easy printing. I’ve always believed I would use Sawppy as a platform to explore autonomous robotics, but I’ve been having so much fun in low level mechanical design I have yet to set aside enough time to become proficient at giving Sawppy autonomy.

Thankfully the Sawppy community include people who have built their own Sawppy-derived rovers and put their own time into autonomy. Marco Walther was the first to adopt Sawppy software to ROS by writing a ROS adaption layer, translating the /cmd_vel twist commands into Sawppy motion. Rhys Mainwaring went much further and authored a ground-up ROS-based software stack for Curio their Sawppy-derived rover.

Rhys confirmed what I had feared from my limited ROS experimentation: much of the freely available open software modules for ROS are tailored for robots roaming building interiors. The occupancy grid, for example, is a 2D representation of a robot’s environment. This works well indoors where most walls are vertical and most floors are flat, but such assumptions break down outdoors. Even outdoor-focused autonomous research such as self-driving cars would occasionally simplify their environment into a 2D representation of surface streets. This simplification is very useful for certain problem domains, but a rover exploring rugged terrain is not one of them.

Rhys sent word that Curio development has progressed into investigation into Ardupilot. [Header image by Rhys.] The Ardupilot software stack originally started with autonomous aircraft, but it has since expanded to watercraft and ground vehicles. Its aircraft background also meant the software stack is quite aware the world has three dimensions and thus fewer systemic assumptions relying on two-dimensional simplifications. The Ardupilot ecosystem includes multiple vendors selling Ardupilot-compatible control units with a range of price and features, some open and some closed.

I will have to keep this potential venue in mind as I evolve future Sawppy. I was already planning to move away from serial bus servos and towards more commodity hardware, and now I have another reason: using commodity hardware also improve the chances that an Ardupilot control unit can be found to interface with such components. This is an exciting possibility that really motivated me to get started working on Sawppy evolution!

Rotate Sawppy STLs For Printing

For future Sawppy iterations, I’ve decided I should put identifiers on 3D printed components to help with parts management. Another thing I could do to help other Sawppy builders is to orient the STL files for printing. I had published a set of Sawppy STL files upon request, but I did it reluctantly. Due to the challenges of precise dimension tolerances required for heat-set inserts to work well (plus interaction with other unyielding parts like 608 bearings) I expected that my STL files would not suffice for most builders. Which is why I made Sawppy’s Onshape CAD document public as well, so people can tweak dimensions and generate their own STLs.

My expectation turned out to be correct for some builders, who then had to learn enough Onshape to generate STLs tuned for their heat-set inserts and assorted other parts. But many others chose not to do so. I have since learned that a fraction of them were relative beginners who were intimidated by the thought of picking up CAD. They just wanted to download STL files, load into their printer slicer, and go.

Reducing Sawppy construction complexity was something already on my list for my own sanity, but it would also make Sawppy more approachable for beginners. It would be helpful if I could orient every STL file for printing. My published set of STL were oriented exactly as they were installed on Sawppy, and I expected 3D printing enthusiasts to know how to find the correct face to place on their print bed. I was wrong for the beginners, which I realized after receiving some messages asking for help. These messages included pictures of Sawppy parts printed in the wrong orientations. Not only are print layers in the wrong direction for optimal strength, the parts were also covered with auto-generated support structure that were difficult to remove.

This orientation challenge was the worst for Sawppy’s corner steering joints. These objects have an angled side that were the result of trigonometric math for scaling Curiosity’s suspension geometry, and the result was not a nice even number of degrees. Even worse, I had designed those faces to be facing the print bed. Which meant it was up to the user to find some way to make their slicer automatically align to this oddly-angled face. At the time I was using Simplify3D as my slicer, which has a straightforward “Place Surface on Bed” tool. Unfortunately not every slicer has an equivalent feature, and even if it did, it may be named differently. Thanks to the Sawppy community I collected information on how to do this for several other slicers, but it would be better if people didn’t need to worry about it at all. I did the math in CAD, I can perform the rotation in CAD so nobody else has to deal with it.

Doing so would raise the odds of success for relative beginners to build Sawppy, without penalizing people investigating advanced techniques like adapting Ardupilot.

Sawppy Parts Management

Documenting the reasoning behind decisions and their execution is a challenge on any team project, but absolutely required if all team members is to be on the same page. I’m sure there were a lot of JPL documentation to make sure everyone understood exactly why everything on Curiosity rover (wiring included) was the way they were. But while spacecraft projects can have a documentation system the entire engineering team is expected to follow, a public project on the internet has to cater to a wider audience.

This was a problem I knew about as soon as I decided to share my Sawppy rover design with the world: I have to assume my readers will have varied backgrounds, and I would not know what is and isn’t obvious to other people. Everything seems simple and straightforward to me, since I designed and built this little motorized rover model on knowledge level I have. But if I want to make Sawppy available for others to build, I have to communicate my design so that someone who doesn’t live in my head (that should be none of you) can build their own Sawppy even if they didn’t know everything I did. And just as expected, I was not completely successful.

I created Sawppy piecemeal, designing and printing parts of a subassembly until they worked together before moving on to another part of the design. However, some rover builders would print all the parts I published before starting assembly, which meant they ran into a problem that caught me off guard: tracking these parts and their proper roles in assembly. I thought I addressed this by making sure Sawppy’s Onshape document is public for people to reference, but it was not quite enough. Some superficially similar parts still caused confusion.

For something like the JPL Open Source Rover, which is built from ServoCity Actobotics components, the instructions can assign designations to parts using Actobotics descriptions. However, for Sawppy’s 3D-printed parts, all I have are their names in Onshape which I carried through to the STL file names. But once printed, that association is lost. I had no problems with this since I knew each part by heart, but I neglected to consider others would not have that knowledge.

The solution is to make sure part identifiers are imprinted on the part somewhere, so they are readable after they are removed from the 3D printer and more importantly available for reference during assembly. This is something I hadn’t thought of but, upon reading the excellent article on Hackaday by Joshua Vasquez, I realized it is an excellent idea and I must incorporate it for future Sawppy parts.

Wire Management on Mars Rovers

While I’m on the topic of keeping wires tidy on my Sawppy rover, I thought it is a good opportunity to take a little detour and look at wiring on real rovers going to Mars. Or at least, their Earthbound test counterparts which as far as I can tell got the identical treatment on wire management. After all, their job is to replicate the Mars robot explorers as closely as possible for testing here on Earth. Most of the differences are centered on electrical power supply, because these rovers can run on what is essentially an extension cord. The Spirit/Opportunity sibling “Dusty” doesn’t have working solar panels, and the Curiosity sibling “Maggie” doesn’t have a nuclear reactor. But other than that, they strive to be identical which I assume also included the wiring scheme.

Looking at the family portrait of Earthbound test vehicles, we can see that a lot of wiring out visible on the surfaces. Running alongside structural members like suspension arms and equipment bay. I found this extremely fascinating! Why are the wires outside instead of tucked inside? My first thought was that the major wires are tucked inside and those visible outside are less important auxiliary channels, but that doesn’t seem to be the case.

During discussions about the damaged wheels on Curiosity, it was mentioned that the greatest risk is not that the wheel would be unable to roll. The greatest risk are that jagged pieces of protruding wheel may cut some of these exposed wires rendering motors and sensors inoperable. This tells us those exposed cables are in fact critical to rover operation and not merely less important items left exposed. Though they are exposed, they are not wild and unruly. In fact they are exceedingly tidy. In fact, NASA and JPL have precise specifications regarding wire management, and rover wire bundle installation represents the state of the art in cable lacing.

So… why on the outside? This isn’t the kind of information that NASA JPL puts in their publicity packets, so I’m left to speculate. The first observation is that all the usual reasons to shelter wires don’t apply to Mars. Here on Earth, exposed wiring bundles are quickly degraded by exposure to the elements. In contrast, Mars has a thin atmosphere and no weather to speak of.

Second, with the wires exposed and accessible, it makes diagnosis and repair easier. This isn’t a joke about repair technicians on Mars, but referring to vehicle assembly here on Earth. As the rover is put together and their integration tested, problems would inevitably crop up. Thus there is value in accessing wires for diagnostics and repair without having to take apart components of unrelated systems. What makes things easier for a little Sawppy rover here on Earth is equally valid for a rover being prepared to go to Mars. But this is all just speculation. All we know is that the penalty of running wires externally did not outweigh whatever benefit they expected to get. Ease of access has value, as keeping track of everything in such a huge project is a major undertaking all on its own. Tracking parts for a little Sawppy rover gets confusing enough.