Author Archives: kevin

New product: Motoron M3H256 Triple Motor Controller for Raspberry Pi

via Pololu Blog

Our Motoron M3H256 Triple Motor Controller for Raspberry Pi is now available! The M3H256 is a stackable I²C motor controller that can drive up to three brushed DC motors bidirectionally at voltages between 4.5 V and 48 V and continuous currents up to 2 A per channel. Unlike its M3S256 sibling, which is designed as a shield for an Arduino, the Motoron M3H256 is intended to stack on top of a Raspberry Pi (Model B+ or newer), similar to a HAT (Hardware Attached on Top). With an I²C address that can be configured uniquely for each board, a stack of Motorons let you control many motors at once without taking up lots of GPIO pins and PWM outputs from the Pi.

A robot with three omni wheels and motors controlled by a Raspberry Pi with a Motoron M3H256 Triple Motor Controller. A D24V22F5 regulator powers the Raspberry Pi.

If you decide not to plug it into a Raspberry Pi, the Motoron M3H256 can also be used in a breadboard or another custom setup with your own wiring:

An Arduino Micro on a breadboard using a Motoron M3H256 to control three motors.

Motoron M3H256 Triple Motor Controller for Raspberry Pi pinout.

The Motoron M3H256 is available in three different configurations similar to its Arduino shield counterpart: you can get one fully assembled with stackable headers and terminal blocks already soldered, a kit that lets you pick which of the included connectors to solder in yourself, or the board alone if you already have or don’t need connectors and standoffs.

And to help you get started using the Motoron with a Raspberry Pi, we have a Python library you can use to configure the M3H256 and send it commands:

import motoron

mc1 = motoron.MotoronI2C(address=17)
mc2 = motoron.MotoronI2C(address=18)

# Clear reset flags to allow Motorons to run
mc1.clear_reset_flag()
mc2.clear_reset_flag()

# Set up acceleration limits for Motoron #1
mc1.set_max_acceleration(1, 200)
mc1.set_max_acceleration(2, 200)

# Set up acceleration and deceleration limits for Motoron #2
mc2.set_max_acceleration(1, 75)
mc2.set_max_deceleration(1, 250)
mc2.set_max_acceleration(2, 80)
mc2.set_max_deceleration(2, 300)
mc2.set_max_acceleration(3, 75)
mc2.set_max_deceleration(3, 250)

# Drive the motors

mc1.set_speed(1, -100)
mc1.set_speed(2, 100)

mc2.set_speed(1, 300)
mc2.set_speed(2, 200)
mc2.set_speed(3, 50)

We’re sure there are plenty of applications where the convenience and scalability of Motorons will be useful. What kind of projects can you think of that would make good use of one (or several)?

For more information about the Motoron M3H256, see the product pages and the comprehensive user’s guide.

New product: VL53L5CX Time-of-Flight 8×8-Zone Distance Sensor Carrier

via Pololu Blog

I’m excited to announce the release of our new VL53L5CX Time-of-Flight 8×8-Zone Distance Sensor Carrier! Over the past several years, STMicroelectronics has introduced a number of FlightSense distance sensors, starting with the VL6180X, that use time-of-flight (TOF) measurements of infrared laser light to measure distances. Each new sensor has been more capable than the last (usually offering an increased range), but the VL53L5CX is more than just another incremental upgrade. What makes the VL53L5CX really special is its ability to take readings of multiple targets across a grid of multiple zones, allowing you to generate a depth map with up to 8×8 resolution and 4 m range.

A plot of a coffee cup as detected by a VL53L5CX time-of-flight 8×8-zone distance sensor.

Compared to sensors that only give a 1D measurement, the VL53L5CX does demand more from a microcontroller to support its operation as a 3D lidar. Initializing the sensor through I²C and processing its data requires a lot of RAM and program memory, so it is not practical to use the VL53L5CX with most 8-bit MCUs like the Arduino Uno. (The same was true for the VL53L3CX, which shares the VL53L5CX’s multi-target capability but does not have multi-zone capability.) We found that the Raspberry Pi Pico’s RP2040 microcontroller worked well for interfacing with the VL53L5CX, and other similarly powerful 32-bit controllers like an ESP32 should also work.

It’s fun to compare our VL53L5CX carrier with our other ST time-of-flight sensor boards because even though the boards are the same size (and pin-compatible), the VL53L5CX component itself is significantly bigger than its predecessors. We also switched from using 0603-size surface-mount resistors (0.06″ × 0.03″, or 1.5 mm × 0.8 mm) to 0402-size parts (1 mm × 0.5 mm) to help everything fit in the same form factor, and that makes for even more contrast with the large IC. As we refine our manufacturing abilities to let us work with more challenging parts like these, it’s nice to have more options for making things even more compact. (When can we try some 0201 parts?)

New products: DRV8874 and DRV8876 motor driver carriers

via Pololu Blog

We’ve expanded our selection of motor drivers again with the release of some compact carrier boards for TI’s DRV8874 and DRV8876 motor drivers, which feature current sense feedback and adjustable current limiting. These three ICs and their boards are all very similar, differing mainly by the amount of current they can handle: in a TSSOP chip package, the DRV8874 delivers up to 2.1 A continuous on our carrier board and the DRV8876 does 1.3 A. The DRV8876 chip is also available in a smaller QFN package, so for a lower-current and lower-cost option, our DRV8876 (QFN) carrier can deliver 1.1 A continuously. All three versions can drive a single brushed DC motor at voltages from 4.5 V to 37 V.

DRV8874 Single Brushed DC Motor Driver Carrier (top view).

DRV8876 Single Brushed DC Motor Driver Carrier (top view).

DRV8876 (QFN) Single Brushed DC Motor Driver Carrier (top view).

The DRV8874 and DRV8876 drivers offer a choice of control modes that includes phase/enable (PH/EN) and direct PWM (IN/IN) as well as independent half-bridge control, which lets you drive two motors unidirectionally. With their wide operating voltage range and current sense/current limiting added in, this combination of capabilities results in some unusually versatile motor driver boards, especially considering their small size. (But if you need something that works with even higher voltages, consider our similar DRV8256E and DRV8256P carrier boards too, though those don’t provide current sense feedback.)

Comparison of the DRV8874, DRV8876, and DRV8256 motor driver carriers

DRV8876 (QFN)

DRV8876

DRV8874

DRV8256E
DRV8256P
Motor channels: one
Min. operating voltage: 4.5 V
Max. operating voltage: 37 V 48 V
Max. continuous current(1): 1.1 A 1.3 A 2.1 A 1.9 A
Peak current: 3.5 A 6 A 6.4 A
Current sense feedback? 2500 mV/A 1100 mV/A none
Active current limiting: adjustable
Size: 0.6″ × 0.7″ 0.6″ × 0.6″
1-piece price: $5.95 $6.95 $9.95 $12.95 (E)
$12.95 (P)
1 On Pololu carrier board, at room temperature and without additional cooling.

New product: Motoron M3S256 Triple Motor Controller Shield

via Pololu Blog

We’re excited to announce the launch of our new Motoron M3S256 Triple Motor Controller Shield! This I²C motor controller is designed to plug into an Arduino or Arduino-compatible board and control up to three bidirectional brushed DC motors at voltages from 4.5 V to 48 V with continuous currents of up to 2 A per channel. However, what really sets the Motoron apart from our other motor shields is that you can easily stack multiple boards to control even more motors at once!

Unlike basic motor driver shields that are best for driving just a few channels using the Arduino’s hardware PWM outputs, the Motoron M3S256 has its own on-board microcontroller with an I²C interface, letting you communicate with a stack of many controllers using only two I/O lines. Each Motoron can be configured to have a unique I²C target address, ensuring that every shield can be addressed individually and every motor can be controlled independently. For synchronized motion, you can even signal all the motors on several controllers to change speed at the same time with a single I²C command.

We provide an Arduino library for the Motoron that makes it easy to send it commands and configure its many settings, including motion parameters and error handling options. Working with multiple Motoron controllers is as simple as calling a few functions once you have set up their I²C addresses:

// Set up acceleration and deceleration limits for Motoron #1
mc1.setMaxAcceleration(1, 80);
mc1.setMaxDeceleration(1, 300);
mc1.setMaxAcceleration(3, 50);

// Set up acceleration and deceleration limits for Motoron #2
mc2.setMaxAcceleration(2, 50);
mc2.setMaxDeceleration(2, 200);
 
// Drive the motors
 
mc1.setSpeed(1, -800);
mc1.setSpeed(2, 100);
mc1.setSpeed(3, -100);
 
mc2.setSpeed(1, -400);
mc2.setSpeed(2, 50);
mc2.setSpeed(3, 300);

Alternatively, if you are not using a microcontroller board with the standard Arduino form factor, it is almost as easy to use the Motoron on a breadboard.

A Raspberry Pi Pico on a breadboard using a Motoron M3S256 shield to control three motors.

The Motoron M3S256 is available in three versions with different connector options:

Motoron M3S256 Triple Motor Controller Shield for Arduino (Connectors Soldered).

Motoron M3S256 Triple Motor Controller Shield Kit for Arduino.

Motoron M3S256 Triple Motor Controller Shield for Arduino (No Connectors).

You might wonder why the assembled version comes with 3.5mm-pitch terminal blocks soldered in when the through-holes are spaced 5 mm apart. The answer is that the smaller 3.5 mm terminal blocks allow for more clearance when the shields are stacked, reducing the risk of shorting them to each other, but we still designed the board with bigger holes and wider spacing for maximum flexibility.

For more information about the Motoron M3S256, see the product pages and the comprehensive user’s guide. We have plans to expand the Motoron family with more versions including Raspberry Pi-compatible form factors and higher-power models, so expect more announcements soon!

The Zumo gets a graphical display too: new Zumo 32U4 OLED Robot!

via Pololu Blog

Our 3pi+ 32U4 robot got an upgraded OLED display earlier this year, and now it’s the Zumo’s turn with the release of our new Zumo 32U4 OLED Robot!

In many ways, this new version is just like the original Zumo 32U4: it’s a versatile tracked robot designed to be a capable Mini-Sumo competitor, but with enough sensors and extra features to enable lots of other applications. The Zumo 32U4 OLED adds to that versatility by replacing the original LCD (liquid crystal display) with a high-contrast graphical OLED display. With this monochrome 128×64 screen, you can present high-density data displays to help you analyze the Zumo’s status and sensor readings, or you can add some flair to your Zumo by showing eye-catching graphics.

We’ve updated our Arduino library for the Zumo 32U4 to add OLED display support as well as an LCD compatibility layer (the same way we did for the 3pi+), letting you easily convert existing programs to run on the OLED version or write new programs that will work on both old and new robots.

As with the LCD version, the new Zumo 32U4 OLED robot is available as a kit (with motors not included so you can select your own to customize performance) or as a fully assembled robot with your choice of 50:1, 75:1, or 100:1 motor options

Assembled Zumo 32U4 robot.

Assembled Zumo 32U4 OLED robot.

New products: DRV8256E/P motor driver carriers

via Pololu Blog

We’re pleased to announce our inaugural products based on the DRV8256E and DRV8256P motor drivers from Texas Instruments, which we are especially excited about. These little carrier boards can deliver a continuous 1.9 A to a single brushed DC motor at voltages from 4.5 V to 48 V, so they have some of the broadest operating ranges of any of our drivers, and they can handle short bursts of considerably higher current (up to 6.4 A for less than a second). They also feature configurable active current limiting, which can help make them good choices for a motor that might only draw around an amp when running but much more when starting.

The DRV8256E and DRV8256P are very similar, and we use the same printed circuit board for both chips, but their control interfaces are different. The E version provides a phase/enable interface that lets you control a motor with a single PWM speed signal along with a simple digital direction signal, while the P version provides an IN/IN interface that gives you direct control over the motor outputs but requires two PWM signals for bidirectional speed control.

However, there is also a tradeoff with these two ICs. The DRV8256P uses drive/brake operation, shorting the motor outputs together and electrically braking the motor during the off portion. Many other TI drivers with phase/enable interfaces (like the DRV8838) also use drive/brake, but the DRV8256E does not: it operates in drive/coast mode, where the motor outputs are high impedance during the off portion of the PWM cycle, allowing the motors to coast. We don’t know why TI made a different decision for the DRV8256E, but it seems likely they have some high-volume customers who prefer it this way.

In our experience, drive/brake mode provides a much more linear relationship between PWM duty cycle and motor speed, so for an application where that is important, you might choose to accept the need for an additional PWM signal to get that improved linearity. These graphs show the difference in one specific scenario (powering a high-power micro metal gearmotor with no load):

However, graphing the relationship between duty cycle and the current drawn by the motor driver from the supply reveals some more interesting differences. Specifically, at lower PWM frequencies, drive/brake operation uses much more current at intermediate duty cycles as the motor current ramps up and down for each PWM cycle:

Finally, graphing current draw against motor speed shows that drive/coast can be more efficient for a given speed compared to drive/brake. So for an application with closed-loop speed control where it’s not as important for duty cycle to correspond linearly with speed, using drive/coast might be preferable if the PWM frequency is low.

If you have any thoughts about drive/brake vs. drive/coast and their use in different applications, we would be interested in hearing about it.

For more information about these drivers, see their product pages: