Micro Servo Angular Position Inconsistency

I got my little rover Micro Sawppy Beta 3 (MSB3) up and running controlled by a wired joystick. This joystick was very simple and affordable but it also had poor proportional response. It was not significantly different from using a digital directional pad, Atari 2600 style. It induced some pretty abrupt movements as I tried to drive MSB3 around, but as a silver lining, it also exposed a problem that went un-noticed in the much gentler MSB1: micro servo angular position isn’t consistent.

To get a better look at this problem, I dug up one of my earlier ESP32 test projects that turned it into a simple servo tester. I plugged all four micro servo motors into the board, so they all receive the same PWM control signal. I then adjusted the signal so they all pointed straight ahead. A little mechanical trim adjustments were needed to get the title image where all wheels were physically aligned.

I then turned the knob on my servo tester and watched all four servos move in not-quite-unison. As we get further and further off center, we can see the steering angles start to vary from one servo to the next even though they are all receiving the same control signal.

I did not see this problem on MSB1 or the cardboard box rover testbed. For MSB1 it might have been related to the fact it used different control electronics, which didn’t fling these servos from one extreme to the other. But a likely contribution is the possibility servos have better consistency within the same batch. All four MSB1 steering servos are from the same batch. The cardboard box rover testbed steering servos are from a different batch than MSB1, but all four are from the same batch.

In contrast, MSB3 has steering servos from different vendors, and different batches. (One of them is even a metal gear MG90S instead of the plastic gear SG90 of the other three.) This came about because I had been testing different servos earlier, but somehow I didn’t notice the angular position discrepancy until now.

As a practical matter, I think this variation is not ideal but within acceptable bounds. This lack of accuracy will merely be noted as another luxury we traded off to lower parts cost of a Micro Sawppy rover. So I’ll leave it and move on as there are lots more tinkering still ahead.

Configurable Micro Sawppy Servo Power Supply

My first soldered control board for Micro Sawppy was a huge mess of wires, most of which were related to power distribution. I am confident future revisions will improve, partly from experience and partly from features that I won’t need anymore. One of them is visible in the center of the title picture: a jumper by a MP1584 buck converter voltage regulator. It allowed me to switch between powering the servo with that buck converter and powering the servo directly from battery input power.

Earlier I had determined that four AA alkaline batteries had the right voltage for SG90 micro servos, but that voltage would sag significantly under the load of TT gearmotors driving six wheels. Adding another battery would destroy the servo when the system is unloaded. I knew there were a lot of power losses on my earlier breadboard-based prototype. I thought a soldered board would be a more accurate test. But while it may have made some difference, it was not enough to help Micro Sawppy run reliably on four AA batteries.

If Micro Sawppy is to be powered by alkaline batteries and still avoid using a voltage regulator for servos, I would have to move upscale to higher amperage C or D batteries. I also contemplated the idea of trying one of those large rectangular 6V lantern batteries but they all share the problem of availability. Alkaline C, D, and lantern batteries were once commonplace, but they aren’t very common anymore. I had a few NiMH (nickel-metal hydride) rechargeable batteries in AA form factor, who have the ambition to replace C and D batteries with a few adapter sleeves. I tested them and also found they could not sustain the required amperage under heavy draw.

I could also have multiple four-AA banks in parallel, or have separate power sources: one bank of four AA batteries just for steering servos, driving the remainder of the rover on some other power source. This complexity feels extremely inelegant and I can’t yet think of any reason why this path would be better than conceding that I will need a voltage regulator for steering servos.

So I moved the jumper to the other position, and started using a MP1584 buck converter breakout board set to produce 5.4V. This is between the valid range of 4.8V and 6V, and it is two volts under the nominal 7.4V of 2-cell LiPo I’m using to test this circuit. This two volt margin should be enough for MP1584 buck converter to work.

I used a MP1584 breakout board here because I had leftovers from a multipack (*) I bought for earlier projects, but I’m not confident they are the right device for the job. The datasheet claims it can sustain two amps of output with occasional spikes to maximum of 3 amps. Four SG90 micro servos would usually stay well under that limit, but their power consumption can spike occasionally making capacity planning unpredictable. At the very minimum I should put an electrolytic capacitor to buffer its output, and experimentation will tell me if I need more than that. I might also try to monitor the input voltage level.

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

Aftermath of Exceeding SG90 Micro Servo Six Volt Maximum

I wanted Micro Sawppy rover to be a beginner-friendly design, which meant avoiding the hassles of working directly with lithium chemistry rechargeable battery cells. I investigated a few options, starting with four AA alkaline cells in series, but none were able to sustain power in the five-to-six volt range I sought. Sagging under four volts in the worst case. I thought the next obvious step in the investigation would be to add an AA battery for five AA in series. This was a mistake.

I had examined micro servo electronics earlier, and I found that operating at their quoted 4.8V nominal voltage was actually unreliable. I really needed to feed them at least five to six volts. In my experiment earlier, I found my little servo could operate at 7.4V (nominal voltage of two-cell lithium cells) but would not tolerate 8.4V (fully charged two-cell lithium cells.)

Based on this knowledge, I thought five AA cells would be fine, as they would have a maximum voltage of 7.2V. However, I had forgotten that my high voltage experiment were on a MG90S servo, not a SG90. And with the variation of electronics across all those servos I had taken apart, results for one wouldn’t be reliable for another anyway. I added the fifth AA cell and, immediately upon applying power, I smelled the telltale scent of unhappy electronics.


I disconnected power and examined my two servos that no longer responded to commands. They were warm to the touch and have a distinct bulge of melted plastic on their enclosure. The title image showed one of these damaged servos (right) next to an unused servo from the same batch (left) both angled to highlight surface features. I opened up the bulged case and saw the servo control chip has melted the top of its chip packaging. And not only that, it melted a rectangle into the blue plastic enclosure which was directly under the bubble.

It is obvious that I should not feed these micro servos any more than 6V, the historical standard for remote control hobby electronics. Derived from the voltage for four fully charged nickel-cadmium (NiCad) battery cells in series. Which meant if I wanted to increase power level for the rest of Micro Sawppy, I would need a regulator to ensure micro servos input voltage do not exceed 6V. This would mean extra components and complexity, but at the moment I see no way around it.

There is a slim chance the problem isn’t as dire as it appears at the moment. My cardboard box rover uses a breadboard and jumper wires to create its circuitry, and this system doesn’t have very high current-carrying capacity. It is possible that I’m losing a lot of power to resistance of thin wires, a problem that has occasionally plagued past projects. Now that the breadboard and jumper wires have done their job of exposing problems in a prototype, I should move on to a circuit board with soldered connections. Trying four AA batteries on that circuit would be a better representation of the little rover’s power situation, as well as freeing me from physical constraints of breadboard dimensions.

Micro Sawppy Rover Cardboard Box Testbed

Proving that I could control DRV8833 DC motor driver IC using an ESP32 was the final piece of the foundation I knew I needed before I seriously start building a micro Sawppy rover brain on an ESP32. During my development of this software, I will need a physical chassis to test code on. While I could go straight to my Micro Sawppy Beta 3 (MSB3) chassis, doing so has the risk of breaking physical robot hardware. Anything from a servo moving beyond intended limits, to embarrassing mistakes like driving the rover off the table.

A safer option is to have a representative testbed with fewer risks than a physical robot. For my original Sawppy rover, I removed all ten LX-16A serial bus servos and laid them out on a table. I found that a line of servos wasn’t very good at conveying system behavior, since I had to do some mental spatial transforms in my head to interpret those servo movements. Some bugs slipped through this process because I made mistakes in my mental visualization. From that experience I thought it would be better to have a testbed that better represented the physical layout of the rover chassis, and this is an opportunity to put that idea to the test.

In line with my recent discovery of cardboard for mockup purposes, I pulled a cardboard box from my paper recycle bin. I turned the box inside-out to give me some clean note-scribbling surfaces, plus I’m not advertising that product on this site anyway. Holes were cut in the cardboard so I could use twist ties to fasten six TT gearmotors in the same relative location as they would be on a rover. I also cut four rectangular holes for the steering micro servos. Since I cut those holes by hand, the imperfections of the manual cut gave the servos enough friction to sit in place without any fasteners.

Wires for all of these components went into the box, and small holes were cut so they could poke through to this top surface. This routing keeps all excess lengths of wire out of my way making for a neater work area. The ESP32-based control board, whatever it ends up being, should fit in the center area I kept clear for it. Excess wire isn’t the only thing I kept in the box, it was also a convenient place to store all the related auxiliary pieces related to the project. Each micro servo has a plastic bag with spare control horns as well as their mounting screws not needed for the testbed. And each gearmotor came with a wheel that’s not strictly necessary for the testbed. There’s a chance I’ll want these wheels later, to better visualize relative rotation velocity of the wheels. If that should occur I know where to find the wheels: they’re in the box!

But first I need to get started with Sawppy ESP32 software.

SG90 Micro Servo Strength Test

The weakest point in my Sawppy V1 rover were its shaft couplers, but that bug also became an accidental feature: when the system is abused, being the weakest link meant it is a sacrificial element to break before anything more expensive would. I am now designing the servo steering mechanism for Micro Sawppy Beta 3 (MSB3) and wanted to know: do I also have an (accidental) abuse-absorbing feature on the little rover?

This was something fairly easy to test and, thanks to the low cost of SG90 plastic gear micro servos, I was willing to sacrifice one for this knowledge. I put together a MSB3 prototype steering assembly and wired the servo to power and control signal, telling to hold straight center. If I wanted to be scientific I would use a torque wrench or something to quantify the forces as I test, but I didn’t have the proper equipment so I just used my hand.

The answer is no, nothing else in this steering assembly for MSB3 will step up and absorb abuse on behalf of the steering servos. It took surprisingly little force from my wrist before I heard something snap. I disassembled the gearbox to see not one but two failures: A tooth is bent (but still attached) on the final output gear, and another tooth has broken off from the adjacent meshing gear.

Since I didn’t use an instrument to quantify the breaking force, I don’t have objective numbers to post here. Subjectively I felt the breaking point was beyond what I would reasonably expect from a little rover in normal roaming, which is good for rovers rolling along minding their own business. But I want micro Sawppy to be something a teacher can introduce to their class, and I didn’t think the breaking point was beyond the capabilities of curious/destructive children, and so the fragility worries me.

I’m sure MG90 metal gear servos would fare better, but would they be strong enough? I’ve already sacrificed a few MG90s to experimentation and I’ll want to set up proper instrumentation before I sacrifice another. And obviously a MG90 is more expensive than a SG90. Is it better to use affordable SG90 servos and replace them as needed? Or is it better to go straight to MG90 for higher durability? Answering this question definitively would require real world usage data. See how often SG90s require replacement, and whether the replacement rate is greater or less than the up front-cost increase of using MG90 servos. In order to obtain this real world usage data, I’ll have to keep working on the rest of the rover.

Micro Sawppy Beta 3 Steering Trim

Getting a pair of bearings aligned with the wheel contact patch is a feature on all Sawppy rovers, so that in itself wasn’t new. But Micro Sawppy Beta 3 (MSB3) did try a new way to mount bearings, and I’m optimistic it’ll make future Sawppy designs easier to build. On top of that steering joint, I’ve also modified the servo attachment for another feature I wanted to put on my rover designs: mechanical steering trim adjustment.

Sawppy V1 had a software-based trim adjustment system, where the center point of each steering servo could be adjusted by modifying a value in a text file. I though it was something that I could set once and forget but I was wrong. The potentiometers used to sense position inside a servo motor drifts over time (and temperature, and humidity, and phase of the moon…) so in reality steering trim had to be adjusted fairly frequently.

For MSB3 the servo horn bundled with a micro servo is mounted on a 3D-printed piece with an arched hook in the front. I could then fasten it to my steering assembly with a single screw. Steering trim adjustment becomes a matter of loosening that screw, sliding to a different point within that arc, and tightening the screw back down.

Another advantage of this design is that, unlike MSB1 and MSB2, the servo is freed from handling any structural loads. It is now responsible solely for steering just as servos were for Sawppy V1. It is a feature I’m glad I could bring to a smaller scale. I thought about going one step further on ease of assembly, and tried a few clip-on servo mounting brackets for tool-less assembly and replacement. (Pictured.) But even though these little servos assert little torque, there is enough to distort 3D-printed plastic and affect steering accuracy so I returned to the concept of a screw-down servo bracket.

But the experience did remind me of one thing about Sawppy V1: I didn’t like using heat-set inserts on shaft couplings because they would slip and break. However, that slippage and breakage did have an advantage when Sawppy is stressed beyond design limits. When a child decided to break my rover, the coupler broke before that abuse was transmitted into the servo. What would happen to this little rover servo?

Micro Sawppy Beta 3

Gaining a basic understanding of how to use the L298N module to control DC motors was an important confidence booster for modifying my little rover plans: Switch the rover’s six-wheel drive from micro servos modified for continuous rotation to a different approach: TT gearmotors that are designed from the start to drive wheels. They even come with one of the most frequent Sawppy requests: soft rubber wheels that are expected to have better traction on earthly surfaces. Steering the little rover’s four corner wheels remain the duty of micro servos, which would be doing their designed job of rotational position actuators.

The first rover chassis to emerge from this new plan is Micro Sawppy Beta 3 (MSB3) shown here next to its predecessors MSB1 and MSB2. Changing the wheel drive mechanism has a huge impact on the overall design, as this family portrait shows. A new rocker-bogie suspension implementation is the focus here, relegating the body back to a simple box as it was on MSB1.

The next few posts will cover some of the highlights of mechanical design changes for MSB3. Changing the wheel drive motor required a completely new steering knuckle design for the corner wheels. Which became an opportunity to design a multi-piece mechanism that would allow me to quickly adjust steering trim at mechanical level. Increasing the number of parts does make the mechanism more complex, but I am optimistic it would actually prove to be easier to build. MSB3 also represented a new way to use 623 bearings that hopefully eliminates the sensitivity to tightening torque. And the revamped rocker features an improved adaptation of the real rover’s rocker deploy pivot allowing the rover to fold up for transport. And finally, the differential linkage is a further evolution of using 3D printing to avoid having to scour remote control hobby catalogues for an adjustable suspension turnbuckle.

This tour of MSB3 starts at the same place as its predecessors, from the wheels. Then we’ll work our way up.

DC Gearmotors For Little Sawppy Rover

Based on my experience modifying wheel drive motors on my little rover Micro Sawppy Beta 2 (MSB2), I decided it was trending towards a rover design that would be too difficult to work on. If I, as the designer of MSB2, am tearing my hair out struggling with wire routing, how can I realistically expect beginners to work with this thing? I think MSB2 succeeded at being really cute, unfortunately the beauty was only skin deep and its core difficulties are not what I want.

But while I stopped further work on MSB2, I wanted to continue the task I was in the middle of: trying out the idea of using DC gearmotors. The micro-servos I used in MSB2 taught me that my original idea for driving little rover wheels were unreliable. While we could modify micro servos for continuous rotation, there’s no guarantee their control circuits would give us usable speed control. Sometimes they don’t! In order to guarantee a little Sawppy rover could be reliably built, I must take motor speed control into my own hands.

This decision started when I removed all electronics from MSB2 wheel servos, using them as just a motor with a gearbox inside a micro-servo sized enclosure. (FYI Adafruit product #2941 is exactly like this, no modification required.) Even though I’m throwing out half the device, it’s still a very inexpensive way to obtain a small DC gearmotor thanks to the large volume market of generic commodity micro servos. But if we are going to use a small high volume commodity DC gearmotor to drive little rover wheels, there’s actually a better option: TT gear motors.

These DC motor + gearbox units are ubiquitous like generic micro servos, mass produced by many manufacturers at high volume and low cost. It is available as Adafruit #3777 but they are definitely not the only retailers. (*) I first learned they existed when I saw them pop up in multiple projects submitted to a Hackaday contest, and a little background research unveiled how widespread they were.

Since I’ve decided to add the complexity of DC motor driver modules, these TT motors immediately jump to the top of the list. Unlike micro servos, TT gear motors were designed for driving wheels.

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

Micro Sawppy Beta 2 Wire Channels Are Too Hard To Work With

My little rover project Micro Sawppy Beta 2 (MSB2) turned out to have (effectively) three speeds: stopped, full speed forward, and full speed reverse. MSB2 originally intended to get its six-wheel drive from inexpensive micro servos modified for continuous rotation. This approached worked for its predecessor MSB1, but MSB2 used servos from a different manufacturer and their feedback control circuit had very poor (or poorly tuned, or nonexistent) proportional control. As a result it was nearly impossible to drive MSB2 at partial throttle.

Given this setback opportunity to try other ideas, I started modifying all six wheel drive servos. I unsoldered the flawed control circuit board and soldered wires directly to the motor input terminals, intending to route those wires to a motor control H-bridge circuit of my own choosing. This would mean I’m only using the mechanical portions of the micro servos, effectively turning it into a DC gearmotor.

But I only got halfway. Unsoldering the board and soldering motor wires is well within my comfort zone, but wrangling with wires got very tedious and frustrating. In order to replace the three-wire continuous rotation servo wires with two-wire motor control, I have to struggle with the intricate wiring channels I’ve designed into suspension components. In fact I have to struggle with it twice: once to remove the wire, and once to add the replacement.

That’s when I realized MSB2 has failed some very important project objectives: making the rover easy to build, easy to diagnose, and easy to repair. For the three wheels I managed to convert, it took far more time to wrestle with the wires than it did to perform soldering, and that’s just wrong. I want a design where, if a servo dies, it can be quickly replaced to get the rover back up and running. The wiring channels may give us a tidy looking rover, but not one easy to work with. As a result I’ve decided MSB2 is going down the wrong path and stopped work on this iteration. But I am thankful for the cute little rover, it taught me the tradeoff for tidy wiring and gave me motivation to examine using DC gear motors to drive a little rover’s wheels.

Micro Sawppy Beta 2: The Runaway Rover

Once I built up my little rover Micro Sawppy Beta 2 (MSB2) I observed that its steering servos were acting differently from the batch I used for MSB1. Beyond the clearly visible physical differences, these servos also had different control logic that can get into a never-ending oscillation.

A contributing factor here (if not the main factor) is that this micro servo’s motor control logic is far too eager in its corrections. It applies too much power and, if that power is not absorbed by damping, we have over-correction which repeats the cycle. In theory the motor controller uses power in proportion to the error in position. If the target position is close, it should use less power than if the target was far away. This particular servo control board has poor (or at least poorly tuned) proportion control. It seems to use the same amount of power whether the target position is close or far away.

The occasional oscillation is moderately annoying for rover steering, but at least it is usually damped out when the rover is sitting on its wheels. I didn’t experience the full impact of control algorithm used in these micro servos until I converted them to continuous rotation for rover’s six wheel drive. Now the poor proportional response manifests in a rover that I can’t run at partial power. I could make MSB1 crawl slowly up obstacles, but MSB2 didn’t want to crawl slowly like a real Mars rover would. It is either stopped or booking across the landscape at full speed.

In this scenario I suppose I could also apply damping by increasing the workload. Which means either adding friction to the drivetrain or making the rover heavier. This is assuming the motor will exhibit proportional behavior at higher load levels, which is possible but not yet proven. But despite the light weight causing other problems, I didn’t like the idea of adding friction or weight purely for the sake of ballast. So I am going to explore a different venue by removing the flawed servo control board. I’ll have to find some other motor controller and use only the mechanical portions of these micro servos as a DC gearmotor assembly.

Micro Sawppy Beta 2 Has The Shakes

The robot arm I built as a test mockup for my little rover Micro Sawppy Beta 2 (MSB2) was a simple manually-posed affair. I wanted to get a better feel of how such a thing would articulate before I put in the work to motorize it, and I had no suitable actuators on hand anyway. In fact, I had no idea what I would use for such a project, since I found problems with the micro servos I’m already using in this project.

There are a few robot arm designs built around the same small affordable micro servos. For example, the MeArm is a super minimalist robot arm designed to be assembled from laser-cut pieces. I’ve seen a few MeArm in person and based on how they moved, I could tell there are some challenges to use them effectively. One problem I witnessed was that, under certain circumstances, a particular servo would get into an oscillation bouncing on either side of the target position. Unable to ever reach that position and hold it steadily.

I built and ran MSB1 without seeing such behavior and had been feeling pretty good about things, but MSB2 used a different batch of micro servos from a different manufacturer. With this batch, I saw the same oscillation I saw on a few MeArm affecting MSB2 steering and I think it’s coming from certain servo control boards. Or at least I don’t see how it could be caused by my mechanical design changes between MSB1 and MSB2.

The comments on my tweet support my hypothesis: this batch of micro servos have some shortcomings in its feedback control logic to cause this behavior. I think it is very likely a deliberate engineering tradeoff decision dropping some feature to make it cheaper, given that these micro servos were built to minimize cost. There were multiple suggestions to add damping which does indeed mitigate the problem. For MSB2, this oscillation only occurs when I hold the steering mechanism up in the air. Once I set down the wheel, friction between wheel and ground adds enough damping to stop the oscillation.

I’m feeling particularly irritated at this servo behavior, because it turned my beloved feature into a bug: the smooth low friction rotation enabled by ball bearings is a contributing factor for this oscillation. If I didn’t use ball bearings and had high friction steering, this oscillation would probably not happen. But annoying as this was for steering, it became a disaster for driving.

Micro Sawppy Beta 2

The main objective of MSB1 was to establish that a scaled-down rocker-bogie suspension system could nominally function and expose problems along the way. That objective did not require much of a rover body, so MSB1 only had a minimalist “Scarecrow” box. The main objective of MSB2 was to build upon its established suspension system and add a body with some resemblance to Mars rovers Curiosity and Perseverance.

On top of that body is not a realistic model of a rover camera array. Instead, it has a smiling face, which follows the precedence set by rover illustration JPL used for Mars 2020 “Name the Rover” contest (resulting in Perseverance) and that of ESA’s ExoMy rover. I had contemplated various ideas on how the face can change, maybe small OLED panels or an e-ink display. For this first trial I just drew a face with black marker. (There was also a layer of cellophane tape to block marker ink from capillary action.) I did this during a virtual meet of makers and I was surprised that a simply drawn smiling face made a hugely positive difference on how people perceived my little rover project. Though I probably shouldn’t be surprised: there was a similar change in perception when I added googly eyes to Sawppy V1 after seeing it done by another Sawppy builder. A tiny change makes people smile.

For electromechanical actuation, MSB2 used MG90S metal gear servos from a different manufacturer so I can compare how they perform against the ones used in MSB1. This particular batch were the MG90S that had a mild case of false advertising: only the final output gear was metal (visible as silvery metal) and the remainder were all black plastic. The two batches were bought from the same Amazon vendor on the same product page (*) but they are obviously distinctly different products. One of the differences had a serious impact on MSB2 and changed the direction of the project, more details in a future post.

I originally intended for MSB2 to be up and running in time for launch of Perseverance rover, but as is usually the case, other things happened. All I could do was a short video where I manually moved MSB2’s poseable arm waving a flag cheering Perseverance on. But it became a part of JPL’s official launch tweet, and I’m quite happy with that accomplishment even as I work through MSB2 design problems.

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

Micro Sawppy Beta 1 Suspension Bogie

Continuing the tour of micro Sawppy beta 1 (MSB1) from the ground up, the rear steering knuckles are attached to the suspension bogie. In Sawppy V1, the bogie’s attachment joint to suspension rocker had a mechanical design oversight: there were no mechanical limiters to rotation angle. I didn’t realize it was even a problem until Sawppy over-rotated during a climbing demo and flipped the bogie assembly, pointing mid and rear wheels skyward. Not only does it render Sawppy immobile, but it also puts a ton of stress on the wiring harness. I designed and installed a crude limiter to prevent wire breakage, but solving the problem more elegantly was on my to-do list. MSB1 represented the first attempt.

The joint itself is an adaptation of Sawppy V1’s design. A pair of bearings are embedded in the printed joint. On Sawppy a length of 8mm metal shaft is used as rotational axle, and the bearings are held in place with E-clips cut into the shaft. I wanted to move away from those clips so here I’m trying Ameer’s idea of using fasteners directly. In the case of MSB1, M3 screws.

A washer is used as spacer to give the bogie a little room to rotate without rubbing against the rocker arm, this aspect was the same as on Sawppy V1. (After I took this picture I realized the washer is shown installed on the wrong side, they’re supposed to be on the far side of the camera.)

I was wary of bearings damaging the M3 thread, but hoped the rover is light weight enough that it would not become a huge issue. That turned out to be secondary to a bigger problem: this design is very sensitive to how tightly the fastener was torqued down. In Sawppy V1 this wasn’t a problem because the e-clips stay in their slots. But as this screw is tightened, it presses down along bearing center axis. Too much pressure, and the bearing could no longer rotate smoothly. Too little pressure, and the joint rattles. This is a problem shared with a few other designs like the 4tronix rover, which mentioned this specific issue in their online assembly instructions.

I put that on my list of new problems to think about, and moved on to the old problem of over-rotation. I 3D-printed several ideas to interrupt rotation in some way and eventually settled on this design:

A little C-shaped piece of plastic that can clip into place over the M3 screw. One end goes over the head of the screw, and the other end covers the nut on the opposite side. This keeps its center portion in place between the rocker and bogie suspension components, preventing over-rotation. This draft is bulkier than it needs to be, I will thin it down for future revisions so it looks less like a big wart on this bogie’s connection to suspension rocker.

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.

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.