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.

Window Shopping littleBits Space Rover Inventor Kit

Before I start getting too ambitious with making my personal rover project more like a user-friendly commercial product, I should look around to see if a product already existed. There are a lot of robot kits out there trying to earn that STEM education money, and some of them do try to get a slice of the excitement around our interplanetary robotic explorers. And while some of them are interesting and have their own merits, most of them lack features that I consider critical in a rover relative.

A representative example is the Space Rover Inventor Kit from littleBits. I like the idea of littleBits, giving beginners a very friendly way to explore electronics by making components with magnetic connectors. This makes electrical connections easy and also helps avoid beginner mistakes like accidentally reversing electrical polarity. The downside is that the customer has to pay a premium for this capability, and it’s not a premium that I’ve been personally willing to pay. This particular kit has a MSRP of $200 USD, and for that kind of money I would much rather build my own robot. (Though at time of this posting, the kit is on sale for $30.)

As a supplement to generic electronics beginner kits, littleBits also apply their technology to some themed offerings like this Space Rover kit. All the electrical components are reusable and remixable littleBits centered around a robot control module. The module is interesting because it interacts with a phone app, giving the rover remote control capabilities. But I also see the app as a disadvantage: as I understand it, the app would discourage experimentation. If the user changes the rover around, it wouldn’t take much before it exceeds what the phone app can gracefully handle. Thus motivating the user to leave it in the space rover configuration, defeating the point of using littleBits to begin with.

But in my eyes the biggest shortfall of this rover is its two-wheeled differential drive chassis. Similar to what home robot vacuums like Roomba uses. This is fine for flat indoor ground, which is what earthbound rovers mostly end up doing anyway. So as a home education toy this is a good technical choice. But for fans of rocker-bogie like myself, this is sorely lacking and we must look elsewhere.

But at least this little Space Rover has an arm. Looks like it only has one degree of freedom, which is very limiting, but that’s one more degree of freedom than Sawppy’s nonexistent robot arm. Victory: littleBits Space Rover!

Window Shopping: NASA Perseverance Rover 3D Print Static Model

After finishing a model of Mars rover Curiosity, the obvious question is: did NASA release a 3D print static model of its successor Perseverance? And the answer is yes! Curiously, the web site page points to a 3D file suitable for graphics rendering, not for 3D printing. But poking around the GitHub repository revealed there’s a “M2020” 3D print model. (Before receiving its name, Perseverance was called Mars 2020.)

Armed with my recent experience, I looked over the files for this printable rover. First the good news: the rocker-bogie suspension is represented in much higher fidelity on this model. The full rocker bogie geometry is represented, including a differential bar that is designed for some bent paperclips to serve as critical linkages. The wheel tracks appear to be correct with the center pair of wheels having wider tracks than the front and rear pairs. And the geometry is more accurate, no weird right angle bends as concession to ease of printing.

The lack of concession to ease of printing is also the bad news. Unlike the previous model, none of the geometry has been modified to fit flat on a print bed. Printing this model will require, at a minimum, printing with supports which is always problematic. Dual-material printer with dissolvable supports should make such designs easy to print, but I don’t have one of those.

Another change from the previous model is that this one doesn’t use snap-together construction. Parts are designed to be glued together instead. It also means these files assume a much higher printing precision, since superglue requires a much tighter fit than snap-together construction.

If I saw these traits on a Thingiverse item, I would be skeptical that the model is even buildable. That site is littered with too many things that are obviously impossible, merely the dream someone created in CAD and never test printed.

But this one appears to be real, since among the STL files is a picture of this rover design that has been built. Looking over the print quality of its parts, it was obviously printed at high detail quality on a good printer. Likely better than mine! I think I’ll hold off printing this rover design for the moment. Maybe later, when I have a well dialed-in printer that I can trust to meet precise tolerance requirements. In the meantime, I can admire the Perseverance 3D Model released by NASA that lives strictly in the digital realm.

Seeed Studio Odyssey X86J4105 Has Good ROS2 Potential

If I were to experiment with upgrading my Sawppy to ROS2 right now, with what I have on hand, I would start by putting Ubuntu ARM64 on a Raspberry Pi 3 for a quick “Hello World”. However, I would also expect to quickly run into limitations of a Pi 3. If I wanted to buy myself a little more headroom, what would I do?

The Pi 4 is an obvious step up from the 3, but if I’m going to spend money, the Seeed Studio Odyssey X86J4105 is a very promising candidate. Unlike the Pi, it has an Intel Celeron processor on board so I can build x86_64 binaries on my desktop machine and copy them straight over. Something I hope to eventually be a painless option for ROS2 cross compilation to ARM, but we’re not there yet.

This board is larger than a Raspberry Pi, but still well within Sawppy’s carrying capacity. It’s also very interesting that they copied the GPIO pin layout from Raspberry Pi, the idea some HATs can just plug right in is very enticing. Although that’s not a capability that would be immediately useful for Sawppy specifically.

The onboard Arduino co-processor is only useful for this application if it can fit within a ROS2 ecosystem, and the good news is that it is based on the SAMD21. Which makes it powerful enough to run micro-ROS, an option not available to the old school ATmega32U4 on the LattePanda boards.

And finally, the electrical power supply requirements are very robot friendly. The spec sheet lists DC input voltage requirement at 12V-19V, implying we can just put 4S LiPo power straight into the barrel jack and onboard voltage regulators will do the rest.

The combination of computing power, I/O, and power flexibility makes this board even more interesting than an Up Board. Definitely something to keep in mind for Sawppy contemplation and maybe I’ll click “Add to Cart” on this nifty little board (*) sometime in the near future.

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

Update on ARM64: ROS2 on Pi

When I last looked at running ROS on a Raspberry Pi robot brain, I noticed Ubuntu now releases images for Raspberry Pi in both 32-bit and 64-bit flavors but I didn’t know of any compelling reason to move to 64-bit. The situation has now changed, especially if considering a move to the future of ROS2.

The update came courtesy of an announcement on ROS Discourse notifying the community that supporting 32-bit ARM builds have become troublesome, and furthermore, telemetry indicated that very few ROS2 robot builders were using 32-bit anyway. Thus the support for that platform is demoted to tier 3 for the current release Foxy Fitzroy.

This was made official on REP 2000 ROS 2 Releases and Target Platforms showing arm32 as a Tier 3 platform. As per that document, tier 3 means:

Tier 3 platforms are those for which community reports indicate that the release is functional. The development team does not run the unit test suite or perform any other tests on platforms in Tier 3. Installation instructions should be available and up-to-date in order for a platform to be listed in this category. Community members may provide assistance with these platforms.

Looking at the history of ROS 2 releases, we can see 64-bit has always been the focus. The first release Ardent Apalone (December 2017) only supported amd64 and arm64. Support for arm32 was only added a year ago for Dashing Diademata (May 2019) and only at tier 2. They kept it at tier 2 for another release Eloquent Elusor (November 2019) but now it is getting dropped to tier 3.

Another contributing factor is the release of Raspberry Pi 4 with 8GB of memory. It exceeded the 4GB limit of 32-bit addressing. This was accompanied by an update to the official Raspberry Pi operating system, renamed from Raspbian to Raspberry Pi OS, is still 32-bit but with mechanisms to allow addressing 8GB of RAM across the operating system even though individual processes are limited to 3GB. The real way forward is to move to a 64-bit operating system, and there’s a beta 64-bit build of Raspberry Pi OS.

Or we can go straight to Ubuntu’s release of 64-bit operating system for Raspberry Pi.

And the final note on ROS2: a bunch of new tutorials have been posted! The barrier for transitioning to ROS2 is continually getting dismantled, one brick at a time. And it’s even getting some new attention in long problematic areas like cross-compilation.

Window Shopping ARCore: API Documentation

Investigating Google ARCore for potential robotics usage, it was useful to review their Fundamental Concepts and Design Guidelines because it tells us the motivation behind various details and the priorities of the project. That gives us context around what we see in the nuts and bolts of the actual APIs.

But the APIs are where “the rubber meets the road” and where we leave all the ambitions and desires behind: the actual APIs implemented in shipping phones define the limitations of reality.

We get a dose of reality pretty immediately: estimation of phone pose in the world comes with basically no guarantees on global consistency.

World Coordinate Space
As ARCore’s understanding of the environment changes, it adjusts its model of the world to keep things consistent. When this happens, the numerical location (coordinates) of the camera and Anchors can change significantly to maintain appropriate relative positions of the physical locations they represent.

These changes mean that every frame should be considered to be in a completely unique world coordinate space. The numerical coordinates of anchors and the camera should never be used outside the rendering frame during which they were retrieved. If a position needs to be considered beyond the scope of a single rendering frame, either an anchor should be created or a position relative to a nearby existing anchor should be used.

Since it is on a per-frame basis, we could get Pose and PointCloud from a Frame. And based on that text, these would then need to be translated through anchors somehow? The first line of Anchor page makes it sound that way:

Describes a fixed location and orientation in the real world. To stay at a fixed location in physical space, the numerical description of this position will update as ARCore’s understanding of the space improves.

However, I saw no way to retrieve any kind of identifying context for these points. Ideally I would want “Put an anchor on that distinctive corner of the table” or some such. But still, “Working with anchors” has basic information on how it is useful. But as covered in many points throughout ARCore documentation, use of anchors must be kept at a minimum due to computational expense. Each Anchor is placed relative to a Trackable, and there are many ways to get one. The biggest hammer seems to be getAllTrackables from Sesson, which has a shortcut of createAnchor. There are more narrowly scoped ways to query for Trackable points depending on scenario.

Given what I see of ARCore APIs right now, I’m still a huge fan of future potential. Unfortunately its current state is not a slam dunk for robotics application, and that is not likely to change in the near future due to explicit priorities set by the product team.

But while I had my head buried in studying ARCore documentation, another approach popped up on the radar: the OpenCV AI Kit.

Window Shopping Google ARCore: Design Guidelines

After I got up to speed on fundamental concepts of Google ARCore SDK, I moved on to their design recommendations. There are two parts to their design guidelines: an user experience focused document, and a software development focused variant. They cover many of the same points, but from slightly different perspectives.

Augmented reality is fascinating because it has the potential to create some very immersive interactive experiences. The downside is that an user may get so immersed in the interaction they lose track of their surroundings. Much of the design document described things to avoid in an AR app that boiled down to: please don’t let the user hurt themselves. Many potential problems were illustrated by animated cartoon characters, like this one of an user walking backwards so focused on their phone they trip over an obstacle. Hence one of the recommendations is to avoid making users walk backwards.

Image source: Google

Some of the user experience guidelines help designers avoid weaknesses in ARCore capabilities. Like an admission that vertical surfaces can be challenging, because they usually have fewer identifiable features as compared to floors and tabletops. I found this interesting because some of the advertised capabilities, such as augmented images, are primarily targeted to vertical surfaces yet it isn’t something they’ve really figured out yet.

What I found most interesting was the discouragement of haptic feedback in both the UX design document and the developer document. Phone haptic feedback are usually implemented as a small electric motor spinning an unbalanced weight, causing vibration. This harms both parts of Structure from Motion calculations at the heart of phone AR: vibration adds noise to the IMU (inertial measurement unit) tracking motion, and vibration blurs the video captured by the camera.

From a robotics adaption viewpoint, this is discouraging. A robot chassis will have motors and their inevitable vibrations, some of which would be passed on to a phone bolted to the chassis. The characteristics of this vibration noise would be different from shaky human hands, and given priority of the ARCore team they would work to damp out the human shakiness but robotic motions would not be a priority.

These tidbits of information have been very illuminating, leading to the next step: find more details in the nitty gritty API documentation.