We’re excited to offer a series of addressable LED strips and addressable LED panels based on the new SK9822 integrated circuit. Like the APA102C, the SK9822 combines an RGB LED and driver into a single 5050-size package, allowing each pixel to be individually controlled using a simple two-wire SPI protocol.
The SK9822 is almost (see the notes below) a drop-in replacement for the APA102C and is better than it in a few ways, most importantly its built-in constant current control. If you’ve ever tried to power a long chain of LED strips and only connected power at one end, you might have noticed that the far end of the LED strip has a lower voltage across its power rails because of resistance in the long power connections. For LED strips based on the APA102C and WS2812B, the lower voltage makes the light dimmer and redder. With the SK9822, voltage drops like that are less likely to have a visible effect as long as the voltage stays above 3.5 V.
The SK9822’s protocol is very similar to that of the APA102C, but it updates the color that is being shown at a different time. If you replace APA102C LEDs with SK9822 LEDs in a low frame-rate application, you might have to update the code you are using to control the LEDs. The latest version of our APA102 Arduino library works with the SK9822 so you can either use it directly or use it as a reference when writing your own code. The colors generated by the SK9822 look different from the colors generated by the APA102C, so we would not recommend mixing the APA102C and the SK9822 in a single project.
We offer six different kinds of SK9822 LED strip with different LED densities and lengths:
One of the main features of the kit is that it provides a backlit 2×20 character LCD to replace the receiver’s original 5-digit 7-segment display, allowing much more information to be shown. The kit includes a clear plastic window to replace the receiver’s original smoked dark plastic window, and a black plastic display mask. Edward gets both of these pieces made using our custom laser-cutting service.
Two laser-cut pieces, a clear window and black display mask, shown on top of the Ten-Tec 1254 receiver’s original face plate.
Ten-Tec 1254 receiver with Edward Cholakian’s display upgrade kit installed.
The display/control board in the kit uses the P-Star 25K50 Micro as its processor. Edward, a consulting engineer who designs embedded hardware and firmware, told us that he chose the P-Star because he was already using a Microchip processor similar to the P-Star’s PIC18F25K50 in one of his previous designs, and it was more economical to buy the P-Star than to hand-assemble his own board. He said the P-Star’s cross-platform USB firmware upgrade software was also a plus since his own bootloading software does not support Linux and macOS.
The kit comes with software for Windows that can control the receiver over USB. The software provides a graphical user interface and uses WinUSB to talk to the P-Star’s native USB interface.
USB control program for the Ten-Tec 1254 Receiver Display Upgrade Kit
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:
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.
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.
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’sBlack 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!