I am happy to announce the Dual TB9051FTG Motor Driver Shield for Arduino. It gives you two of our favorite integrated motor driver (you can read more about why I like it in my TB9051FTG carrier blog post) in the convenient Arduino shield form factor. You can also think of it as a lower-cost, slightly higher-performance version of our popular Dual MC33926 Motor Driver Shield for Arduino.

With a 4.5 V to 28 V operating range and the ability to deliver up to a few amps per motor, the TB9051FTG is great for a huge range of small hobby and toy motors that you might have available in your parts box or classroom.

For those who don’t need all the power that the TB9051FTG can support, we also have the smaller (and lower cost) Dual MAX14870 Motor Driver Shield for Arduino.

As usual, we have an introductory discount to go with this new product announcement. Be among the first 100 customers to use coupon code TB9051SHIELD (click to add the coupon code to your cart) and get up to three units for just $9.97 each. The introductory coupon for the single TB9051FTG carrier is still available, along with some discounts for other products we have introduced this year; you can see all the coupons that are not used up yet on our specials page.

A while ago, I made a wedding gift for some friends, both of whom are avid Star Wars fans. The gift was basically a multi-piece decorative set that consisted of a modified toy Han Solo blaster, a stand to hold the blaster, and three edge-lit LED displays: one each of Boba Fett, Darth Vader, and Jar Jar Binks. I painted over the toy blaster to make it look more like it came straight out of the movies and added electronics so that it could interact with the displays (and the couple’s TV!).

The blaster uses IR TV remote codes to do several things: it can shoot the LED displays (and they’ll respond by blinking and playing audio recordings unique to each character), change the color and brightness of each display, and it can act as a limited TV remote by turning on or off the TV. At the heart of the blaster lies an A-Star 32U4 Mini ULV, which monitors the state of a switch, a couple of buttons, and a few potentiometers in order to decide which actions to carry out. The ULV version of the A* Mini is especially convenient for this setup because the toy blaster was originally powered by two AAA batteries, which produce too low of a voltage for a 5V microcontroller. The ULV’s built-in switching step-up voltage regulator allows it to operate directly off of the batteries and power the other components, unlike typical Arduinos that need at least 7V.

The blaster has two modes: one for shooting the displays and turning on/off the TV and another for adjusting color and brightness of the displays. Which mode the blaster is in is determined by the state of the programming mode switch, which is accessible with a flick of the thumb. While powered on, the A* continually checks to see if the programming mode switch is enabled. If it is disabled, the blaster will respond to trigger presses. When the trigger is depressed, the A* does two things: it sends a pulse train to a 5mm IR LED and drives an input pin low on an Adafruit Audio FX Mini sound board, which then outputs sound to a speaker through a 2.5W audio amplifier, producing DL-44 blaster firing noises. The blaster and displays use the IRremote Arduino library for sending and receiving the pulses. For these blaster shots, the blaster emits the IR TV remote code that corresponds to the generic power-on/power-off code for an LG TV. This same code is decoded by the Star Wars displays as a “hit” and the characters react to being shot. You can watch videos of those reactions in the YouTube playlist below (the playlist also includes the displays’ bonus Easter egg content, which is only accessible by sending certain button presses from the LG TV remote!). The sound level is a little low, so you might need to increase your volume to hear what the characters are saying:

If the programming mode switch is enabled, the blaster repeatedly emits a set of IR TV remote codes that contain information on what color and how bright the displays should be. Color is adjusted in the HSV color space using the blaster’s three rotary potentiometers (one each for hue, saturation, and value). There is also a linear potentiometer that can be used to set overall brightness (this effect combines with the change in brightness from adjusting the value potentiometer). So long as a display’s IR receiver can detect the IR signal sent by the blaster, the LED information can be decoded and the LED arrays can be updated.

Each display features a ~12″ tall profile of the head or upper body of a Star Wars character. The profiles are laser-etched onto a 1/2″ thick clear acrylic piece, which also has holes at its base. The holes allow the piece to be fastened to a recessed channel at the top of the display box. A short segment of an APA102C LED strip lines the bottom of the recessed channel and faces upward into the acrylic profile, which allows its light to disperse across the laser-etched surfaces. The display box has the same sound board and amplifier as the blaster, but uses a more powerful 1W speaker. An A-Star 32U4 Prime controls everything and power is supplied via a 9V 3A wall power adapter.

Compared to the rest of the system, the design of the blaster stand is pretty straightforward: it is just several pieces of 1/4″ plywood arranged into a frame that houses two channels. Those two channels have mounting holes which allow two clear acrylic pieces, which conform to the shape of the blaster, to be fixed to the frame. A lip along the inside of the frame makes it easy to mount the silver mirrored acrylic piece. The bottom of the mount features a personal well-wish from me to the couple. The message is written on the inside of the Alliance Starbird, which is cut from gold mirrored acrylic. The stand also houses some scrap metal parts (a bunch of prototype Zumo blades) to give it some weight. Four adhesive rubber feet, one for each corner of the stand, help make sure the stand doesn’t slide around easily and scrape the gold Starbird piece.

I owe a part of the inspiration of this gift to my coworker, Kevin, since in some ways I was basically trying to one-up his Harry Potter-themed wedding gift, which was given to another coworker, Brandon, for his wedding. Kevin also ended up helping me make some good decisions and generate some clean-looking CorelDraw files for the display cutouts/rastering. So, thanks, Kevin! You the real MVP.

For more pics, gifs, and a build log, check out this Imgur album! Also, you can find 2D (.DXF and .CDR) and 3D (.STL, .STEP, and .SLDPRT) CAD files for the laser cut parts on my Thingiverse page!

In celebration of Independence Day (July 4th), we are discounting selected products by up to 25% and offering an upgrade to the next best price break for everything else in our store. Please note that we will be closed Wednesday, so orders placed after 2 PM Pacific Time on Tuesday, July 3 will be shipped on Thursday, July 5.

For more information, including all the discount coupon codes, see the sale page.

Happy 4th of July!

I have some exciting new wheels to tell you about (available as an 80×10mm black pair and an 80×10mm white pair). With a few small exceptions, all of the wheels we have made so far were for press fits (more properly called interference fit) onto 3mm D shafts such as those on our micro metal gearmotors. The press fit is simple and convenient for smaller motors and wheels, but there is an inherent trade-off between how hard you have to push to get the wheel on the shaft and how well the wheel stays on the shaft. As we contemplated designing some new wheels for our growing lines of 20D gearmotors and 25D gearmotors with 4mm output shafts (and higher power), I wanted something better. Our wheels already worked with our machined hubs with set screws, like this:

But the machined hubs are expensive, more expensive than the rest of the wheel. There’s also the much more minor issue of the machined hub option only allowing for the wheel to be placed at the very end of the shaft unless you drilled out the plastic wheel to have a hole larger than the shaft. I wanted to have an all-plastic, injection moldable solution that involved multiple parts that would somehow clamp the wheel onto an axle, kind of like a chuck on a drill.

My initial idea was to have just two parts: the outer wheel and an inner, interchangeable collet that would get wedged between the wheel and axle. But our mechanical engineers were not able to come up with a single part that could both compress onto the shaft and attach rigidly to the outer wheel. Because the parts are so small, the resolution of our 3D printer limited the effectiveness of prototypes, so we worked with scaled-up models. This picture shows one earlier model next to the final production parts for scale:

The other side of that model shows what we were thinking about for holding nuts in place on the back side of the wheel:

At that point, we were at a three-component design, plus the three screws and nuts, which was turning out to be difficult to assemble onto a shaft, even if it worked. The screw heads needed to be accessible from the outside of the wheel so they could be tightened, and that left the nuts near the motor where they were difficult to access, and trying to make the wheel hold the nuts required the wheel to be toward the motor and the collet piece on the outside, which was less aesthetically appealing.

So, in the end, we gave up on my all-plastic goal and designed a single stamped plate with threaded holes that clamps the wheel onto the collet insert. It definitely makes the assembly much easier, as you can see from this expanded view:

Having a design that seems like it might work on a 3D printed mock-up is still quite different from getting it working on the final, injection-molded parts. The clamping action of the collet inserts might have given us a little more margin for error than our usual press-fit wheels, but on those, a wrong fit is relatively straightforward to adjust: start with the fit a little on the loose side, and if it’s too loose, make the pin (and hole) smaller until it’s tight enough. With the new wheels, there were many more things that could go wrong, including alignment (wobbling). There was also the unknown of how much torque the hubs would take.

In the end, I think we arrived at a nice performance point. The wheels cannot take as much torque as if they were screwed on to the machined hub with set screw, but they can do much more than just the press fit hubs while putting less strain on the motor output shafts during installation. It’s possible to assemble the wheels with a little wobble, but if it’s a concern in your application, you can fiddle with how you tighten the three screws to get it as lined up as you like.

We started with our 80×10mm wheels, and made inserts that work with 3mm and 4mm shafts, both round and D-shaped:

Since the concept seems to be working, we will be working on different wheel sizes and inserts for larger shafts later this year.

As with all our new product introductions this year, we are having an introductory special. Be among the first 100 customers to use coupon code MULTIHUBINTRO (click to add the coupon code to your cart) and get 33% off on up to three sets.

I don’t blame you if you have no idea why the new Stability Conversion Kit for Balboa is so exciting. With a name like that, you probably couldn’t even guess what it is, let alone why it’s exciting. But let me keep you guessing while I share a little about the first robot I built, which is kind of a hint. It’s pure coincidence that I happened to get reunited with it just as we were preparing to release this new product I’m announcing here.

I know for sure that I built my first robot in eighth grade, for the science and engineering fair for which everyone in my school had to do a project, which means I must have started working on it in 1992 when I was twelve years old. The better projects in my school went on to the local, island-wide science fair in Hilo, and the better projects there went on to the state fair in Honolulu. (I was initially not among those chosen to go on from the Big Island, I think because of some judging process mistake, but my science teacher and probably others lobbied to get me there.) There was time between the different stages, so I kept working on it through the spring of 1993, which would now make it over 25 years old. I probably added the labels in later stages in response to some advice to better present what I made.

Jan’s first robot, “Robot Line Tracker,” built 1992-1993.

When Paul saw the robot for the first time in my office this morning, he immediately recognized a piece of it: “That looks like the gearbox from my first robot!” I was a bit skeptical, but he immediately backed it up by pulling out Gordon McComb’s Robot Builder’s Bonanza and showing me the project he had followed from the book. (In another amusing twist, it turns out that the copy of the book Paul had in his office is my old book, though I hadn’t gotten it until high school, and I didn’t realize until today that the gearbox in the book was the same one I had used.)

I’m pretty sure I got the gearbox from Edmund Scientific, because their printed catalogs and Radio Shack (nearest one in Kona, 40 miles away) were initially my only sources for anything electronics-related. The wheels were from some broken radio control toy. The ball caster was long a point of frustration. In earlier versions of the robot, I had tried more common swivel casters and then a ball caster I made from a ping pong ball in a toilet paper tube, but neither was very reliable. I was very happy to eventually find the metal ball caster that I used in the final version, which you can see here along with the three IR LED and phototransistor pairs used for detecting a two-inch white line on a black background:

That heavy, noisy caster was not ideal, but at least it didn’t jam at a bad angle like the swivel caster or collapse like my ping pong ball and cardboard creations. I am mentioning all these details because it was so much work just to put a basic chassis together, without even getting to the electronics part. The electronics are not something I want to cover in this blog post, but I should mention that I was very fortunate to find a mentor at the Canada-France-Hawaii Telescope headquarters right across the road from my school. CFHT had a nice electronics lab stocked with all kinds of components they just gave me and tools they let me use, and I got lots of help from John Horne when I was in 8th grade and then from many others there while I was in high school.

So, to bring this back to Pololu’s new product: the Stability Conversion Kit for Balboa is primarily a ball caster attachment for the Balboa chassis:

That might sound pretty basic, but using it fundamentally transforms the Balboa into a very different kind of robot. As a reminder, Balboa is a two-wheeled, balancing robot:

You can read more about the balancing robot in my blog post introducing the Balboa robot. It’s a very capable platform that we spent many years developing, but making a balancing robot is not easy, and it’s probably not the best type of robot to build as your first robot. We did not even release the chassis as a separate product independent of electronics because it would be difficult to do much with it. The new stability conversion kit completely changes that. With the ball caster, the chassis can be used as a much more beginner-friendly differential-drive mobile base with three points of contact with the ground:

We offer the ball caster attachment by itself, for those who want to use it with a complete Balboa 32U4 robot kit to immediately get up and running without developing their own electronics. We also now offer the Balboa Chassis with Stability Conversion Kit, which includes all the mechanical components for the chassis other than wheels and motors:

Balboa Chassis with Stability Conversion Kit (No Motors, Wheels, or Electronics).

As with the original Balboa 32U4 kit that includes electronics, we deliberately do not include motors and wheels so that you can pick your own to customize the look and performance of your robot. This diagram shows the possible chassis angles with four different wheel sizes ranging from 60 mm through 90 mm:

Variety of chassis angles available when using different wheels on the Balboa Chassis with Stability Conversion.

Micro Metal Gearmotor HPCB with extended motor shaft.

For motors, we recommend our 30:1 HPCB, 50:1 HPCB, or 75:1 HPCB micro metal gearmotors with extended back shafts that can be used with encoders. Even if you do not plan on using encoders on your robot at first, it’s nice to have the option down the road.

And options are what our chassis kits are all about, whether you select our Zumo tracked chassis, Romi round chassis, or now the new Balboa chassis. One of my guiding principles in developing our robot platforms is that I want to help you, our customers, build your robot, not just the particular one we designed.

I realize there are many kids interested in robotics who are not as fortunate as I was to have Canada-France-Hawaii Telescope headquarters across the street from my middle school, and that for many of them (and their parents and teachers), all of the options we offer can be overwhelming. Over the next several years, we will be working on sensors and other modules specifically for the Balboa, along with combination bundles and tutorials that will make Balboa a platform that students can begin with as a basic first robot in middle school and keep expanding through higher levels of their education.

I’ll end this product introduction as I have all my product announcements this year, with an introductory special to encourage you to try the Balboa chassis out for yourself. Be among the first 100 customers to use coupon code BALBOACHASSIS (click to add the coupon code to your cart) and get 15% off on Balboa-related products (limit 4 per product).

I am happy to announce that we have released version 1.2.0 of the configuration software for the Jrk G2 USB Motor Controllers with Feedback.

This release contains a large number of new features for our graphical user interface (GUI) software that let you have more information and control while you are setting up a feedback system with the Jrk.

The graph window received the most striking update: you can now use the mouse to vertically move and zoom the different plots independently of each other. You can change the colors of the plots and save your settings to a file so you don’t have to redo them the next time you start the utility. Colored indicator arrows appear at the top and/or bottom of the graph if one of the values you are plotting is too high or low to be plotted.

The variables shown in the status tab can now be moved into their own, separate window, so you can see them at all times without having to switch back to the status tab. Similarly, the “Manually set target” interface is now visible from every tab, so you can quickly test your feedback system after changing any setting. We added a “Center” button that sets the Jrk’s target to 2048, and we added a moving red dot to the target slider that shows the scaled feedback if feedback is enabled. If feedback is not enabled, the dot is green and shows the duty cycle instead.

The “Apply settings” button now has a blue background and a label to its left when it is enabled, to make it more obvious that you should apply your settings.

The main window and the variables window in the Jrk G2 Configuration Utility (version 1.2.0).

A brief history of Jrk software development

We developed the software for our original Jrk 21v3 and Jrk 12v12 controllers back in 2009. We used the C# language and the WinForms GUI API from Microsoft since that is what we were familiar with, but unfortunately those choices basically locked us into only having the software work on Windows. While you can compile and run C# code on Linux and macOS using Mono, and Mono does have an implementation of the WinForms API, that WinForms implementation was far from adequate. It worked on x86 Linux machines, crashed immediately on ARM Linux machines, and kind of ran but was totally unusable on macOS machines. I reported a few bugs to the Mono project, and the only response I got was that WinForms is no longer being developed actively. We never released Jrk software for Linux, though we did release Maestro and Simple Motor Controller software for x86 Linux using Mono. People have asked us many times over the years about running our software on a Raspberry Pi, and for our C#/WinForms GUI software we always had to tell them that it was not possible because there was no good implementation of the WinForms API for that platform.

Starting with the Wixel in 2011, we switched to using C, C++, and Qt for our configuration software. Qt is a giant cross-platform C++ library with many components. For us, the most important component is Qt Widgets, which makes it easy to develop a cross-platform GUI with the standard elements that people expect, like windows, menus, buttons, checkboxes, and text fields. There are wrappers for accessing Qt in different languages, but we chose to write our GUI software in C++ so that it can directly access Qt, and because C++ code is easier to deploy than a lot of other languages that might require a virtual machine or interpreter. Qt works well on Windows, macOS, and Linux – including on the Raspberry Pi. While we sometimes encounter bugs in Qt or overly-rigid APIs that lack important features, we are usually able to work around those issues and get a good result.

Along with C++ and Qt, we use the C language to write low-level libraries for actually talking to the USB devices. The upper layer of these libraries takes device-specific commands like “set target to 2800” and translates them into USB commands. The lower layer takes the USB commands and passes them to an appropriate USB API provided by the operating system. This is a nice way to split up the software: the device layer knows about the device but doesn’t know about the operating system, and the USB abstraction layer knows about the operating system but doesn’t know about the device.

The Wixel software developed in 2011 used its own minimal USB abstraction layer written in C. The first versions of p-load, developed in 2014 for our P-Star 25K50 Micro, did something similar. In 2015, I built on the lessons learned from these earlier projects to develop a much better USB abstraction library called libusbp. This new library has been working great for us since then, and powers all of the USB communication in the latest versions of p-load, the Pololu USB AVR Programmer v2 software, the Tic software, and the Pololu Jrk G2 software.

In 2017, I developed another piece of the stack: nixcrpkgs. The nixcrpkgs project solves the problem of reliably compiling our portable C/C++ source code into actual executables and installers that work on a variety of different systems. With nixcrpkgs, I can compile our software for Windows, macOS, and Linux (32-bit, 64-bit, and ARM) by just running a single command on one computer. It allows me to control the exact versions of all the dependencies that go into the software. I no longer have to worry about the versions of tools and libraries installed on my development machines. I also do not have to worry about the software installed on the end user’s machine: software compiled with nixcrpkgs uses static linking so all of its dependencies (except for certain things provided by the operating system) are linked directly into the executable. The download for the Jrk G2 software for the Raspberry Pi generated by nixcrpkgs is only 6 MB (compressed), and it installs just 4 files.

Prior to nixcrpkgs, we only provided binary downloads for Windows and macOS. It was difficult to produce these downloads because we relied on third-party software distribution systems like MSYS2 and Homebrew to provide binary versions of the libraries we depended on, and we didn’t have much control over those systems. We required Linux users to compile the software and its dependencies (like libusbp) themselves. Compiling software from source can be a pretty error-prone process: we strive to make our software portable, but it’s hard to test enough combinations of compiler and library versions to avoid all the issues that might come up.

The Jrk G2 software is open source and comes with build instructions for many platforms. I am hoping that this will allow people to do cool things in the future, such as translating the GUI text into their native language, adding buttons to perform custom commands, or using the code in their own software to control the Jrk. It should also provide some confidence that you will be able to use the Jrk in long-term applications and recompile the software for future operating systems.

You can download the new software from the Jrk G2 Motor Controller User’s Guide or the “Resources” tab on a Jrk G2 product page. If you need help using the software or troubleshooting your system, please post on our forum. If you have feedback or additional feature requests for the software, let us know in the comments.

LVBots held a line following competition at Pololu on May 24th. This time we had our “classic” line following course like in previous competitions, and an “advanced” course with gaps, intersections, tighter turns, and shortcuts. Continued…

I am happy to announce the release of two new stepper motor driver products, carriers for Toshiba’s TB67S249FTG and TB67S279FTG. The only difference between the two is the maximum current supported, and with operation up to 47 V, the TB67S249FTG is our highest-power stepper motor driver. Both chips offer several innovative features, including Toshiba’s Active Gain Control (AGC):

Ben and I met with some Toshiba reps at the CES show earlier this year and got to see the demo setup shown starting from around 1:45 in that video, and it looks like it could be great for many applications where the drivers and motors are inefficiently running at maximum current all the time.

The folks at Toshiba were also excited about their Advanced Dynamic Mixed Decay (ADMD) feature:

The last special feature that I’ll point out is the internal current sensing, which Toshiba calls Advanced Current Detection System (ACDS). This is not very relevant when comparing our assembled breakout boards, but if you are considering using the driver chips directly in your own design, not having to add two big current sense resistors is a big plus.

Because these stepper motor driver ICs have so many features, we made breakout boards larger than our usual small stepper driver carriers (popular on RAMPS and similar projects) so that we could fit all the necessary control pins. We are looking into the feasibility of fitting this chip into that smaller 0.6″ × 0.8″ form factor and what mix of features we would make accessible on it.

As with all of our new product announcements, we are offering an introductory discount to make it extra easy to try out these new drivers. Be among the first 100 customers to use coupon code TB67SINTRO (click to add the coupon code to your cart) and get 40% off on up to three units of each type.

We’ve released a basic VL53L1X library for Arduino to make it easier to get started using an ST VL53L1X time-of-flight distance sensor with an Arduino-compatible controller.

Because of how complex the VL53L1X is and how difficult it is to learn how it works, developing a library for it has been more of a challenge than writing one for a typical sensor like an LSM303 accelerometer/magnetometer. Continued…

Installation of our new Mycronic MY600 that arrived earlier this month is going smoothly. Here are a few pictures and a video from our first test print on a Pololu PCB panel.

Ninoos from Mycronic showing us how to use the MY600 solder paste jet printer.

First Pololu test panel in our new Mycronic MY600 solder paste jet printer.

The gantry is supported only on the left side!

First print on a Pololu PCB panel using Mycronic MY600 solder paste jet printer.

MY600 jet printer first print: Looks like we need a little more solder paste under the central chip and a little less on the leads.

That footage of the jet printer in action is not sped up!