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.

Uh-oh.

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.

Initial Thoughts on Micro Sawppy Rover Battery Power

Wiring up all the motorized components on my cardboard rover testbed exposed a few minor problems that were easily fixed, but exposed battery power as a headache I’ll have to deal with. Sawppy Rover V1 and Micro Sawppy Beta 1 both used lithium-polymer battery packs from the world of remote-control hobbies. They are lightweight and powerful, but they are also sensitive to mechanical damage and occasionally react very badly to abuse. I have ambition to make Micro Sawppy a small beginner-friendly rover design, so I didn’t want people to be intimidated by all the dire warning surrounding proper LiPo care and feeding. Also, while lithium battery costs have dramatically dropped over the past years, they are still relatively expensive and I wanted to keep Micro Sawppy affordable.

Which was why for my cardboard rover testbed, I started with a pack of four AA alkaline batteries. Alkaline AAs are common, inexpensive, and tolerant of abuse. Four of them in series deliver a maximum of six volts, aligning with the maximum rated voltage for TT gearmotors and SG90 servos I used on Micro Sawppy. Which is why a four-pack of AA is a very popular way to power small robot kits using those components. The difference is that they usually only have a pair of TT gearmotors, whereas Micro Sawppy has six. They also have fewer than four SG90 micro servos like those handling corner steering here. With all of these components, my cardboard rover has proved to be too much work for four AAs. Dragging its output voltage below four volts and triggering a brownout reset of the ESP32 brain.

My next idea on a way out of this predicament is to use a commodity USB power bank. They produce nominal 5V for charging USB devices. They are usually built around lithium batteries, but they are a self-enclosed device with a durable shell and protective circuitry. Making them a beginner-friendly safe way to incorporate lithium battery power. Officially USB1 only allowed devices to draw half an amp at five volts, which is not nearly enough for a rover. But newer USB power banks advertise higher power levels, some of them communicate using a secret handshake to indicate this capability. I had a few different power banks on hand, advertising maximum output of up to 2A. Unfortunately none of those were able to sustain power delivery for my cardboard box rover, either.

All of these power sources advertised power ranging from 5V but none of them could sustain that under the load of Micro Sawppy motors. I then returned to the idea of using alkaline AA batteries and thought… what if I added one battery, for five AA batteries in series? The answer is: some micro servos get very unhappy and quit.

Cardboard Rover Testbed Wheels Turning And Steering

Once I figured out how to handle power for ESP32 on my cardboard box rover testbed, I started connecting the rest of the components. Since I had motor control PWM code ready to go, I started by connecting the DRV8833 breakout boards one by one to the power rail. Which for this experiment was a battery holder for four AA alkaline batteries that had a power switch built in. (*)

I wanted to start with 4 AAs because alkaline batteries are commonplace and more importantly, tolerant of abuse compared to sensitive lithium ion batteries. I’m not squeamish about working with lithium battery packs personally, but I am squeamish about using them on a rover design I want to advertise as beginner-friendly. Four fresh AA batteries in series would deliver 6V, which is coincidentally the maximum spec voltage for both SG90 micro servos and TT gearmotors. Thus a four-pack of AA is a common power supply for little robot kits using similar components.

Here I am thankful for the LED indicating power supply, which was not part of the DRV8833 data sheet but added as a bonus on the particular breakout boards I had bought. Each module was powered-on to verify the power LED illuminated, then I turned it off to install one wheel. After I turned it back on to verify one wheel is working correctly, I would turn it off and connect the other wheel for verification. Testing parts one step at a time ensured that whenever something went wrong (and they did) I would know where to start looking.

As I connected more motors, I noticed that the DRV8833 power LED would visibly dim when the wheels start turning. To monitor voltage, I wired in a compact voltmeter(*) originally purchased to monitor battery voltage on Sawppy V1. I saw the voltage would sag from nearly 6V to just under 5V. More of a drop than I had expected, but with all six wheel drive motors in place I thought I was in good shape. It turned out I severely underestimated the peak power draw for four corner steering SG90 micro servos. When those little servos are trying to reach a new position ASAP, they seemed to draw more than the TT gear boxes despite their physically smaller motors. During regular operation my four-pack of AA would struggle to stay above 4V, and if the steering servo encounters any obstruction, it would drop below 4V causing the ESP32 to brown out and reset. This is obviously Not Good and I will need to put more thinking into power supply.


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

Cardboard Box Rover Testbed ESP32 Power Supply

Power distribution is a concern in any electronics project, but a breadboard ESP32 circuit mounted on a cardboard box rover stand-in has an additional twist: USB. When a USB cable is plugged in to my ESP32 dev kit to upload new firmware and serial monitoring, it is also connected to the computer’s +5V power rail. But when my rover is out and about on its own, that USB connection will be absent and ESP32 will have to draw power from the onboard battery.

I initially thought I would have to install a 5-volt regulator on my rover to power the ESP32, much as how I had been using MP1584 buck converters to power Raspberry Pi 3 for earlier projects such as Sawppy V1. Then I remembered the ESP32 is a 3.3V part so there must already be a voltage regulator of some sort on the dev kit. Looking on the board and confirmed on the schematic, there is a AMS1117-3.3 LDO (low drop-out) regulator on duty. These regulators are happy to accept voltage up to 15V and down to as low as 1.3V over the output voltage, which in this case is 3.3 + 1.3 = 4.6V.

Looking over the schematic that HiLetgo bundled with this ESP32 dev kit, I see the onboard USB serial interface chip also runs on the 3.3V regulator output. Another thing this “Vin” pin is connected directly to is the power LED, which has a 1k current-limiting resistor so it can tolerate higher than 5V of input.

So that leaves the USB cable’s +5V line. If I have battery power voltage on that VIN pin, I don’t want that voltage to feed into my computer’s USB port. I need to make sure this ESP32 can connect to USB or battery power but never both at the same time. My solution is to use a length of solid-core wire to bridge battery power input to the Vin pin, and shaping the wire so it blocks the USB port. This way, I can’t connect this wire while the USB plug is in use.

In order to use USB power, I have to disconnect the VIN wire and swing it out of the way like a gate. In order to make sure that battery voltage wire doesn’t touch anything inconvenient while it is out of the way, I stabbed the exposed solid core wire into cardboard to tie up that literal loose end.

None of the remaining components on the rover testbed will need to receive software updates over USB, so this is the only place where I had to worry about switching between two power sources. Everything else will be wired directly to battery power.

Cardboard Box Rover Testbed Breadboard

Writing down ESP32 pin assignments in a spreadsheet is a good to plan things out ahead of time, but it isn’t a robot until wires are connected and circuits completed. I’ll test the plan on my cardboard box rover testbed. When I cut out the holes for all those motors and servos, I left a space open in the middle for circuitry. Since this is a testbed to prove out a plan, I want the flexibility to easily test things incrementally as I build things piece by piece. It would also be nice to easily fix problems I will undoubtedly discover during testing. Both of these desires pointed to a breadboard and jumper wire instead of a more permanent soldered solution.

In my collection of ESP32 development kits, there is a very important differentiation for this task: some of these modules are 0.1″ wider than the others. This difference is critically important for a breadboard prototype: the narrower modules leave one breadboard hole exposed on either side for jumper wiring, in contrast the wider module would completely block all holes on one side. To use wider modules on a breadboard, all the wires have to run underneath the module making them much less experimentation-friendly than their thinner counterparts. For this particular project I’m using an ESP32 dev module I purchased from this Amazon link (*) but there’s no guarantee the vendor wouldn’t change things up in the future.

One problem with the narrower module is that its compact layout left no space for labels on the visible side of the board. Rather than laboriously looking up charts and counting pins every time a wire connection is to be made, some clever people have designed paper templates to help with the task. I found one that matched my ESP32 dev kit at this link. Checking against my dev kit’s schematic, I see it is functionally correct though there is an inconsequential cosmetic typo of GIOP instead of GPIO. Printing out the PDF at 100% scale will match size with the real thing, which I then put between the breadboard and my ESP32 as I pushed the ESP32 dev kit in to the breadboard. Metal pins have no problem punching through that paper, and the paper is not conductive enough to cause problems with the circuit.

Having a pinout reference immediately available cuts down on frustration and mistakes, and I liked the idea so much I wanted them for my DRV8833 breakout boards as well. Because those breakout boards also had visible pin labels on their downward-facing side of the board. I didn’t have the skill to draw up a nice template using graphics design software, but using a sheet of paper I could create a hand-written reference.


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

Assigning Pins for Sawppy Rover ESP32

As part of exploring MCPWM duty cycles, I had to make decisions on ESP32 pin assignments. This is how my ESP32 DevKit will communicate with my DC motor driver and steering servos. Three DRV8833 motor driver IC breakout boards for Micro Sawppy rover’s six TT gear motors driving wheels, plus four corner steering servos. Together they require sixteen PWM pins which is within an ESP32’s capability.

I’m very thankful for this compilation of ESP32 pinout from Random Nerd Tutorials, which served as a starting point and immediately crossed off many off-limit pins like those tied to ESP32 flash memory access. I also eliminated the primary serial transmit & receive pins from consideration as I wanted to keep them available for serial monitoring.

The next pins I wanted to keep clear were the two hardware I2C pins. I want to be build a baseline ESP32-controlled rover with as few external support chips as possible. But if I can leave the I2C pins free, that leaves the door open for add-ons and expansions. Additional PWM pins can be added with something like the popular PCA9685 chip. (*) And additional digital input/output pins can be added via PCF8574 (*) or similar chips. In fact, if I get to a point where I desire specific ESP32 peripherals (capacitive touch?) I can offload all wheel driving and steering duties to an external PWM chip.

I wanted to leave hardware SPI pins open for the same reason, but SPI was a luxury I could not afford. That would mean leaving four more pins unused and that’s more than I can spare for my baseline design. If SPI becomes important, I’ll need to offload some wheel control to external PWM chips. Another luxury I had to leave behind are the JTAG debug pins, which also demanded four pins I could not spare unless I offload PWM to external components.

But even though I could use those JTAG pins for general output, some care had to be taken because there will be some spurious signals on those pins. Upon power-up, before my code can run to configure those pins for PWM output, these pins will have signals corresponding to JTAG or other system use. In practice I expect this to mean my rover will twitch a little bit at startup, so I assigned those pins to steering servo signal duty. I rather that my rover steering servo twitch on powerup instead of a drive wheel. I don’t want the rover to drive itself forward or back uncontrolled, no matter how briefly.

After all of the above concerns are factored in, the final one is the physical relationship of pins. I wanted to keep related pins close together, such as the A and B lines for motor control. This is a little tricky to do on the Random Nerd Tutorials chart, because it is sorted by GPIO number instead of their physical position. I used Excel to create a chart that maps the physical location of those pins. Then I assigned their use so they roughly correlate to their positions on the rover, with the DevKit USB port pointing towards back. In reality the wiring won’t be that straightforward because the motor control lines will have to go through a DRV8833 first, but it might help me during debugging.

The assignments are listed on the outer-most columns of the chart. The first letter is one of (F)ront, (M)id, or (B)ack. The second letter is (L)eft or (R)ight. The third letter is (A) and (B) for DRV8833 motor control, or (S) for steering servo. This particular set of assignments leaves the I2C SDA & SCL pins free. Unencumbered GPIO23 is left free and clear for anything. The four input-only pins 34, 35, 36, and 39 are still available. And as a last resort, we still have the restricted-use GPIO0 pin. With this plan for pin assignments in hand, I proceed to turn the plan into reality.


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

Interactive MCPWM Duty Cycle Explorer

I started exploring TT gearmotor response to different duty cycles by editing MCPWM parameters in source code, compile with those new parameters, and uploading the results to my ESP32 motor control test bench board. It took only three cycles of this process before it was painfully clear I needed a better way. So I copied an excerpt (the joystick and MCPWM portions) of my ESP32 Sawppy control software out to a separate test program in order to interactively explore TT gearbox behavior under different duty cycles.

This test program only dynamically varies the duty cycle, not the PWM frequency. I’m running my program at a PWM frequency of 20 kHz. There may be an annoying whine audible to dogs and newborns, but it’s comfortably above my not-spring-chicken range of hearing. A brief test established that these TT gear motors behave differently at lower PWM frequencies. The most consequential effect is that I could turn them at a lower minimum speed. Still not rock-climbing slow, but there’s definitely an effect. I don’t have enough electrical engineering background to understand why I have more torque with lower PWM frequency, so I’ll have to come back to this topic later to find an explanation for my observation. In the meantime I’m insistent on 20 kHz PWM because I don’t like to hear the whining.

In my test program I didn’t have a real need for analog control, so the joystick was effectively turned into a direction pad. Pushing one direction increments duty cycle, pushing the opposite decrements it. The orthogonal axis adjusts the increment rate, so I can adjust in duty cycle increments of 10%, 1%, and 0.1%. In order to test startup power, I could press down on the stick to trigger its associated button. This button toggles motor power on and off. This program is only useful when connected to serial monitor because the increment rate and the current duty cycle are displayed via text sent over serial link. I plan to use this tool again once Micro Sawppy is rolling on its own wheels, in order to update speed-to-duty cycle mapping to reflect realistic loads on the wheels rather than unloaded spinning in the air.

In theory it should be possible to have this tool as a part of Sawppy ESP32 control code instead of a separate project. I would have to set up some sort of conditional compilation mechanism so I could toggle whether to compile standard Sawppy control or this duty cycle explorer. However, I don’t see any particular motivation to perform this work today so until I see a benefit, I’ll leave that integration task on the to-do list for the future. With some working PWM duty cycles in hand I can start putting them to work with ESP32 GPIO pin assignments.


[ This test program is publicly available on GitHub. ]

Exploring TT Gear Motor Speed Range

I wrote my ESP32 Sawppy rover chassis Ackermann geometry code to output calculated wheel speeds and steering angles in an implementation-neutral (but not similar to ros_control) way. Wheel speeds were specified in meters per second of desired ground travel speed, so the next step is to translate that into DRV8833 MCPWM control signals driving TT gear motors.

This conversion will be some kind of mapping from desired wheel travel velocity to PWM duty cycle. Without closed-loop control, I knew the mapping would not be accurate, but maybe it’ll close enough to be acceptable at this price point. I’m not sure how much of a load will be borne by each rover wheel yet, so the first draft of this mapping will work with the wheels spinning freely in air without load. Since a single DRV8833 can drive two motors, I drove a pair of TT gearmotors with the same electrical PWM parameters. I was not surprised to find that they had slightly different speeds. It’s not even a consistent ratio: one motor was faster at full power, while the other was faster at low power. Looks like the error bars on my mapping are getting longer and longer with each discovery!

For the sake of getting some numbers as a starting point, I estimated unloaded wheel travel speed at 6V to be approximately 0.6 m/sec. With this, I’m cautiously optimistic that Micro Sawppy rovers running on TT gear motors will be able to keep up with Sawppy V1 with its much larger diameter wheels. However, they won’t have the same performance at the low end. Unloaded, these TT gearmotors could turn as low as 15cm/sec, but just barely. Any slower than that and the motor couldn’t overcome internal gearbox friction. Such behavior implies these little rovers wouldn’t be much good for low speed rock climbing. This initial experiment found that TT gearmotors maximum speed isn’t very fast, and their minimum speed isn’t very slow. But it’s still an open question whether they are “good enough” for the sake of making an affordable micro Sawppy rover. I already know I need to revisit this speed range exploration once the rover is running on its wheels, so I wrote a tool to make that process less painful.

Abandoning ros_control Analogy for Micro Sawppy

Every time I revisit the task of writing Sawppy rover control code, I’m optimistic that I’m one step closer to not having to rewrite from scratch again. This time around, I’m following conventions set by decade-long development of ROS (Robot Operating System) but writing in low-level C code that should run on anything from embedded microcontrollers on up. This approach adds a few challenges but I hope it’ll be more adaptable to other platforms (both software and hardware) in the future.

On the hardware front, many robot chassis that advertise ROS compatibility uses the velocity command (cmd_vel) topic as their interface layer to ROS autonomy logic nodes. Hardware-specific code listens to messages sent to that topic, and handle translating desired velocity into physical movement. I will follow that precedent but I also had the ambition to go one step further with some inspiration from ros_control. The key word is “had”, past tense.

As I understand it, ros_control original motivation was to interface with components that one would find on a robot arm, creating a generic interface for motors and actuators. This allows for generalized operation with ROS nodes like the MoveIt framework for motion planning, and it is also the interface layer for switching between real and virtual robots for the Ignition Gazebo simulator. And since it’s generic, it’s perfectly valid to try to apply those concept to motors and actuators for chassis locomotion.

I like the concept, but I got lost when wading into documentation. When I dug into one of the actual interfaces like JointPositionController, I saw only a setCommand() that sends a single double-precision floating point value. This is clearly only part of the picture. What is the context that number? For actuators like RC servo it would be a rotation, but for a linear actuator it would be a distance. How would I communicate that information, along with other context like whether that rotation/distance is along X, Y, or Z axis?

Furthermore, the interface assumes closed-loop control on every actuator, since the interface has getPosition() to query status and setGains() to adjust PID coefficients. I wouldn’t be able to offer any of that on a micro Sawppy rover. RC servos do perform closed-loop control, but the loop is closed within the servo and the robot has no visibility to actual position or adjust PID coefficients. And without an encoder wheel, TT gear motors have no closed loop control at all. Some ROS tutorials (like this one) asserted there’s no point to ros_control on low-end robots and I now understand their point.

Since I don’t understand concepts of ros_control yet, I’ve chosen to postpone that idea for ESP32 Micro Sawppy software. The worst downside is that I might go down a path that will require another rewrite in the future. But hey, I’ve done it before and I can do it again. To mitigate this risk, I’ll still communicate my rover actuator commands using unit conventions as described by REP103. So I’ll communicate steering angles using radians instead of RC servo commands, which should be friendlier to conversion to different actuators in the future. Similarly, wheel speed will be communicated in meters per second rather than motor power level, again in the hopes it’ll be generic enough for other actuators in the future. Today I’ll pack them into a single message for short term ease and deal with that problem later. I have a more immediate problem: I found the TT gearboxes have a narrower range of speed than I originally thought.

Revisiting Sawppy Geometry Jupyter Notebook

My decision to follow ROS conventions for my Micro Sawppy rover control software also meant taking on some of the challenges of adapting manual control conventions to an automation-centric world. I remain optimistic that this short term pain will prove worthwhile long term, but it’ll be some time before I know for sure.

I chose an ESP32 as my rover brain, thanks to its feature set being a good match for my ambition to design a low-cost entry-level rover. The cost-cutting decision to move hardware from Raspberry Pi to ESP32 has a big impact on the software environment. From Python running on a general purpose Linux-based operating system to C running on a bare-bones FreeRTOS environment optimized for embedded systems. While I’ve written a C version for Sawppy’s alternate Arduino control scheme, I couldn’t port my old code straight across due to my new ROS-centric focus.

This is far from the first attempt at a ROS-friendly Sawppy rover code base. I tried to do it once myself before aborting that effort due to unneeded duplication. I looked at Rhys Mainwaring’s rover software stack for ROS Melodic to see if I could adapt it to Micro Sawppy’s ESP32. Logic-wise, it follows all the ROS conventions I wanted to follow, but it also used all the ROS software frameworks I won’t have on an ESP32. I also wanted more abstraction between rover chassis math and actuator code. In ROS this is the job of ros_control which Rhys plans to adopt, but that is part of the ROS infrastructure I won’t have on bare ESP32 FreeRTOS.

So I went back to something I created as part of my aborted effort: a Jupyter notebook for working through my rover math. Jupyter has since evolved into JupyterLab but it didn’t seem to have any problem opening up my old notebook. Thanks to all the markdown documentation I had written alongside my Python code in the Jupyter notebook, I could quickly get back up to speed on my thinking on the project. Reviewing my code months later, I even found and fixed a bug that slipped through earlier! I’m not sure this is the most elegant fix, my Python code is not very “Pythonic” because I still think like a C programmer. It is technically a bug, but today it is a feature because I’m porting it to C that will compile for ESP32. My plan was to build a FreeRTOS task that takes a desired rover chassis movement command similar to a ROS cmd_vel message, and outputs data similar to a ros_control message… but then my plan changed.

Manual Control Square Peg in a ROS Round Hole

I have converted my test code reading a joystick via ESP32 ADC peripheral to generate ROS-like data messages as output. There were some hiccups along the way but it’s good enough to proceed. The next step in the pipeline is to interpret those joystick commands in a little Sawppy rover context and generate ROS-like robot chassis velocity command (cmd_vel) as output. And as I start tackling the math I realized I’m going to face a recurring theme. I have some specific concepts around manual control of a little Sawppy rover, but those concepts aren’t a good fit for ROS conventions like REP103.

The first concept is velocity. ROS command for linear velocity is specified in meters per second. There’s no good way to say “go as fast as you can go”. Specifying meters per second will never be accurate on an open-loop DC motor system like micro Sawppy for multiple reasons. The first and most obvious one is battery power: full speed will be faster on a fully charged battery. The next problem is robot geometry. When traveling in an arc, Sawppy’s top speed will be constrained by the top speed of the outer-most wheel. As the arc tightens, that outer-most wheel running as fast as it could would still constrain the rover to a lower top speed. So Sawppy’s top speed will vary based on other conditions in the system.

The second concept is rotation. ROS command for angular velocity is specified in radians per second. There’s no good way to say “pivot about the rover’s inner wheel” because the center of the turn is dictated by the combination of linear and angular velocity. Thus the center of the turn is a result of (instead of a part of) the command. In my experience I’ve found that people have a hard time working with Sawppy turning radius when the center of turn is inside the rover’s footprint. People have an easy time with turns that resemble the cars we see on the roads everyday. People also had no problem with Sawppy pirouetting around the center axis. But in between those realms, people get confused pretty quickly. When I created the wired controller for Sawppy, I divided up the control space into two regimes: One mode where Sawppy pivots in place, and another mode where Sawppy’s turning radius is constrained to be no tighter than pivoting on one of the middle wheels. Deliberately constraining Sawppy’s maneuverability to be a subset of its capabilities was a worthwhile tradeoff to reduce user confusion .

But the whole reason of ROS is autonomy, and autonomous robots have no problem dealing with all degrees of freedom in robot movement, so there’s no reason to block off a subset of capability. However, that also meant if I’m structuring the manual joystick control system to follow ROS conventions, I have no easy way to block off that subset for human friendliness. It is certainly possible to do so with lots of trigonometry, but it always makes my head hurt. ROS works in radians and I have yet to develop a good intuitive sense for thinking about angles in radians. All of my mental geometry have been working in degrees.

These are but two of the problems on the road ahead for Sawppy, in its first draft as a manual remote-controlled vehicle. I hold out hope that this up front pain will make Sawppy software work easier in the future as I adapt ROS nodes to give Sawppy autonomy. But it does mean making today’s manual control Sawppy a square peg trying to fit in a round hole, with lots of imprecision that will fall to “best effort” basis instead of rigidly complying with expectations of ROS. But I’ll stay with it to the best of my abilities, which means revisiting rover geometry math in this new context.

Joystick Range Check Works Around ESP32 ADC Mystery

One of the things I knew I wanted to do for my Micro Sawppy rover’s ESP32 brain was an option for wired analog joystick input. This proved useful for Sawppy V1 and I wanted it for Micro Sawppy as well. Not just as a backup control method, but as the first test in my hypothesis that I will benefit from following ROS precedents for generic messages. In addition to the evergreen ambition to give Sawppy autonomy, I want to support the following manual input control mechanisms:

  • Wired analog joystick for noisy wireless signal environments.
  • Web-based control similar to what I created for SGVHAK rover and adapted to Sawppy.
  • Bluetooth based control to connect with devices like the BBC micro:bit.
  • ROS2 joystick control message via micro-ROS.

If I have a generic message type resembling ROS joystick message, each of these input methods can theoretically be isolated in their own FreeRTOS tasks. They all post the same message type to the same message queue, so the rest of Micro Sawppy doesn’t have to care about where their input came from. Swapping input was something very difficult to do on SGVHAK rover software and I want to do improve this time around.

So as a starting point I wanted to take my quick hack of ADC joystick support in my FreeRTOS play project and rewrite it to be something suitably robust for Micro Sawppy. Since it was a quick hack, there were a few weird things that happened but I chose not to worry about it at the time. Thinking I’ll sit down and figure it out later. It is later and… I failed to figure it out. But I did devise a workaround so I can continue with the project. I’ll come back and update this paragraph if I figure it out later.

The issue center around ESP32’s ADC (analog-to-digital converter) peripheral. I had been familiar with ADC peripheral on a Arduino’s ATmega328, which can read values in a range from 0V to +5V via analogRead(). The ADC on a PIC16F18345 works in a similar manner. The ESP32 is a 3.3V chip so I had expected its ADC to read the range from 0V to +3.3V but I was wrong. By default it only reads from 0V to 0.8V. We can configure a signal attenuator to increase range of ADC sensitivity, but even at maximum attenuation it only claims to read from 0V to 2.6V.

This presents an issue with analog joystick inputs, which are electrically potentiometers that feed a voltage value somewhere between its input max voltage and ground. Wiring such a device up to the ESP32’s 3.3V supply means we’ll lose the ability to read the high end of the joystick corresponding to the range between ADC maximum of 2.6V and 3.3V. It also means the joystick’s center position will return about 1.65V which is higher than midway between 0V and 2.6V. So I had expected ADC readings to be higher than what I would expect.

The reality was just the opposite, they were lower instead. I configured the ADC for 9-bits resolution, so the values are anywhere from 0 to 511. Midway would be 256, but joystick center actually correlated to ~220. And even though I expect to hit maximum value partway through the high range of joystick motion, I never got there. Maximum value never exceeded ~460. I used a voltmeter to measure the input and confirmed +3.3V, but the reading wasn’t close to the actual maximum value of 511. Several rounds of fiddling with configuration flags did not change this result.

So as a workaround, my new joystick code does a range check upon powerup. It assumes the joystick is centered at powerup (hopefully reasonable assumption when they are spring loaded) and waits for me to move each axis through its minimum and maximum values and press the button. Before that first button press, my code tracks the highest and lowest values seen, which are used to normalize joystick message output to the range from -1 to +1 that is used in ROS joystick message. I’m using some very inexpensive joysticks whose potentiometers drift significantly, so maybe a range check is a good idea anyway. Either way it’s good enough for me to move on.

Goals and Challenges for Sawppy ESP32 Software

With a cardboard rover test platform ready to go, I’ve run out of excuses to put off the software portion of micro Sawppy rover work. If my little rover is going to come alive, the software work must be done. This task shouldn’t be as intimidating as it feels, because this is my second round through writing rover brain code. I have learned some lessons from writing SGVHAK rover code running on a Raspberry Pi (code which I then adapted to Sawppy) and those lessons should help me this time on the ESP32.

One goal for my new ESP32 project is to be more ROS-friendly. I’m not ready to dive straight into micro-ROS right now. But when I (or someone else) tackles the challenge, the project shouldn’t be tripped up by something that needlessly complicates the task. I wrote SGVHAK rover code before I knew much about ROS, and in hindsight I made some decisions that made a ROS port annoying for no good reason. For example, the ROS convention for robot forward is along the +X axis. Ignorant of this when I wrote SGVHAK rover software, I chose forward to be +Y axis. The ROS convention for angular measurements are radians for units, and the right-hand rule for positive rotation. Meaning a positive rover steering rotation is counter-clockwise. For SGVHAK rover, I worked with angles in degrees and positive rotation was clockwise. There was no reason to go against these ROS conventions, it was done purely out of ignorance. If I were to adapt my SGVHAK rover code to ROS, a whole bunch of conversions need to occur risking additional surface area for bugs. I completely understand why Rhys Mainwaring wrote a rover ROS software stack from scratch instead, I would have done the same!

So for my upcoming ESP32 Sawppy rover brain project, I’ll keep ROS conventions in mind. Specifically REP103 for units and coordinate conventions. Another ROS-inspired similarity will be messages, which is a new luxury gained by the change in platform. For SGVHAK rover I avoided the complications of introducing multiprocessing concepts to Python code running on a Raspberry Pi. But now I’m targeting the customized FreeRTOS Espressif created to run an ESP32, I gain a lot of multiprocessing tools as a natural and fundamental part of the platform. I will be organizing my code components into FreeRTOS tasks, which has similarities to how ROS organizes code components into nodes. So when my tasks communicate with each other, I’ll look to see if there is a ROS equivalent. I won’t be able to make my FreeRTOS messages compatible with ROS message formats, though. Because I won’t have some of the luxuries like dynamically sized arrays. But the data organization should at least look similar.

I foresee the following items, and I’ll probably find more as I go:

  • I will rewrite my ESP32 ADC joystick code to communicate with a new data message. It should resemble sensor_msgs/Joy from ROS, normalized to the same value ranges.
  • When I write the task which translates raw input into desired rover chassis command, that result will be communicated with something that resembles geometry_msgs/Twist used for ROS topic cmd_vel (Commanded Velocity).
  • When that cmd_vel command is broken down to commands for individual motors and actuators, those individual commands should resemble joint commands of ros_control. I have not yet worked with ros_control myself so this one is the fuzziest with the most unknowns. But I look forward to learning!

And as expected of a learning project, I ran into problems immediately with the first item on the list. I eventually decided to devise a workaround for ESP32 ADC behavior I don’t understand yet.

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.

Test Driving DRV8833 With ESP32 MCPWM

It was time well spent to study my batch of commodity breakout boards for the DRV8833 DC motor driver IC. It reinforced that I should not take random instructions downloaded online at face value, even though in this case the errors wouldn’t have been relevant to my planned usage. Armed with confidence I understand how to use the board I have on hand, I proceed to the next step: verify I could write code to control one with an ESP32 and its MCPWM peripheral.

My self-education FreeRTOS project was created with this future in mind when I started by controlling a L298 DC motor driver IC. The first exercise used the control scheme utilizing three pins per motor (two digital for state, one PWM pin for magnitude) which is compatible with the TB6612 but not DRV8833. The beauty of FreeRTOS was that I was able to isolate code specific to this control scheme in its own FreeRTOS task. In theory, all I would need to do is to write another task with DRV8833’s control scheme (a pair of PWM pins per motor) and swap out the motor driver control task. The remainder of my test program, from the joystick ADC to the heartbeat status LED, would remain untouched and blissfully unaware I’ve switched my motor control task.

I’m happy to report theory matched practice this time! The problem I encountered was unrelated to FreeRTOS. It was really easy to get one motor up and running but I was tripped up by my misinterpretation of Espressif documentation when trying to run two motors simultaneously at different speeds. Each MCPWM unit on a ESP32 can control three motors, and each MCPWM unit had three timers. The quote from Espressif documentation that I misunderstood was:

Each A/B pair may be clocked by any one of the three timers Timer 0, 1 and 2. The same timer may be used to clock more than one pair of PWM outputs.

I tried to run two pairs of PWM outputs (one pair per motor) with the same timer, which is explicitly allowed by the documentation and generated no compiler or runtime errors. However, the fact that it is possible and allowed doesn’t mean it actually does what I want. By using the same timer, I had also locked those motors to the same speed. Different speeds require separate timers. Which is why MCPWM offers up to three timers so we can run each motor at a different speed. Once I realized my mistake and understood what was going on, it was an easy fix to get both motors up and running each with their own timer. With both motors running on my existing cardboard testbed, I thought it was time to upgrade to a fancier (but still cardboard) testbed.


This coding practice project is publicly available on GitHub.

Notes on Commodity DRV8833 Breakout Board

Having read through the datasheet for DRV8833 DC motor driver IC, I was optimistic that they would be a good choice to control DC motors on the TT gearmotors I have installed on Micro Sawppy Beta 3 (MSB3) rover. DRV8833 operating voltage range of up to 10V is a much better fit for these 3-6V motors. Compared to the classic L298N motor controller with its 4 to 45V range. The lower voltage handling requirements, as well as being a much newer design using modern power management techniques, means a DRV8833 breakout board is far more compact than a L298N breakout board. Something clearly visible in this side-by-side picture. Physical volume is an important consideration when fitting electronics inside a little rover.

Side by side size comparison of L298N and DRV8833 motor control IC breakout boards.

For my first round of experiments, I bought a batch of 5 DRV8833 breakout boards from the lowest bidder of the day on Amazon (*) I’m sure a different day will have a different lowest vendor when we issue a query for DRV8833(*), because these breakout boards seem to be commodities offered by many different vendors. We also see this particular design from many vendors on AliExpress. I noticed two or three very popular designs for a DRV8833 breakout board. I have no idea where this particular design came from. If the same factory is supplying all of these vendors, or if the design has been cloned by multiple manufacturers. Whatever the history, I see enough quantity to give me confidence these boards won’t disappear overnight. We’ll see if I’m right!

Incorrect instructions shown on some DRV8833 product listings.

In this particular product listing, one of the pictures serve as a rudimentary reference manual for the board. I was suspicious of these instructions so I probed this board to determine the circuit for myself as I did for the L298N board. I’m glad I did! The instructions had swapped the “FAULT” and “SLEEP” pins for reasons unknown. Fortunately, those pins are optional so most users (including my intended use) won’t be affected.

There are only a few supporting components on this board. From the DRV8833 datasheet I expected three capacitors and they are clearly visible. I also see two resistors and a LED. The LED was not on the datasheet, it was a bonus feature to indicate power supply is present, along with its 4.7kOhm current-limiting resistor. The final resistor is a 47kOhm pull-up resistor for the SLEEP pin, by default pulling it high to enable the board and giving us the option to leave the breakout board’s (SL)EEP pin unconnected.

Back side view of a DRV8833 breakout board, showing the J1 trace that can be cut to disconnect pull-up resistor and allow control over sleep functionality.

For applications that want to assert control over sleep/enable themselves, there is a provision on the back side of this breakout board. Cutting the trace on J1 will disconnect SLEEP from the pull-up resistor, opening up the pin to external control. If we should change our minds afterwards, we can solder across J1 pads to reconnect the pull-up resistor.

No such provisions exist for current chopping control. DRV8833 offers the option to limit maximum current by putting current-sensing resistors on the AISEN and BISEN pins, but this particular breakout board design connected those pins directly to ground without any provisions to add current-sensing resistors back in. Applications that want current chopping will have to go elsewhere.

Remainder of the board was fairly straightforward, once we figure out the pin rename mapping. This board labelled its pins IN1-4 and OUT1-4 following precedent of L298N, instead of the names in the DRV8833 datasheet of pins 1 and 2 for channels A and B. For those that prefer this information in schematic form, here’s what I drew up after my probing session for this board to guide my first experiment putting one to use:

Schematic diagram for a popular type of DRV8833 breakout board.

Sawppy Rover Dances Like Real Rovers

Whenever I build something physical from my imagination, the reality always served a few surprises I failed to anticipate in my mind. Two recurring themes are seeing real joints flexing beyond their primary rotation axis, and realizing physical objects aren’t as perfectly rigid as they are in CAD. Nothing exemplifies this more than the rocker-bogie suspension of my Sawppy rovers. Their movement are well-defined when I articulate them in CAD, but once printed and assembled, I saw movement that weren’t in my CAD model. When rolling over obstacles, Sawppy would wobble and bounce in response to mechanical shocks that weren’t absorbed by its curved wheel spokes. A few other Sawppy rovers builders have asked me to check if this was supposed to happen on their rovers. I answered that it was not an intentional design feature, but they have done nothing wrong as I see it on my rover as well. I joked that our rovers are just dancing.

Part of this comes from Sawppy’s low-cost construction. The aluminum extrusion beams are not as rigid as the carbon composite tubes of real Mars rovers, and the 3D-printed connectors for those beams are not as rigid as CNC-machined metal components. The commodity 608 bearings I used for Sawppy’s joints give me smooth movement and load bearing capability, but they also add some mechanical slop to the system.

But part of this came from the suspension geometry itself, which is unlike suspension systems of cars we drive here on planet earth. Due to far higher speeds involved, our car suspensions are robust and bolted to car chassis at multiple points for added rigidity. In contrast, Mars rovers experience road impacts at a far slower rate, reducing the need for a heavily braced system. Such bracing are undesirably heavy on their strict weight management regimen. So rover suspension components are rather spindly and are attached at only one (or in rare cases, two) points. With so few attachment points, and a multi-segmented construction that puts large subassemblies at the end of several joints, any component movement and flex is compounded.

I had been curious how this tradeoff manifested on real Mars-bound rovers. They have sturdier components, but Sawppy copied their geometry and share the associated challenges. I kept my eyes open on footage of Perseverance rover while it was being tested to see if I see any wobble or bounce, but those tests are slow-moving affairs that imposed no major mechanical shocks to propagate through the system. Since I don’t expect anyone to swing a sledgehammer at the rover, I had resigned to never knowing.

But then I was happily surprised when I watched video footage of Perseverance landing sequence, specifically the part where the descent stage unspooled its tethers to lower the rover. (Thanks to Emily Velasco for turning it into an animated GIF I can embed here.)

Perseverance rover descends during skycrane maneuver

During this sequence, Perseverance suspension was released from its compact travel configuration and unfolded to its driving configuration in preparation for landing. This drop-and-lock action imposed mechanical shock on rover suspension elements, and we can see everything wobbling and bouncing just as I see frequently on my own little rover. It was both enlightening and entertaining to know that real Martian rovers can dance, too! They just choose not to, most of the time.

UPDATE: NASA JPL has released sounds recorded by Perseverance on-board microphone as it started driving across the Martian landscape. In that sound clip, we can hear rover suspension components flex and squeak in response to driving over surface features. Not too different from what I hear from my own Sawppy rover.


[Title image by NASA/JPL-Caltech]

Window Shopping DRV8833 DC Motor Control IC

It was a pure accident that I stumbled across the DRV8833 DC motor control IC. After a quick comparison against my original candidate TB6612 I think some DRV8833 modules might actually the better choice for my micro Sawppy rover project. Its required control signals are an ideal fit for the MCPWM peripheral on the ESP32 I planned as my rover brain. Though note not all models of the ESP32 line has MCPWM peripherals, for example it appears to be absent from the ESP32-S2.

The DRV8833 is less capable than the TB6612 in some ways. For example, the maximum voltage is listed as 10.8V which is lower than the 15V listed for TB6612, and far short of the 45V listed for a L298. But TT gearmotors are typically listed with a maximum voltage of 6V, so I should be fine. I was surprised that the amperage rating isn’t much lower, with 1.5A typical and 2A peak that should suffice for TT gearmotors. And if I need additional current carrying capacity, the DRV8833 is explicitly stated to be capable of both output stages working in parallel to double the maximum current. The L298 datasheet also explicitly listed parallel operation as an option, but the TB6612 did not.

Like the L298, the DRV8833 has provisions for current-sensing resistors between AISEN and BISEN pins to ground. But unlike the L298, the DRV8833 will actually read their voltage to limit maximum current output. The current-sensing resistors are a whole world into themselves. They work best when placed close to the IC because that minimizes variation introduced by PCB traces. But if they are close, they will be in close proximity to heat generated by the IC, which will change their resistance. Quite a few variables need to be juggled for it to work right, so I’ll probably choose to opt out of current limiting and connect those pins to ground. Fortunately the chip’s own overcurrent protection circuit works independently and will activate with or without external current-sensing resistors.

All four control pins, two for each stage, have internal pull-down resistors. Thus this chip is always in a defined state and we don’t have to worry about any particular startup sequence. Whether power arrives first or control signals arrive first, the chip will work in a known way. There are two more input pins, one to control sleep and another to signify fault. The fault signal is open-drain which would make it compatible with a lot of different circuits, but I might not have ESP32 input pins to spare for detecting fault conditions. I won’t worry about low-power sleep (at least not yet) for micro Sawppy, and in that case the recommended procedure is to pull it up with a 25-75kOhm resistor.

In addition to that optional resistor, there are three required capacitors, but no external diodes are required. Looks like the diodes to handle back-EMF from inductive loads are built in which is great news. It makes for a pretty short list of external support components, but I still don’t plan to use the chip directly. The first reason is that I have many options for breakout boards. From high quality Adafruit #3297 to the lowest bidder of the day on Amazon.(*) For low quantities it’s worth a few extra bucks to pay for an already-assembled breakout board.

The second reason is that I can’t meet proper installation requirements for the more capable DRV8833 variants. As is typical, the DRV8833 is available in several chip package formats. I was surprised to see that one of them had a much lower rating for typical amperage, a third of the others. However, peak rating stayed the same, so I suspected it’s not a limitation of the chip itself. Further reading (section 10.3.1) confirmed that maximum current of a DRV8833 is a direct function of heat dissipation and the lower-rated chip package lacked a heat conduction pad present in the others. (TI calls it PowerPAD.) Thus soldering a DRV8833 correctly requires reflow soldering. I would have to pay someone else to handle it, or buy my own reflow setup, but that’s a concern for the future. Right now I can start with some cheap breakout boards.


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

TB6612 Vs. DRV8833 DC Motor Driver ICs for ESP32 Micro Sawppy

While researching TB6612 DC motor driver IC breakout boards on Amazon, my results list actually had more breakout boards built around the DRV8833 (and claiming TB6612 compatibility) than actual TB6612 boards. So I tried performing an Amazon query for DRV8833(*) and saw I had far more options in that category. This may change in the future as worldwide silicon supply & demand varies, but that’s the situation as I type this. I didn’t explicitly set out to find yet another candidate to replace my L298 motor driver, but since I stumbled across it, I decided to spend a bit of time to take a closer look at the DRV8833 by Texas Instruments.

First things first: the claim of TB6612 control logic compatibility is wrong. Well, technically they are compatible for applications that are only interested in powering their motors only in full forward or full reverse, but that is not realistic. Such applications would not bother with a motor control IC and would directly use some MOSFETs or even relays instead. For real motor control applications, I’ve seen two different methods to interface with the classic L298 motor control IC. TB6612 is logic compatible with one method, DRV8833 is compatible with the other method, and they are not compatible with each other.

TB6612 requires three pins: two digital pins to control behavior (forward, backward, brake, or coast) and a PWM pin to control magnitude of that behavior. DRV8833 only accepts two pins to control behavior and modulation is done by rapidly pulsing one of those pins to switch between states. Partial throttle forward, for example, is done by rapidly switching between forward and coast states. DRV8833 does not have a dedicated PWM pin like the TB6612, and the closest counterpart to a L298’s ENABLE pin is the nSLEEP pin on a DRV8833 but that pin is unsuitable for modulating velocity. The first problem is that there’s only a single nSLEEP pin for both motors, and secondly waking up from sleep requires ~1ms making smooth motion difficult if not impossible.

In general, using two pins instead of three is an advantage when we are constrained by the number of pins available, and the ESP32 certainly has that problem. However, the tradeoff is that DRV8833 requires two pins capable of generating PWM signals per motor, whereas TB6612 only requires one. This would be a concern for microcontrollers with limited PWM peripherals, but the ESP32 literally has more PWM peripheral outputs than it has usable pins.

Looking specifically at my micro Sawppy rover application, the picture of pin allocation is not quite that straightforward as (2 pins * 6 wheels = 12 pins) versus (3 pins * 6 wheels = 18 pins). In typical operation, all the wheels on one side of the rover will be traveling in the same direction, so it is possible to share the direction control pins across three wheels on the same side of the rover, cutting it down to 10 pins instead of 18. Plus if I make the rover front-back symmetric I have an additional option to share the PWM control signal across front and rear wheels, which cuts pin count down to 8. But while DRV8833 can’t share pins across wheels on the same side, it can also benefit from front-back symmetry cutting its requirements down to 8 pins as well. A tie!

Clearly there are many tradeoffs I can make with motor driver arrangement and control, depending on how many PWM peripherals are on a particular microcontroller and how many pins it has to spare. For my first iteration I like the idea of having independent control over each wheel, even though right now I’m not sure how it would be useful. Once I get that working (or learn why I can’t) I’ll look into trading off independent control for reduced pin count. So the current plan of record is to use two PWM pins for each of six wheels, driving DRV8833 DC motor control ICs.


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

Window Shopping TB6612 DC Motor Driver IC

The cardboard backing for my latest experiment was never going to be the final arrangement, and neither are the L298 motor driver mounted using twist ties. I started experimenting with them because they were the classic, a known quantity, and widely available. But I would have expected technology to move on, and I found confirmation in this Hackaday article talking about the TB6612 motor driver IC as a replacement for those venerable L298.

I pulled up the data sheet published by manufacturer Toshiba because I wanted to learn where its specifications differed from the L298. As the article stated, this chip is not a direct drop-in replacement. In some respects this is good, for example the diodes to absorb back-EMF from inductive loads. The L298 required external support diodes, but the TB6612 has them built in, reducing parts count in our projects. In other respects the differences were limiting, such as a voltage range that only went up to 13.5V maximum which is far lower than the L298’s 45V. But since I’m looking to drive TT gearmotors which have a recommended voltage range of 3-6V, this limitation is not a problem here. And the smaller size of TB6612 would be quite welcome in a micro rover.

Examining the control signals, I see TB6612 allows us to specify motor direction using IN1 and IN2 pins. To control velocity, we send PWM signal to a pin explicitly named PWM. For applications that control a L298 using its IN1 and IN2 pins to control direction and control velocity by PWM controlling the enable (EN) pin, the TB6612 would be a direct logical replacement. However, my L298 breakout board tied EN to high by default implying speed control by PWM pulsing IN1 and IN2. I guess this is also valid for L298 but such a control scheme would not be compatible with TB6612.

Looking around, I can see the TB6612 used in a few other maker-friendly products including Adafruit product #1438 which is an Arduino motor shield built around this motor control chip. SparkFun #14451 offers it in a more compact breakout board instead of the Arduino shield form factor, Adafruit #2448 is another similar option. I haven’t built up my own equipment and skill to work with surface mount components directly, so I will need such breakout boards or pay someone else to assemble a board with it.

Examining my options on Amazon (*) I was surprised at how slim my selections were. Perhaps this is a temporary thing due to the current worldwide semiconductor shortage? Whatever the reason, the majority of my search results today were actually breakout boards for a different chip, the DRV8833, while claiming TB6612 compatibility. Since I’m in the research stage, I might as well take a look at that chip, too.


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