Author Archives: david

New products: Addressable RGB LED strips based on the SK6812

via Pololu Blog

We are now selling new addressable RGB LED strips based on the SK6812. These LED strips replace our older WS2812B LED strips. Like the WS2812B, the SK6812 is an RGB LED with an integrated driver that allows independent control over a chain of LEDs using just one I/O line. The main difference between the two drivers is that the SK6812 has constant current control capabilities that let it have a voltage-independent color and brightness over a wide range of voltages, so any voltage drop due to long power lines is less of a concern.

LED side of the SK6812-based addressable LED strips, showing 30 LEDs/m (top), 60 LEDs/m (middle), and 144 LEDs/m (bottom).

We offer six different kinds of SK6812 LED strip with different LED densities and lengths. Our strips with 30 LEDs per meter are available in three lengths:

We also offer denser SK6812 LED strips that have 60 LEDs per meter:

Our highest density strip has 144 LEDs per meter:

We provide LED strip example code for the Arduino, AVR, and mbed microcontroller platforms. More information about the LED strips and how to use them can be found on the LED strip product page.

Controlling an addressable RGB LED strip with an Arduino and powering it from a 5V wall power adapter.

New products: APA102C-based addressable RGB LED panels

via Pololu Blog

New products: APA102C-based addressable RGB LED panels

We’re excited to offer a series of APA102C-based addressable RGB LED panels, which make it easy to add colorful images, text, or lighting effects to your project. These panels use the same integrated APA102C LED driver as our APA102C-based addressable RGB LED strips, which means that you can control the LEDs using a standard SPI interface that works over a wide range of communication rates.

We offer APA102C LED panels in three different sizes:

For more information about our APA102C-based LED panels, including links to example code, see their product pages.

Addressable RGB 8×32-LED Flexible Panel, 5V, 10mm Grid (APA102C) showing an animated rainbow.

An addressable RGB 16×16-LED panel with a plastic diffuser (not included) showing the Pololu logo.

New product: Pololu USB AVR Programmer v2

via Pololu Blog

New product: Pololu USB AVR Programmer v2

I am excited to announce the release of the Pololu USB AVR Programmer v2, a programmer for the popular AVR microcontrollers from Atmel.

Here at Pololu, we have been making AVR programmers for over eight years in order to support products like our Orangutan robot controllers and the 3pi robot. These programmers are used to transfer a compiled AVR program from your computer to the target AVR’s flash memory, allowing it to run the program.

From left to right: the original Orangutan USB Programmer, the Pololu USB AVR Programmer, and the Pololu USB AVR Programmer v2.

The new Pololu USB AVR Programmer v2 is our third-generation AVR programmer. It is an updated version of our Pololu USB AVR Programmer (product #1300) with many improvements and changes.

To support programming AVR microcontrollers running at 3.3 V, we added an adjustable voltage regulator that allows the programmer to set its own power voltage to either 3.3 V or 5 V. By default, the programmer will operate at 3.3 V, but it measures the voltage on its VCC pin and will automatically switch to 5 V if it detects a high-enough voltage on VCC. You can also disable the automatic switching and just set the programmer to always be 3.3 V or always be 5 V using our configuration software.

With the Pololu USB AVR Programmer v2, we made an effort to increase the programming speed for commonly-used types of AVRs, such as the ATmega328P. With the older Pololu USB AVR Programmer, if you wanted to program all 32 KB of the AVR’s flash memory, it would take about 6.8 s using the maximum ISP frequency of 2 MHz. With the Pololu USB AVR Programmer v2, it takes only about 4.8 s to do the same thing. Also, if your ATmega328P has a high-enough clock speed, you can increase the ISP frequency to 3 MHz and then it would only take 4.3 s. (These numbers are from tests done using AVRDUDE 6.2 in Windows.)

The Pololu USB AVR Programmer v2 has 470 Ω resistors on all of its I/O lines, which will help protect the programmer and your target system from damage in case there is a voltage mismatch or a short circuit.

Programming the fuse bits on an AVR has always been scary because you can accidentally program the wrong clock settings and brick your AVR. With the new Pololu USB AVR Programmer v2, it is a little less scary: the programmer provides a 100 kHz clock output that can be used to send a clock signal to your AVR, which can help you revive it when it has the wrong clock settings. We tested this on the ATmega328P and it probably works on many other AVRs as well. You should still be careful when setting the fuse bits though!

Like its predecessor, the Pololu USB AVR Programmer v2 can act as a USB-to-TTL serial adapter, so you can use it to debug or communicate with your projects over serial. We arranged the serial pins in a more standard arrangement that is similar to commonly-available FTDI USB-to-serial cables and breakout boards. The pins also come with a female header soldered in, so you can plug the programmer directly into a variety of Arduino boards and use it upload sketches via a serial bootloader.

The Pololu USB AVR Programmer v2 is compatible with commonly-used AVR programming software such as Atmel Studio, AVRDUDE, and the Arduino software (IDE).

You can use our open source configuration software for Windows, Linux, and Mac OS X, to change the configuration of your programmer and see useful information about it. We provide both a graphical user interface (GUI) and a command-line interface (CLI). Here is a screenshot of the GUI in Windows:

The Pololu USB AVR Programmer v2 Configuration Utility in Windows 10.

The Pololu USB AVR Programmer v2 uses a relatively new PIC microcontroller, the PIC1825K50. We sell a user-programmable break-out board for this microcontroller called the P-Star 25K50 Micro. One of the exciting features of this microcontroller is that it can do full-speed USB without needing an external crystal or resonator. The USB specification requires devices to have a clock that is accurate to within ±0.25%. On previous products, we usually had to add an external resonator or crystal to the board to meet this requirement. However, the PIC18F25K50 has a neat feature called Active Clock Tuning, which means that it can automatically tune its internal oscillator by monitoring the timing of the USB signals from the computer. This allows the internal oscillator, which is normally not very accurate, to achieve the accuracy needed for USB. This feature allowed us to make the programmer a little smaller and a little less expensive.

For more information, see the Pololu USB AVR Programmer v2 product page.

Sumo ring border angle detection

via Pololu Blog

My robot from the last LVBots mini-sumo competition has a feature which I think is pretty interesting and sets it apart from a lot of other robots: when it detects the border of the sumo ring, it measures the angle of the border and uses that information to try to get to the center.

The name of my robot is Zumo Red, and it is a Zumo 32U4 Robot Kit with 75:1 HP micro metal gearmotors. Zumo Red has special red sprockets and a red LED holder, but other than that it is just a normal Zumo 32U4 with integrated encoders, line sensors, and a gyro, which were all useful for finding the center of the ring.

Zumo Red, a Zumo 32U4 with red sprockets and a red LED holder.

My idea was that the center of the ring is the farthest spot from the edge, so it is the safest spot to be in, and my robot should try to get there. You can see an example of this behavior in the video of Zumo Red vs. Sumo Neko. After pushing its opponent out of the ring, Zumo Red measured the angle of the border, drove to a spot near the center of the sumo ring, and started scanning for opponents again.

The rest of this post explains the principles I used to measure the angle of the border.

Let’s start by sketching out the basic situation. The diagram below shows the sumo ring and a robot inside it. The three red dots represent downward-facing line sensors that are used to detect the white border of the ring. The main purpose of these sensors is to allow the robot to know when it is about to drive out of the ring, allowing it to turn around and save itself. We’ll assume that the robot has an identifiable front side that is usually facing towards the direction of motion whenever the robot is driving. We’ll assume that the line sensors are near the front side, and arranged in a line that is parallel to the front side.

Diagram showing a Mini Sumo ring and and robot. The red dots represent downward-facing line sensors on the front of the robot that are used to detect the border.

We need to get an understanding of all the different ways the robot could be oriented when it starts detecting the border with its sensors. The picture below shows some example orientations for the robot.

Some possible positions a robot can be in when it senses the border of the sumo ring.

The angle that the robot is facing does not matter, because the sumo ring has rotational symmetry. In other words, every border-detection scenario can simply be rotated until the robot is facing towards the top of the diagram without changing anything important. Therefore, we can just consider the cases where the robot is facing towards the top of the diagram and forget the other cases, which makes our job a lot easier.

We will also assume that the robot is driving straight forward. If it is driving in reverse, driving along a curve, or getting pushed by another robot, the technique presented here for measuring the angle will probably not work. Since it is driving towards the top of the diagram and starts inside the ring, there is no way for sensors to detect the lower half of the border. The robot is going to drive forward and sense some part of the upper half of the border.

If the leftmost sensor sees the border first before any of the other sensors do, the robot will know that it is in the upper-left quadrant of the diagram above, like positions 1 and 2. If the rightmost sensor sees the border first, the robot will know it is in the upper-right quadrant, like positions 4, 5, and 6. If the robot is in position 3, where both sensors detect the border at nearly the same time, the robot could decide it is in either quadrant, and that is okay. Because the interior of the sumo ring is concave, the first sensor to see the border will usually be the leftmost or rightmost sensor; it would be unusual for an inner sensor to see the border first.

Therefore, as soon as the robot sees the border with a sensor, it knows what quadrant it is in, and it can use that information to decide which direction to turn. This is what our simple BorderDetect example for the Zumo 32U4 does. It knows what quadrant it is in, but beyond that it does not know where it is.

This close-up diagram shows the situation when the rightmost sensor detects the border:

The right triangle that is formed when a sumo robot first senses the white border with its right-most sensor.

A right triangle is formed with perpendicular sides a and b, as shown in the picture above. We can use trigonometry to find the angle θ (theta). By the definition of the tangent function, the tangent of θ is equal to a divided by b. Therefore, a formula we can use to calculate θ is:

``θ = arctan(a / b)``

If you are programming your robot in C or C++, you can use atan, a function from the C standard library, to compute the arctangent.

The value of a can be measured with the robot’s encoders. The robot can drive forward until the middle sensor detects the border and measure how much distance it traveled to get there.

The value of b is just the distance between the two sensors involved, so it is a constant property of the robot that should be entered into your code ahead of time. The value of b can be calculated by measuring the distance between the two sensors. However, you should make sure that the value of b in your code uses the same units as the value of a, or else you will not get the correct ratio when you divide them. Since a comes from the encoders, converting b into the same units involves knowing the number of encoder counts per motor revolution and the diameter of your robot’s tires/treads. Instead of calculating or looking up those numbers, I think the easy way to get b is to take some measurements of a and θ and pick a value for b that fits your data. That’s what I did for Zumo Red: I made it to drive forward to the border, measure a, and stop moving. Then I used its gyro to measure θ as I manually turned it towards the center. I repeated this process several times at different locations on the ring. Collecting this data and plotting it gave me confidence that my procedure for measuring the angle would actually work, and it helped me determine the value of b.

Once the robot has computed θ, it can calculate the angle it needs to turn to face towards the center, φ, with this formula:

``φ = 180° – θ``

The robot can use either a gyro or its encoders to perform a measured turn towards the center. The Zumo 32U4 has an integrated gyro, so that’s what I used in my robot. However, encoders would probably work too if your robot does not have a gyro.

If you would like to see a working code base that integrates the techniques discussed here, you can check out the code in my zumo-red repository on GitHub. That code is designed to run on a Zumo 32U4 with 75:1 HP motors, so you should be able to get the code working without writing any code of your own.

Zumo Red ended up tying for 7th place in the LVBots contest (which had 18 robots). It won against Venom, lost to Dkunrtakd, won against Sumo Neko, won against Covert Ops, and finally got knocked out of the tournament by Brandon’s Black Mamba. I didn’t add any extra weight to Zumo Red, so it weighed only 273 g, which is probably why it only succeeded in pushing robots out of the ring when it was lucky enough to get at them from the side or rear. If I had gotten the weight closer to the 500 g limit, it might have been able to push some robots out the ring head-on and get a better ranking.

If you make a robot that measures the angle of a sumo ring or does something similar, please let us know your results in the comments!

New support for Atmel Studio 7.0 and Windows 10

via Pololu Blog

New support for Atmel Studio 7.0 and Windows 10

We now support using the Orangutan Robot Controllers, 3pi robot, and the Pololu USB AVR Programmer with the new Atmel Studio 7.0 and Windows 10.

To make this possible, we updated the Windows installers for the Pololu AVR C/C++ Library to support Atmel Studio 7.0. This means that when you install the library on Windows, it will automatically copy its files into the AVR GCC toolchain inside Atmel Studio 7.0 and install project templates for the supported devices. Adding support for Atmel Studio 7.0 required us to add some code to detect its location and fix two unexpected problems. You can see the changes that were made in the libpololu-avr commit history on GitHub.

The second screen of the Pololu AVR C/C++ Library installer for Windows.

We also tested the library installer, Atmel Studio 7, the Pololu USB AVR Programmer, and the Orangutan SVP on Windows 10. Everything worked fine, so we now support using those products on Windows 10.

Importing an Arduino sketch in Atmel Studio 7.0

Atmel Studio 7.0 is the latest version of Atmel Studio, an integrated development environment (IDE) for AVRs from Atmel. It has an interesting new feature that allows you to create a new project from an Arduino sketch. The idea is that you could import an Arduino sketch, compile it with Atmel Studio, and then load it onto an Arduino-compatible board using a debugger from Atmel. This would allow you to step through the program one line at a time as it runs on real hardware and see what the program does at each step. It would also allow you to use the advanced code editing features of Atmel Studio. When you import a sketch into Atmel Studio 7.0, the source code of your sketch, along with the Arduino core source code and the code for any libraries you are using, gets copied into the directory for the new project.

However, the new feature only supports a certain small set of boards from Arduino and Adafruit, which means that you would have to select a board similar to your Orangutan, 3pi robot, or A-Star and then adjust the project settings (such as the F_CPU clock speed macro) to make it work. Atmel Studio does not support Arduino bootloaders, so it will not be easy to program an A-Star without getting an external programmer. Our Pololu USB AVR Programmer does not support debugging, so if that is the only programmer you have, then there is relatively little value in using Atmel Studio to program your device instead of just using the Arduino IDE. The feature does not appear to be very polished and still has bugs, which I encountered when I tried to import a sketch that has multiple .h and .cpp files.

If you want to try out the new feature, just open Atmel Studio 7.0, select File > New > Project…, and then select “Create Project from Arduino sketch”, which is a template that can be found in the “C/C++” category.

Wixel software now works on the Raspberry Pi

via Pololu Blog

Wixel software now works on the Raspberry Pi

We have released a new build of the software for our Wixel Programmable USB Wireless Module that works on ARM Linux systems like the Raspberry Pi. This means that you can now upload apps to a Wixel from a Raspberry Pi, without needing a typical desktop computer. You can find the software download in the Wixel User’s Guide.

We have seen people use Wixels to help monitor blood glucose levels, create wireless quiz buttons, or wirelessly control servos. For a complete list of all the Wixel apps we know about, see the Wixel Apps list on our forum. We hope that the expanded software support for the Wixel will help people create new applications in the future.

Wixel programmable USB wireless module.