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.