Window Shopping: Cutra Wondercutter Ultrasonic Knife

During an online video meetup with some makers, I learned that consumer-level ultrasonic knives exist. One member of the meetup was taking theirs apart for some reason I’ve now forgotten, I just remembered his quick demo of the handheld cutting blade cutting through a 3mm thick sheet of acrylic. It wasn’t exactly “hot knife through butter” (maybe cold knife through refrigerated butter) but certainly far superior to what I could do with my X-Acto #11 blade.

I had known of ultrasonic tools in the medical field, specifically dental tools. I also had some idea they existed in the realm of industrial manufacturing equipment. But something I could conceivably buy for my own workbench? That’s news to me. Unfortunately, the person on the video wasn’t able to give me much information to go on, so I started searching for “ultrasonic knife” from my usual list of tool vendors. Unsurprisingly, I got a hit at McMaster-Carr: Item #3415N11 Fast-Cutting Ultrasonic Precision Knife. Visually, this looks like the same device I saw being disassembled at the meetup. But McMaster-Carr didn’t give me very much information on this device, not even some things I consider basic like make and model for further evaluation.

A search for “Ultrasonic Knife” on Amazon would give me several multi-thousand-dollar industrial machines, and also this listing. (*) Titled “The Wondercutter S” it looks right, but this listing felt odd for several reasons. The brand is listed as “MICRO-MAKE” but there’s nothing else by that brand name. There is also a logo on the device absent from the McMaster-Carr listing. It is stylized so I couldn’t quite decipher it to letters, but it is definitely neither “Wondercutter” or “MICRO-MAKE”. This listing didn’t give me the confidence I needed to commit several hundred dollars, despite Amazon Prime guarantees.

Continuing online search, I also got a hit at Home Depot which was a mild surprise. I had not associated the big orange DIY home improvement store with high tech tools. From this listing I got a brand name “CUTRA” which explains the stylized logo I couldn’t read earlier.

Now that I have a brand name, I found its company site and their own product site. It appears to be a Korean company and I finally got the specifications I could sink my teeth into. There were also a lot of demonstrations videos on what this device could do, the one that got my attention was cleaning up supports for 3D printing. I’ve never enjoyed cleaning up supports, and I’ve had a few dangerous close calls with my trusty X-Acto blade doing so. A couple of hundred dollars is a significant investment, but if it saves me a single hospital visit that would make the item worthwhile.

From this site I also learned that Wondercutter was crowdfunded as an Indiegogo project back in 2017. Well, I definitely missed the early bird backer special of $258 USD! I just have to pay retail now. Elsewhere on the site I saw I could order direct from Korea, but they have signed an official distributor for United States: Micro-Mark. Now this is a name I know from my scale plastic model days! I used to be a very good Micro-Mark customer buying Tamiya paints (they’ve all since dried out) and small model-building hand tools (I still use some of them).

Well, at least this explains the mystery branding of “Micro-Make” on that Amazon listing, it was a typo of Micro-Mark. There is actually a Micro-Mark storefront on Amazon (*), but with only a subset of the full catalog. For example, they sell replacement Wondercutter blades (*) but they don’t sell the Wondercutter itself on Amazon. Why would they leave it open for an imposter vendor to take away potential Amazon sales? That’s a curious business decision. Micro-Mark claims to be the exclusive distributor for North America, and I can see they are listed as vendors on sites like Walmart. But I’m not sure what’s the point of going through Walmart (or Home Depot or Amazon) if Micro-Mark is actually the distributor. It seems to make more sense to order one direct from Micro-Mark’s own website.


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

Window Shopping LovyanGFX

One part of having an open-source project is that anyone can offer their contribution for others to use in the future. Most of them were help that I was grateful to accept, such as people filling gaps in my Sawppy documentation. But occasionally, a proposed contribution unexpectedly pops out of left field and I needed to do some homework before I could even understand what’s going on. This was the case for pull request #30 on my ESP_8_BIT_composite Arduino library for generating color composite video signals from an ESP32. The author “riraosan” says it merged LovyanGFX and my library, to which I thought “Uh… what’s that?”

A web search found https://github.com/lovyan03/LovyanGFX which is a graphics library for embedded controllers, including ESP32. But also many others that ESP_8_BIT_composite does not support. While the API mimics AdafruitGFX, this library adds features like sprite support and palette manipulation. It looks like a pretty nifty library! Based on the README of that repository, the author’s primary language is Japanese and they are a big fan of M5Stack modules. So in addition to the software technical merits, LovyanGFX has extra appeal to native Japanese speakers who are playing with M5Stack modules. Roughly two dozen display modules were listed, but I don’t think I have any of them on hand to play with LovyanGFX myself.

Given this information and riraosan’s Instagram post, I guess the goal was to add ESP_8_BIT composite video signal generation as another supported output display for LovyanGFX. So I started digging into how the library was architected to enable support for different displays. I found that each supported display unit has corresponding files in the src/lgfx/v1/panel subdirectory. Each of which has a class that derives from the Panel_Device base class, which implements the IPanel interface. So if we want to add a composite video output capability to this library, that’s the code I expected to see. With this newfound knowledge, I returned to my pull request to see how it was handled. I saw nothing of what I expected. No IPanel implementation, no Panel_Device derived class. That work is in the contributor’s fork of LovyanGFX. The pull request for me has merely the minimal changes needed to ESP_8_BIT_composite to be used in that fork.

Since those changes are for a specialized usage independent of the main intention of my library, I’m not inclined to incorporate such changes. I suggested to riraosan that they fork the code and create a new LovyanGFX-focused library (removing AdafruitGFX support components) and it appears that will be the direction going forward. Whatever else happens, I now know about LovyanGFX and that knowledge would not have happened without a helpful contributor. I am thankful for that!

Window Shopping Roku IDK (Independent Developer Kit)

I’ve been given a pair of Roku streaming devices that were retired from a friend’s household, as they knew I like to take things apart to look inside. Before I do that, though, I briefly investigated what might be fun to do with intact and functional Roku devices. I was quite pleasantly surprised to learn that Roku has recently (announcement dated October 26th, 2021) released an Independent Developer Kit (IDK) for hobbyists to play with Roku hardware. This is different from their official Software Development Kit (SDK), which is available to companies like Netflix to create their Roku apps (“channels”). Many other differences between the IDK and SDK are explained in their IDK FAQ.

The Roku SDK requires a business partnership with Roku, but the IDK is available to anyone who is willing to work at low level in C++ and has a Linux development machine available to the task. No direct support for Windows or MacOS, but as the resulting binary is uploaded through a web interface, theoretically a Linux virtual machine could be used to run these tools. The list of example apps hint at what is accessible through the IDK: the OpenGL ES API, interface to the Roku remote control, interface for audio playback, and interface for video playback. (Including Wildvine DRM-protected content.) And it sounds like an IDK app has pretty complete control of the machine, as only one IDK can be installed at any given time. If it takes over the Roku shell, that implies control over the entire system even greater than possible with SDK-developed Roku channels.

But I couldn’t test that hypothesis due to the final requirement: a Roku device with IDK support. A chart listing all Roku hardware has a row for “IDK Support” and the old devices I’ve been gifted are both shown as “No”. If I really want to play with the Roku IDK, I’d have to go out and buy my own Roku device with a “Yes” listed on that chart. At the moment I don’t see the advantage of buying Roku hardware for this purpose. On the surface Roku IDK appears less compelling than developer support available on Google Chromecast or Amazon Fire TV devices. Or for ultimate openness, we can go with a Raspberry Pi. Maybe I’ll find a reason for Roku projects in the future, in the meantime these two old devices without IDK support will be disassembled. Starting with the smaller streaming stick.

Window Shopping Home Assistant

I learned about Home Assistant in a roundabout way, but once I started looking at it, I saw an interesting new tool I want to add to my toolbox. It started off on my good side with description on the project’s home page: “Open source home automation that puts local control and privacy first.” I like everything about that sentence and the tone it sets for the project.

I was once very interested in the promises of having a “smart home” and I was one of the early adopters of a Nest thermostat. (Before they were acquired by Google.) However, several years of Nest thermostat ownership also soured me on the concept of home automation via cloud services. Every once in a while, a server I never knew existed goes down and I get an error message on my Nest. To Nest’s credit, when their backend goes offline the thermostat continues running the last program it remembers. So it would never be worse than a “dumb” thermostat. Unfortunately not all “smart home” devices has such a graceful failure mode. For example whenever AWS us-east-1 suffers an outage, I would read about people not being able to get into their house because their Alexa-enabled smart lock wouldn’t unlock. If my smart home fails, I want it to be my own fault.

With an aversion to this class of failure, I have not bought any more Nest devices and became cool to the whole smart home concept. But maybe that will change if I could have local control and execution, and that is something Home Assistant offers. This also means any data is stored on my home server instead on somebody else’s AWS/Azure/GCP instance. It is popular for people to run on a Raspberry Pi dedicated to the purpose, but I could also run it in a Docker container on my home server as I’ve been doing for many other software pieces in this project.

While I intend to start playing with Home Assistant with DIY nodes built from ESP8266/ESP32, it offers integration with many home automation systems beyond those running ESPHome. It can even integrate with Google Nest, Amazon Alexa, and the like. But there’s a catch: to integrate with cloud-based services I would then have to either (1) open my instance of Home Assistant to the internet, or (2) use Nabu Casa’s cloud-hosted Home Assistant service.

In the near term that would not be a problem because I’m going to leave my Nest as-is. Until I’m more comfortable with the system, I’m not going to let Home Assistant control anything with drastic failure modes like locking me out of my house. I’m going to start simple and keep stakes low.

Learned About Home Assistant From ESPHome Via WLED

I thought Adafruit’s IO platform was a great service for building network-connected devices. If my current project had been something I wanted to be internet-accessible with responses built on immediate data, then that would be a great choice. However, my current intent is for something locally at home and I wanted the option to query and analyze long term data, so I started looking at Home Assistant instead.

I found out about Home Assistant in a roundabout way. The path started with a tweet from GeekMomProjects:

A cursory look at WLED’s home page told me it is a project superficially similar to Ben Hencke’s Pixelblaze: an ESP8266/ESP32-based platform for building network-connected projects that light up individually addressable LED arrays. The main difference I saw was of network control. A Pixelblaze is well suited for standalone execution, and the network interface is primarily to expose its web-based UI for programming effects. There are ways to control a Pixelblaze over the network, but they are more advanced scenarios. In contrast, WLED’s own interface for standalone effects are dominated by less sophisticated lighting schemes. For anything more sophisticated, WLED has an API for control over the network from other devices.

The Pixelblaze sensor board is a good illustration of this difference: it is consistent with Pixelblaze design to run code that reacts to its environment with the aid of a sensor board. There’s no sensor board peripheral for a WLED: if I want to build a sensor-reactive LED project using WLED, I would build something else with a sensor, and send commands over the network to control WLED lights.

So what would these other network nodes look like? Following some links led me to the ESPHome project. This is a platform for building small network-connected devices using ESP8266/ESP32 as its network gateway, with a library full of templates we can pick up and use. It looks like WLED is an advanced and specialized relative of ESPHome nodes like their adaptation of the FastLED library. I didn’t dig deeper to find exactly how closely related they are. What’s more interesting to me right now is that a lot of other popular electronics devices are available in the ESPHome template library, including the INA219 power monitor I’ve got on my workbench. All ready to go, no coding on my part required.

Using an inexpensive ESP as a small sensor input or output node, and offload processing logic somewhere else? This can work really well for my project depending on that “somewhere else.” If we’re talking about some cloud service, then we’re no better off than Adafruit IO. So I was happy to learn ESPHome is tailored to work with Home Assistant, an automation platform I could run locally.

Window Shopping: Adafruit.IO

I have an ESP8266 I wanted to use to with an INA219 chip as the voltage and current monitor for my toy solar panel array. The logged data can be visualized for curiosity, or maybe analyzed and that information fed into something in the future. I started with Arduino IDE, then moved to ESP-IDF on an ESP32, and most recently I played with MicroPython. This was a fun trip exploring the foundational elements, but looking towards the future I see a lot of software work to build this into a system and my interest started to fade.

What if somebody else has already built the infrastructure for something like this? Well, since I was on Adafruit’s INA219 page I saw that they had built one called Adafruit IO. Right up on the landing page it says: “We do the hard work so you can focus on the fun stuff.” Hey, I like the sound of that!

And in typical Adafruit fashion, they have great support for the product interoperating with a wide range of hardware. Including the ESP8266 and INA219! (Though via the Arduino platform and not their CircuitPython platform as they’ve dropped support for ESP8266 CircuitPython.) Data is logged, stored, easy dashboards for visualization, and that data feeds into programmable triggers to take action in response to date. Everything I foresaw having to build but is already here and ready to go. And the price is reasonable: free to start with limited functionality, and $10/mo to upgrade for full functionality.

This looks amazing but I decided against it, because I wanted something purely for consumption at home. I wouldn’t call myself averse to internet applications. After all, I’ve put all my code on GitHub and my project notebook is publicly readable. (You’re reading it right now.) Running some things on the internet makes sense when the intent is for access from anywhere, but for my home projects I don’t want that data to leave the house.

Also, Adafruit IO only retains data for a limited time period. From what I can see this was 30 days during the beta and the duration is something they reserve the right to change. I can’t seem to find their current data retention policy but it really doesn’t matter. Their target usage scenario is for “right now” interaction and projects like long-term historical tracking and analysis is out of scope. I want the option to store that data for longer, and to do it at home, so I passed on Adafruit IO and started looking for another solution.

Investigating TI TPS61187 WLED Driver

I took apart a LG LCD panel LP133WF2(SP)(A1) hoping to salvage something useful. After I failed to salvage the polarizer film, my hope lies with the backlight module. Its diffuser had a multi-layer construction I didn’t understand but found fascinating and wanted to see it light up firsthand. And if I am to do that, I need to figure out how to send power to the backlight LEDs. When I split the panel into the display and backlight modules, I saw the backlight was connected by a ribbon cable with seven conductors. Six of them look identical, and the seventh was wider than the rest, making it a good candidate for either a common anode or a cathode. Which is it, though? For that I looked for hints on the display panel’s integrated driver board.

There were three significant-looking ICs on board. The largest is closest to the connector to the rest of the laptop and the top two lines written on it were “LG Display ANX2804”. I found no information on this chip online. In the middle of the circuit board is another IC, this one labeled “SM4037 DA1422 AMER038”. I found no information on this particular designation, either. (There exists a SM4037 from Fairview Microwave, but it is a connector and not a microchip.) That leaves the chip closest to the backlight connector as the best candidate for a LED driver, and luckily its markings of TPS 61187 match that of a Texas Instruments WLED driver. I think this is it.

Reading its publicly available datasheet reinforced it is the right result, as its “typical application” diagram shows the chip driving six parallel strings of LEDs. The schematic indicates the six strings are connected to a common anode with their own individual cathodes wired to one of six current sinks on the chip. This information is enough for me to wire up this array to my bench power supply to find the right voltage for this string and create my own LED driver circuit. But since I have the datasheet already on hand and a “I know it used to work” backlight control board, I kept reading to see if I could perhaps reuse the board as well.

It looks pretty promising. There are no handshake or control protocol involved, all the potential configurations for this chip are done via resistance values to certain pins which would be already present in this case. I think for a bare minimum setup I only need to provide a power source and a PWM signal to control brightness. I could also connect the enable pin but I think I could get away with using a pull-up resistor. And under this minimalist plan I would be ignoring the fault signals. Plus one very important lesson about its power supply I had to learn first.

Window Shopping: LVGL

I have the color composite video generation code of ESP_8_BIT repackaged into an Arduino display library, but right now the only interface is a pointer to raw frame buffer memory and that’s not going to cut it on developer-friendliness grounds. At the minimum I want to match the existing Arduino TVout library precedent, and I think Adafruit’s GFX Library is my best call, but I wanted to look around at a few other options before I commit.

I took a quick look at FabGL and decided it would not serve for my purpose, because it seemed to lack the provision for using an external output device like my code. The next candidate is LVGL, the self-proclaimed Light and Versatile Graphics Library. It is designed to run on embedded platforms therefore I was confident I could port it to the ESP32. And that was even before I found out there was an existing ESP32 port of LVGL so that’s pretty concrete proof right there.

Researching how I might adapt that to ESP_8_BIT code, I poked around the LVGL documentation and I was pleased it was organized well enough for me to quickly find what I was looking for: Display Interface section in the LVGL Porting Guide. We are already well ahead of where I was with FabGL. The documentation suggested allocating at least one working buffer for LVGL with a size at least 1/10th that of the frame buffer. The porting developer is then expected to register a flush callback to copy data from that LVGL working buffer to the actual frame buffer. I understand LVGL adopted this pattern because it needs RAM on board the microcontroller core to do its work. And since the frame buffer is usually attached to the display device, off the microcontroller memory bus, this pattern makes sense. I had hoped LVGL would be willing to work directly with the ESP_8_BIT buffer, but it doesn’t seem to be quite that friendly. Still, I can see a path to putting LVGL on top of my ESP_8_BIT code.

As a side bonus, I found an utility that could be useful even if I don’t use LVGL. The web site offers an online image converter to translate images to various formats. One format is byte arrays in multiple pixel formats, downloadable as C source code file. One of the pixel formats is the same 8-bit RGB332 color format used by ESP_8_BIT. I could use that utility to convert images and cut out the RGB332 section for pasting into my own source code. This converter is more elegant than that crude JavaScript script I wrote for my earlier cat picture test.

LVGL offers a lot of functionality to craft user interfaces for embedded devices, with a sizable library of control elements beyond the usual set of buttons and lists. If sophisticated UI were my target, LVGL would be an excellent choice. But I don’t really expect people to be building serious UI for display on an old TV via composite video, I expect people using my library to create projects that exploit the novelty of a CRT in this flat panel age. Simple drawing primitives like draw line and fill rectangle is available as part of LVGL, but they are not the focus. In fact the Drawing section of the documentation opens by telling people they don’t need to draw anything. I think the target audience of LVGL is not a good match for my intended audience.

Having taken these quick looks, I believe I will come back to FabGL if I wanted to build an ESP32 device that outputs to VGA. If I wanted to build an embedded brain for a device with a modern-looking user interface, LVGL will be something I re-evaluate seriously. However, when my goal is to put together something that will be quick and easy to play with throwing something colorful on screen over composite video, neither are a compelling choice over Adafruit GFX Library.

Window Shopping: FabGL

I have a minimally functional ESP32 Arduino display library that lets sketches use the color composite video signal generator of ESP_8_BIT to send their own graphics to an old-school tube TV. However, all I have as an interface is a pointer into the frame buffer. This is fine when we just need a frame buffer to hand to something like a video game console emulator, but that’s a bit too raw to use directly.

I need to put a more developer-friendly graphics library on top of this frame buffer, and I have a few precedents in mind. It needs to be at least as functional as the existing TVout Arduino library, which only handles monochrome but does offer a minimally functional graphics API. My prime candidate for my purpose is the Adafruit GFX Library. That is the target which contenders must exceed.

I’m willing to have an open mind about this, so I decided to start with the most basic query of “ESP32 graphics library” which pointed me to FabGL. That homepage loaded up with a list of auto-playing videos that blasted a cacophony of overlapping sound as they all started playing simultaneously. This made a terrible first impression for no technical fault of the API itself.

After I muted the tab and started reading, I saw the feature set wasn’t bad. Built specifically for the ESP32, FabGL offers some basic user interface controls, a set of drawing primitives, even a side menu of audio and input device support. On the display side (the reason I’m here) it supports multiple common display driver ICs that usually come attached to a small LCD or OLED screen. In the analog world (also the reason I’m here) it supports color VGA output though not at super high color depths.

But when I started looking for ways to adapt it to some other display mechanism, like mine, I came up empty handed. If there is provision to expose FabGL functionality on a novel new display like ESP_8_BIT color composite video generator, I couldn’t find it in the documentation. So I’ll cross FabGL off my list for that reason (not just because of those auto-playing videos) and look at something else that has well-documented ways to work on an external frame buffer.

Miha Kocar’s ESP8266 Remote Control

Getting basic voltage monitoring up and running on my Sawppy Rover ESP32 controller was a good milestone for me to take a break from rover work. My code is publicly available up on GitHub and it is even moderately well organized and commented if anybody else wants to take it for a spin. Either for their own Sawppy rover, or for another vehicle. But if someone just wants basic remote control, they don’t have to deal with my code. There’s a simpler and cheaper option: Miha Kocar’s browser-based WiFi remote control built from an ESP8266.

I learned of this project via Hackaday and I consulted it briefly before starting my own Sawppy rover control project. I thought it was admirably minimalist. The entire baseline 2-channel implementation fits in a single file. The browser HTML, CSS, and JavaScript are all encapsulated into a single C string inside that file. Compared to my sprawling project, that is amazingly compact!

One of the ways this could be so simple were the input controls: this project used the existing HTML <input type="range"> control for controlling each axis, which meant it inherited all the code dealing with pointer events. Creative CSS styling made it look very different from a boring HTML form input. The downside is that each of these controls can only manage a single axis, there’s no good way to do a two-axis control pad as I wanted. Having two separate single-axis controls meant two-finger operation, my two-axis control pad allows single-finger operation. This feature was important enough for me to take on the extra complexity, something I occasionally regretted but I think it’s worth the extra work.

Kocar’s project uses websocket for client-server communication, and the code looked super simple and easy. Seeing it removed a lot intimidation for me when I started using websocket for myself. Like my code, it has a “failsafe” mode for when communication is lost, but I didn’t see any code enforcing a single driver.

The biggest reason I didn’t use this project as a direct precedent was that ESP8266 didn’t have a hardware PWM peripheral. These servo control PWM signals are all generated in software. This is fine for one or two channels like we see here, but Micro Sawppy required upwards of 16 PWM channels and that’s too much to expect from an ESP8266, which didn’t have enough IO pins anyway. I needed the PWM hardwareand GPIO pins— of an ESP32.

The next reason was that I much preferred FreeRTOS and how it allowed me to organize individual functionality into tasks. Instead of managing it all myself in a single Arduino loop(), I have the FreeRTOS task scheduler handle things. Information flow between components are managed with FreeRTOS queues. From a personal preference point, I liked having this level or organization.

But I admit all the overhead I added to handle a six-wheel-drive, four-wheel-steering micro Mars rover would be sheer overkill for many other projects. Sometimes a project just need a simple straightforward two-channel remote control, and Miha Kocar’s project is a better tool for that job.

And as a change of pace from my little micro Mars rover, I started looking at a tool for an entirely different job: putting a color picture on an old analog television.

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.

Quick Look: ESA ExoMy Rover

Ryan Kinnett’s Micro Rover isn’t the only 3D-printable rover built by people affiliated with real spaceflight hardware. We also have a rover from European Space Agency’s ESTEC facility at Noordwijk, Netherlands. This facility holds an annual Open Day and in 2018 they showed off a little motorized rover that was much loved by the guests. After some evolution, the model was released worldwide earlier this year as the ExoMy rover with backing of ESA’s publicity department.

ExoMy’s spaceflight counterpart is ESA’s ExoMars rover, which has since been given the name Rosalind Franklin in honor of the accomplished scientist. But unlike most of the other rovers I’ve examined, ExoMy’s design priority was not on scale mechanical fidelity. Instead, ExoMy designers went for an approachable cute appearance. Its suspension still follows the general triple-bogie geometry of Rosalind Franklin, but with stubbier proportions. Rather than a faithful copy of the instrument cluster atop the mast, ExoMy has an anthropomorphic face with eyes and a mouth whose smile happens to be a stylized version of the ESA logo. The head is designed to be modular so rover builders can vary expression and add accessories like tophats and bowties. Very clever, and very cute.

I think it’s worth investigating to make a cute cartoony variant of the JPL rovers as well, for public outreach with younger audiences. (I’ve stated this before, and work has already begun. More details later on this blog.)

Mechanically, all ExoMy articulation comes from standard-sized remote control hobby servo motors. Six continuous rotation variants for wheel rolling, and six position control servos for steering. With ability to steer all six wheels, ExoMy can crab sideways which is not possible with the design used by JPL rovers (and the rovers they inspired) who have fixed nonsteerable middle wheels. Rosalind Franklin also has an additional degree of motion to articulate the wheels to “wheel-walk” across difficult terrain. ExoMy skipped this feature but perhaps an ambitious rover builder will find a way to incorporate it into their design.

Like all the rovers examined over the past few posts, wheel forces are borne directly by their gearboxes without assistance of ball bearings to help take the load. Looks like I am the only one picky about this topic, and I’m perfectly OK with that. It means I have something to set my rover designs apart.

As I mentioned in my Hackaday post about ExoMy, it was probably intended to be released alongside the launch of Rosalind Franklin. Unfortunately the big rover missed its launch window, leaving the little one to take up publicity for ESA’s Martian exploration this year. With such a charming presence, ExoMay is up to the task.

One non-rover-specific feature that caught my attention on ExoMy was the attention paid to keeping wires neat and tidy, tucked into channels designed into suspension arms. My own rover is not so tidy.

UPDATE: I found an ESA page with side-by-side image comparing ExoMy with Rosalind Franklin (ExoMars)

ExoMy and Rosalind Franklin (ExoMars). Source: European Space Agency

Quick Look: Bricolabs Rovers

Next stop in the world tour of 3D-printed fan rovers is Spain (or at least a Spanish-speaking nation) home of Bricolabs Technology Laboratory. (BTL) In contrast to the sophisticated visual fidelity of Frédéric Jelmoni’s rover, Bricolabs went down the path of clean minimalism for their Curiosity BTL rovers.

Yes, rovers plural. For there are two variants of Curiosity BTL: A small 1:10 scale and a larger 1:5 scale. The larger 1:5 scale version uses tires that are available from Pololu and other sources. They resemble the remote control monster trucks tires used on the JPL Open Source Rover, but on this rover they are mounted on 3D-printed wheel hubs. Those six wheel hubs fasten directly to the output shaft of six gearmotor for six-wheel drive. The four-wheel steering duties are handled by full-size (?) remote control hobby servo motors. Thankfully, rather than making the servos handle all of this workload, Curiosity BTL 1:5 includes bearings for their steering joint.

Full rocker-bogie suspension geometry is present and accounted for, with suspension arm segments and the body built out of aluminum extrusion beams of 10mm x 10mm profile. All 3D-printed components were designed in OpenSCAD and these sources files are available alongside 3D-printing STL files in its GitHub repository.

The smaller 1:10 scale rover is even simpler. No aluminum extrusion beams are involved, the entire thing is 3D printed. Wheel drive gearmotors drop down to N20 type gearmotors. Steering duties are handled by micro servos and now they must function without bearing assistance. I’ve used the little 9g micro servos that look like those in the picture, and they have an incredible amount of play in the geartrain which would have led to some very wobbly corner motors. Perhaps the ones visible here are of higher quality.

The wheel hub is also 3D printed and fit directly to gearmotor output shaft, but instead of a commercially available tire the little one has grousers that are 3D printed separately, optionally with different color and material. Again, all STL and OpenSCAD files are available on GitHub.

In the Curiosity BTL family portrait, they are posed alongside the LEGO IDEAS Curiosity rover.

With a common architecture of DC motors on the wheels and RC servo motors for steering, it appears both rovers share the same electronics architecture. An Arduino Mega sends out steering servo signals directly, and also control three DC motor drivers each of which controls two of the driving wheels.

I quite like the simplicity of Curiosity BTL rovers, making them easier to build and accessible to a wider audience. However they do lack a few features that I desire in my own rover, something I keep nitpicking on other rover designs: I want ball bearings on my rotational axis! Designers for these rovers have largely decided the bearings to be extraneous, or that bearings already in their servos/gearboxes are sufficient. This is a valid design decision and is used on other rover designs like Ryan Kinnett’s Micro Rover.

Quick Look: Frédéric Jelmoni’s Reproduction du Rover Mars 2020

Our world tour of fellow 3D-printed fan rovers started in Sweden with Jakob Kranz’s Mars Rover project. The next stop is France, or at least, a French-speaking nation: Reproduction du Rover Mars 2020 by Frédéric Jelmoni. (Thanks to Quinn Morley for passing this one along.) This project is still working up to the first complete iteration, and Jelmoni wants to finish V1 before publishing details so we have to be satisfied with glimpses on the web site and YouTube videos.

Similar to what I did with Sawppy, Jelmoni took orthographic views of Perseverance rover into Autodesk Fusion 360 and dimensioned a layout to scale. This ensures the rover has correct proportions. Looking at the screen shot of his layout, it looks like his wheels have a diameter of 125mm. This is slightly larger than Sawppy’s 120mm but in practice our rovers should be effectively identical in size.

While the body of this rover is built out of aluminum extrusion beams like Sawppy, the suspension arms are built from metal tubes instead. Based on color, my guess is aluminum. This gives an appearance more faithful to the original. The focus on visual fidelity is a consistent theme throughout this project. My Sawppy project gave up a lot of visual fidelity in favor of 3D printing practicality, so our two rover projects reflect different priorities.

A good example are the wheels. These are absolutely gorgeous! The wheel spokes replicate the inner curvature of each spoke, skipping the outer curvature visible in the online 3D model. They look great but I worry about their strength which was why I forfeited fidelity for my own rover wheel design. The 3D printer settings needs to be very well dialed in for optimal layer adhesion, otherwise these spokes are liable to fracture along layer lines. Aussie Sawppy explored a similar idea and the spokes fractured exactly in the way I feared they might. TeamSG blamed it on cheap PLA so I’d be curious if they’ll retry with different filament. Similarly, I’ll be curious to see how this design works out for Jelmoni. Especially if there will be any results from stress testing these wheels.

I loved seeing the rocker-bogie differential design used here. I don’t think the main differential body is 3D-printed. It almost looks like MDF (painted black) but I’m not confident on that guess. Many of the linkage pieces are 3D printed, the most illuminating part being the eye bolt used as the differential bar hinge. This is a good way to handle the multi-axis loads, but I find it curious that it is only used on one side of the link and the rocker side has only a single degree of freedom hinge. Perhaps multiple degrees of freedom movement is not as necessary as I thought it might be.

I’m also curious what material is being used for this rover’s flat body sides. These flat textured panels appear to be commodity items and not 3D printed. Which is great because the power of 3D printing is largely wasted printing large flat sheets. They are best at building unique shapes tailored to an application at hand. A focus on that uniqueness to create a clean minimalist design leads to the Bricolabs rovers.

Quick Look: Jakob Krantz Mars Rover

Since the time I’ve published my Sawppy rover project, I’ve learned of a few other rover projects with no relation to Sawppy (other than being inspired by the same rovers on Mars) but also utilize 3D printing. These are far more affordable than trying to duplicate the mechanical workings of a rover in LEGO. This collection also happens to hail from around the world. The first stop of this world tour is Sweden, home of a rover published by Jakob Krantz titled simply “Mars Rover”. It uses commodity PVC pipes for suspension structural members instead of the aluminum extrusion beams I used on Sawppy. The overall size is slightly larger than Sawppy, with different proportions. For example, the wheels and body appear to be smaller than proportional to Curiosity. But it is recognizably and undeniably inspired by NASA JPL Mars Rovers.

Full rocker-bogie is presented and accounted for, including 3D-printed links for the differential. Sawppy didn’t use 3D printing for these parts, it used the same hardware used on the JPL Open Source Rover. They are adjustable suspension link turnbuckles from the remote control car world, and I have yet to think up or find a 3D printed design that worked as well as those turnbuckles. It’s not clear how Krantz’s design handles rotation across multiple degrees of freedom and browsing the published CAD file only shows gaps where some critical components of the joint (bearings? bushings?) would sit. How these differential links function remains a mystery to me for now.

The published parts list included several bearings, all of which appeared to be used in the rocker-bogie suspension. Examining its CAD file confirmed that all wheel forces are sitting directly against the drive motor gearbox, and all corner wheel forces are directed into the steering servos. I prefer to have ball bearings handling such forces instead of the motor gearboxes directly, and designed Sawppy to use a pair of 608 ball bearings at each rotational joint. Perhaps overkill, but it’s what I like to have.

On the electronics side, Krantz’s rover uses ESP32 for its brains. As a powerful and affordable microcontroller with wireless capability, it is a very good choice for robotics projects. Especially since it is now one of the supported Micro-ROS architectures for interfacing with ROS2. I haven’t seen any interest from Krantz about putting ROS2 on his rover, but the option is there if he wants to.

And there’s plenty of time for future work. Like Sawppy, this rover is a long-term project of Jakob Krantz who has been working on his rover for at least a year. Or at least, there were two Hackaday writeups for his project a year apart. It is a labor of love and I know that well. It’s a journey that Frédéric Jelmoni has recently embarked on for a younger rover project focused on Perseverance.

Window Shopping LEGO Rovers

After seeing circuit boards being used as structural members in the 4tronix M.A.R.S. rover, I realized that I had forgotten a very fertile field: LEGO! My interest in mechanical systems today is something I give full credit to the LEGO sets I had growing up. My LEGO creations grew more complex as I grew older, limited only by my toy budget. However, once I got up and running on 3D printing objects of my imaginations, I haven’t touched my big box of LEGO since. I quite enjoy the freedom of not being constrained by what LEGO pieces are available.

Among currently available LEGO sets, there is a tiny little Mars rover as part of the LEGO CITY Mars Research Shuttle (60226). The set is quite affordable, but about the only thing its little rover has resembling Curiosity rover are the number of wheels. Beyond that, there is no rocker-bogie and no corner steering, which is not a surprise at this price point.

Moving up the price and complexity scale is the LEGO NASA Mars Science Laboratory Curiosity Rover (21104), released in 2014 and no longer in production. This was part of the LEGO Ideas program where people can submit their LEGO designs and, if enough other LEGO fans voted in favor, the LEGO group will consider adapting it for production. This particular idea received over 10,000 supporting votes and became an official product. Perusing its assembly instruction PDF, I was surprised to find that this rover has a fully articulating rocker-bogie suspension. Very impressive! I also sadly learned that it required several pieces that I lack in my own LEGO collection, so I couldn’t “just” follow the directions to build one of my own. At some point I could go hunt for the few missing pieces which should be cheaper than buying this out-of-production kit on eBay. People are asking over $100 for a used kit and as much as $1,100 for a never-opened box. That’s more than two Sawppy rovers!

But if price is no object, I can look to other LEGO creations people have posted. There are quite a few “LEGO rover” projects online, and it follows roughly the same trajectory as the past few window shopping posts: most don’t even have six wheels, some have six wheel rocker-bogie but no corner steering, etc.

An example of a rover with corner steering is this LEGO MINDSTORM NXT creation. Despite being constrained by the selection of available LEGO pieces, it nevertheless replicated some features that I skipped with my 3D-printed rover. One example being the spokes in each of the six wheels, which I had simplified for 3D printing but the builder here faithfully represented more of the curves. And they have a robot arm, which my Sawppy is still waiting for. But according to the text, only the four corner wheels drive leaving the middle wheels free-wheeling. And it’s not obvious if the rocker-bogie articulates faithfully. At the very minimum, this design is missing the differential bar across the top.

This rover looks to be roughly the same size as my Sawppy rover, but the price tag would be significantly higher. There are six visible NXT brains on this invention: five on board the rover and one for the handheld remote. Each $350 MINDSTORM NXT box comes with a single NXT brain, so this rover costs at a minimum 6 * $350 = $2,100 dollars. Yikes.

So as far as LEGO rovers go, the best ones that implement features I consider important are build-it-yourself designs by enthusiasts and not available as commercial products. Thus we return to the world of 3D printing, where Sawppy isn’t the only rover design floating around.

Window Shopping 4tronix M.A.R.S. Rover

Wheeled robot kits calling themselves rovers are plentiful, but rarely do they faithfully represent the JPL rovers sent to Mars. ServoCity’s Bogie Runt Rover at least is a six-wheel chassis with rocker-bogie suspension, but is missing the corner wheel steering system. Looking for commercially available products out there with six wheel drive rocker-bogie and four corner steering, I was almost ready to conclude none existed until I came across the 4tronix M.A.R.S Rover Robot.

The name is an acronym for Mobile Autonomous Robotic System and the autonomy comes from the brainpower of either a Raspberry Pi Zero or BBC micro:bit. Out of all the commercial products I’ve come across, M.A.R.S. has the most mechanically faithful model of Curiosity and Perseverance suspension geometry. It has roughly similar proportions, and uses a differential arm over the body. Sojourner, Spirit, and Opportunity use a differential inside the body in order to maximize top surface area for solar panels. The nuclear-powered Curiosity and Perseverance didn’t have such constraint. By moving the differential above, they gained body interior volume.

Perusing the assembly instructions I see the structural components are all printed circuit boards (PCB) which is not usually considered structural material but apparently can be made to work at this scale. Six wheel drive comes from N20 micro gear motors, and four wheel steering comes from MG90S metal gear micro servos. Both of these are fairly widely available for maker projects and good choices.

My quibble with the M.A.R.S. rover are with its rotational motion joints. First up are the rocker-bogie suspension components, each of the joints are a M3 screw inside a PCB hole. I’m queasy about using fasteners as axles, since their threads are not really designed to carry a load. There are no bearings on these joints and the screws have to be tightened precisely. Too tight, and the joints would bind. Too loose, and the rover will wobble. This seems awfully finicky and would loosen as the rover travels.

Second, each wheel’s weight is transferred directly into the N20 micro gearbox. Examining pictures of these gearboxes online, it does not appear the gearbox is designed to handle loads perpendicular to rotational axis. Perhaps the rover is lightweight enough the load would be fine, but all I see are metal shafts turning inside holes in brass plate.

And third, each of the corner steering wheel assemblies are attached directly to the steering micro servo’s horn. Despite the metal gears, MG90S type servos still has a great deal of flexibility and play in its gearbox in the face of loads perpendicular to rotational axis. We can see each corner steering assembly wobbling noticeably while in motion:

(I also smiled when I realized this video cuts out right when the rover starts tackling a very challenging vertical climb. We’ll never know if it managed the climb.)

The final quibble I have with this design is that the steering axis is not aligned with the wheel. In less formal terms, it means the wheel is sideways offset from its corresponding steering servo instead of sitting directly under the servo. As a result, when the steering servo rotates, its wheel isn’t pivoting about a point. Instead, it is dragged through an arc. This adds a great deal of mechanical stress to the steering mechanism. It also makes the desired wheel velocity harder to calculate through a turn, but it appears the M.A.R.S. software skips that detail. All left side wheels are commanded to turn at the same rate, and all right side wheels are the same with each other. As a result we can see a bit of wheel skid through a turn, reintroducing some of the problems of using a strictly skid steer system as the Bogie Runt Rover did.

In conclusion M.A.R.S. has the mechanical sophistication of corner steering in addition to a good representation of rocker-bogie suspension, but its current iteration does not yet take full advantage. Still, it looks like a nifty little kit and the price of one hundred pounds is significantly lower than the cost of parts for Sawppy.

This concludes my quick tour of commercially available rover kits. But before I move on to DIY rovers, there’s a rover category that bridges across both “commercial product” and “do it yourself”: LEGO rovers.

Window Shopping ServoCity Bogie Runt Rover

The littleBits Space Rover is a cute little thing, but with only two wheels it bears little resemblance to real life Martian robot explorers. Moving a little bit higher on the fidelity scale, there are some robots out there with six wheels arranged in a rocker-bogie geometry. A representative of this breed is the ServoCity Bogie Runt rover.

Browsing the ServoCity web site, it appears that the Bogie Runt is the largest and most complex (so far?) of their line of “Runt Rover” chassis kits. Peewee, Sprout, and Zip Runt Rovers are two-wheel differential drive chassis like the littleBits Space Rover. Then there are the Junior, Half-Pint, and Whippersnapper Runt Rovers which roll on four wheels. The Bogie Runt is the only one with six wheels, and the only one with an articulating suspension system.

On ServoCity’s “Robot Chassis Kits” page they are all listed under “Smooth Surface.” This is certainly true for all the other Runt Rovers, but the Bogie Runt should be able to handle rougher terrain thanks to the rocker-bogie suspension system. It’s not obvious if the smooth surface classification for Bogie Runt was a mistake, or if it was deliberate based on information not immediately visible from just window shopping.

All of the Runt Rover kits appear to be made by laser (or possibly waterjet) cutting of flat materials, likely some type of plastic. They have bolt patterns to connect with ServoCity’s Actobotics build system which is mostly aluminum. Actobotics is very popular with FIRST Robotics participants and because of that, it was also the build system selected for the JPL Open Source Rover.

But that also causes a problem I have with the Bogie Runt: Actobotics is based on Inch dimensions and thus problematic for use outside of the United States. Sawppy is metric and, for worldwide compatibility, I plan to keep all derivatives and descendants metric.

Another shortfall of Bogie Runt is the lack of corner steering mechanisms. It is thus constrained to differential drive (a.k.a. “Tank Steer”) which works very well for two wheels but precision drops as the number of contact patches go up. In my experience, differential drive is marginal for four wheels, and behaves unpredictably with six. It was a tradeoff the Bogie Runt Rover product made against cost and complexity, leaving room for improvement and motivation for me to keep looking.