We are now carrying the Raspberry Pi 3 Model B+. The Raspberry Pi is a popular credit card-sized computer that can run ARM Linux distributions. The Raspberry Pi 3 Model B+ has many performance improvements over the Pi 3 Model B including a faster CPU clock speed (1.4 GHz vs 1.2 GHz), increased Ethernet throughput, and dual-band WiFi. It also supports Power over Ethernet with a Power over Ethernet HAT. Continued…

Our Jrk G2 family is growing! Today we released the Jrk G2 21v3 USB Motor Controller with Feedback, which you can think of as the baby version of the new Jrk G2 motor controllers we released a few months ago or the updated version of our original Jrk 21v3. I already wrote about the history of the Jrk motor controllers in the blog post announcing the Jrk G2 motor controllers, so for today’s announcement I just want to quickly go over how small this motor controller is and how much we packed into it.

First off, this latest controller is small! Here it is next to the original Jrk 21v3:

Comparison of the newer Jrk G2 21v3 (black PCB) with the original Jrk 21v3 (green PCB).

We managed to reduce the size by more than a third, which is quite an achievement given that connectors and mounting holes already took up a pretty good portion of the board area, and we did not want to reduce those. If you looked closely at that picture above, you probably noticed that the motor driver and microcontroller are not visible on the G2, and that’s because they’re now on the back side. Here is that back side, with a quarter for scale:

Jrk G2 21v3 USB Motor Controller with Feedback, bottom view with dimensions.

Because the Jrk G2 21v3 is based on the same foundation as our bigger controllers, you get all the same convenient configurability over USB using our software utility that is available for Windows, macOS, and Linux (if you are interested, you can read more details in this post about the Jrk G2 software).

The graph window in the Jrk G2 Configuration Utility (version 1.2.0).

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

You also get all the great features and interfaces of the Jrk G2 family:

• Easy open-loop or closed-loop control of one brushed DC motor
• A variety of control interfaces:
  • USB for direct connection to a computer
  • TTL serial operating at 5 V for use with a microcontroller
  • I²C for use with a microcontroller
  • RC hobby servo pulses for use in an RC system
  • Analog voltage for use with a potentiometer or analog joystick
• Feedback options:
  • Analog voltage (0 V to 5 V), for making a closed-loop servo system
  • Frequency, for closed-loop speed control using pulse counting (for higher-frequency feedback) or pulse timing (for lower-frequency feedback)
  • None, for open-loop speed control
  • Note: the Jrk does not support using quadrature encoders for position control
• Ultrasonic 20 kHz PWM for quieter operation (can be configured to use 5 kHz instead)
• Simple configuration and calibration over USB with free configuration software utility (for Windows, Linux, and macOS)
• Configurable parameters include:
  • PID period and PID coefficients (feedback tuning parameters)
  • Maximum current
  • Maximum duty cycle
  • Maximum acceleration and deceleration
  • Error response
  • Input calibration (learning) for analog and RC control
• Optional CRC error detection eliminates communication errors caused by noise or software faults
• Reversed-power protection
• Field-upgradeable firmware
• Optional feedback potentiometer disconnect detection

Here is a quick comparison of the different Jrk versions, including the original ones that we do not recommend for new designs:

No new product announcement this year would be complete without our introductory special: be among the first 100 customers to use coupon code JRKG2INTRO and get up to three Jrk G2 motor controllers for 40% off. This coupon is good for the whole family, so you can use it for the 21v3 version we released today or for the larger units released earlier this year.

I am excited to share the second Pololu product for which I routed the PCB, the Dual TB9051FTG Motor Driver for Raspberry Pi. This board complements the TB9051FTG Single Brushed DC Motor Driver Carrier and the recently announced Dual TB9051FTG Motor Driver Shield for Arduino by making it easy to control two motors with a Raspberry Pi (Model B+ or newer).

The TB9051FTG can deliver a few amps across a wide operating voltage (4.5 to 28 V), which makes this expansion board ideal for controlling two small or medium size motors in your Raspberry Pi project. You can optionally connect a voltage regulator, like a D24V10F5 or D24V22F5 step down regulator, to power the Raspberry Pi with your motor power supply. The board also provides a prototyping area to help you construct clean custom circuits without the need for additional prototyping PCBs beyond the footprint of your Raspberry Pi.

The Dual TB9051FTG Motor Driver for Raspberry Pi is available in two versions:

• a partial kit, with connectors included but not soldered in
• fully assembled, with the female header and terminal blocks soldered to the board

The board adheres to the Raspberry Pi HAT (Hardware Attached on Top) mechanical specification, although it does not conform to the full HAT specifications due to the lack of an ID EEPROM. (A footprint for adding your own EEPROM is available for applications where one would be useful.)

With the addition of this product, we now have eight Raspberry Pi motor driver expansion boards for you to choose from. To control more powerful motors, we offer various high-power motor drivers for Raspberry Pi. If you don’t need all the power provided by the TB9051FTG, consider our small and inexpensive DRV8835 Dual Motor Driver for Raspberry Pi or the dual MAX14870 motor driver expansion board (the first board I routed).

We have an introductory discount to go with this new product announcement. The first 100 customers to use coupon code RPITB9051INTRO can get up to two units for just $10.95 each. Note that this introductory offer applies only to the units without connectors soldered in. The introductory coupons for the single TB9051FTG carrier, the dual TB9051FTG Arduino shield, and some other products introduced this year are still available; you can see all the coupons available on our specials page.

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…