Posts tagged “arduino” (Page 2)
You are currently viewing a selection of posts from the Pololu Blog. You can also view all the posts.
Julien de la Bruère-Terreault (also known as DrGFreeman on the Pololu Forum, creator of the Custom Mini Sumo robot and the Romi and Raspberry Pi robot shared on this blog) made “SharpDistSensor” an Arduino library for analog Sharp distance sensors. If you’re running a recent version of the Arduino IDE, you can install it with the Library Manager. The library reads the sensor’s analog voltage output, filters the data, and converts it to a distance measurement. By default it is calibrated to work with the Sharp GP2Y0A60SZLF analog distance sensor 10-150cm 5V, but you can calibrate it to other analog Sharp distance sensors (if you can fit a power function or a fifth order polynomial to the voltage vs distance response of your sensor). Pull requests are welcome for supporting other Sharp distance sensor models!
The readme, library code, and example sketches are available in the GitHub repository.
This is the third post in a series about how to make a Balboa 32U4 robot balance. Last week I talked about inertial sensors, especially the gyro. In this post I will talk about the Balboa’s built-in encoders, which allow accurate measurements of motor speed and distance.
To get your Balboa to balance, you will soon need to create a balancing algorithm, a program that takes sensor input and computes the appropriate motor speed settings to keep the robot upright. So far our only inputs, both from the gyro, are the rate of rotation and current angle of the robot. These are not quite enough to make a good balancer. To see why, suppose that your program tries to balance by holding the angle at a constant 90°. If your definition of 90° is even slightly off-balance, the robot will need to keep accelerating, driving faster and faster to maintain it, until it reaches top speed or hits an obstacle. You might be able to account for this by using the motor output settings themselves as an input to your algorithm, but this is difficult, especially at the low speeds used for balancing. Also, even if you can avoid accelerating, your robot will gradually drift in one direction or the other. The Balboa’s encoders are valuable additional sensor inputs that allow you to measure how fast the wheels are actually turning, so you can directly control acceleration and drift. As a bonus, encoders are great for driving straight, precision turns, and navigation. Continued…
This is the second post in a series about how to make a Balboa 32U4 robot balance. Last week I talked about selecting mechanical components. In this post I will cover the inertial sensors included on the Balboa’s control board and how to use them in your code.
The key to Balboa’s balancing ability is the built-in ST LSM6DS33 IMU chip, which combines a 3D gyroscope and a 3D accelerometer. The Balboa also includes an ST LIS3MDL 3-axis magnetometer. Both sensors are connected to the AVR via I²C, giving it access to a total of nine sensor channels. These nine channels can be used in software to make an AHRS (attitude and heading reference system), a system that gives the robot a sense of its orientation in three dimensions. AHRS software is particularly important in aviation/drone applications, but for basic balancing, you don’t need anything that complicated. In fact, a single gyro channel is enough to determine the robot’s angle of rotation relative to vertical. The gyroscope’s y-axis channel measures the Balboa’s forward/backward rate of rotation; that is the channel we will be looking at here. Continued…
I am excited to announce the release of the Balboa robot! The Balboa is a two-wheeled balancing robot platform that is small enough to tempt you to run it on a desktop, but it’s quick enough that you should probably stick to bigger, softer surfaces. Or at least put a safety net or foam pit around your desk. Here is a short video showing it kicking up into balancing position and driving around:
A look inside the external gearbox on the Balboa 32U4 Balancing Robot.
One of our main goals in designing our robots is to make them complete and engaging on their own while making them open and expandable enough for all kinds of projects. We also don’t want them all to be the same. Most of the Balboa robots in our pictures have 80 mm wheels, but the chassis can also work with our 90 mm wheels (and to a lesser, barely practical extent, our 70 mm wheels). Because the chassis is made for our micro metal gearmotors, you have a few options for gear ratios as with our Zumo sumo robots, but what’s really exciting about the Balboa design is that there is an extra stage of gear reduction for which you get five different options (all included, and you can easily change the gear ratio from whatever you initially choose). The design also allows the drive wheels to be supported on ball bearings, reducing the stress on the micro metal gearmotor output shafts.
The Balboa chassis has a built-in battery holder for six AA cells, which typically give you several hours of run time, even if you add some extra power-hungry electronics like a Raspberry Pi.
Balboa 32U4 Balancing Robot with battery cover removed.
The main microcontroller is an Arduino-compatible ATmega32U4, which is powerful enough to read the on-board IMU sensors and encoders and to control the motors to balance the robot; it’s also great for introductory projects like line following or reading an RC receiver to make a radio-control balancing robot. For advanced projects, the Balboa is ready for you to add a Raspberry Pi computer to perform high-level algorithms while the ATmega32U4 microcontroller takes care of low-level tasks like motor control.
We will be adding more content to the Balboa’s product page and user’s guide, and we will have more blog posts about the Balboa robot. For today, we’ll end with some slow-motion footage of Balboa popping up on its own and then recovering when Paul knocks it around a bit:
At Pololu we maintain around thirty open-source Arduino libraries, and we keep adding new ones whenever we make a new carrier board or Arduino shield. People typically use these libraries with Arduino-compatible boards, such as our A-Star programmable controllers or Arduinos. We also have Arduino libraries for our user-programmable robot kits like the Romi 32U4 robot, Balboa 32U4 robot and Zumo 32U4 robot.
Sometimes we need to make changes to a lot of libraries at once, like when we wanted to add all of our libraries to the Arduino Library Manager. For us, library manager compatibility requires changing the directory layout, but doesn’t require changing the library or example code. With this many libraries to change, there is a risk of potentially breaking a working library by misspelling or moving a file incorrectly. Fortunately, customer Walt Sorensen introduced us to PlatformIO and Travis CI, which let us test compiling Arduino libraries every time they are pushed to GitHub.
Setting this up is easy enough that we encourage you to do it on your Arduino libraries! First, sign up for Travis CI (a testing service, free for open-source projects) and enable it for the GitHub repository you want to test. Now, every time you push new code to your repository, Travis CI will try to see if there is a .travis.yml file in the top level with instructions for running tests.
If your project has the structure of an Arduino Library Manager project and you have at least one example sketch, our short .travis.yml file should work. This file instructs Travis CI to compile the library and its examples against all the supported Arduino boards (specified in the “env” list of the .travis.yml file). The results can be seen on Travis CI’s website (for example, here is Pololu’s Travis CI page). The Arduino compiler is provided by PlatformIO, an open source ecosystem for internet-of-things development, which supports a long list of Arduino-compatible boards.
You can share your Travis CI build status by embedding a badge into your GitHub readme page:
Of course, for most library changes, we still have to test on actual hardware, but now every time we update our libraries (or a contributor submits a pull request), we can be sure they will at least compile on every supported board.
What do you need to turn a Romi chassis into a functioning robot? Here are some Romi projects from the community, as well a couple of our example builds:
A variety of controllers can be used with the Romi, but until now you have had to figure out lots of wiring to connect everything together. You will always need some wiring to connect your own sensors or other devices, but we have been trying to make it easier to get started, beginning with the Romi power distribution board and motor driver board, which help simplify some of the more difficult parts. Our new Romi 32U4 Control Board is the culmination of this product line: a complete controller solution for the Romi that integrates power, motor control, and an Arduino-compatible microcontroller.
Romi power distribution board, motor driver board,
Here is how it looks when connected to a Romi Chassis with motors and encoders plugged in, as well as the optional LCD:
Features of the Romi 32U4 Control Board
Pinout diagram of the Romi 32U4 Control Board (ATmega32U4 pinout, peripherals, and board power control).
- Reverse-protected battery power switch circuit
- Powerful 5 V, 2 A switching regulator
- Dual 1.8 A DRV8838 motor drivers
- ATmega32U4 microcontroller with Arduino-compatible USB bootloader
- 16 free general-purpose I/O ports including 10 analog inputs
- LCD connector
- Three user buttons
- Five indicator LEDs (2 for power, 3 user-controllable)
- Battery voltage monitoring
- Quadrature encoder inputs
- Four general-purpose level shifters
- 3-axis I²C accelerometer
- 3-axis I²C gyroscope
- Raspberry Pi connector with I²C interface and HAT EEPROM
Raspberry Pi interface
Microcontrollers like the ATmega32U4 are great for fast, timing-sensitive operations such as reading sensors or driving servos, but their computing power is very limited compared to devices like the Raspberry Pi. That is why we built a Raspberry Pi interface into this board: to give you the option to expand your robot beyond what is possible with a microcontroller. This could be useful for anything from advanced applications like computer vision or room mapping to simply letting your robot share status updates on Twitter. Here is a Romi assembled with a Raspberry Pi:
When connected, the control board supplies power to the Raspberry Pi and connects to it as an I²C slave device. We include the ID EEPROM required by the HAT specification, though we have not found it particularly useful, so we ship it blank and unlocked for you to experiment with.
Our Arduino library gives example code for I²C connectivity, and you can check out our Raspberry Pi tutorial for the A-Star 32U4 Robot Controller, which we will be updating for the Romi 32U4 Control board.
For more information about the Romi 32U4 Control Board or to order, please see its product page.
We’ve updated our Wixel Shield for Arduino with a few minor improvements. The Wixel Shield provides an easy way to connect a Wixel wireless module to your Arduino or A-Star 32U4 Prime, enabling wireless communication and even wireless programming (on some Arduinos). However, the original version of the shield was released many years ago, so it was not designed with the modern pinout of the Arduino Uno R3 in mind.
The Wixel Shield v1.1 adds pass-throughs for the four new pins—SCL, SDA, IOREF, and an unused pin—introduced by the R3 and present on all newer Arduinos, making it easier to stack other shields with it (especially ones that make use of the new I²C pin location). It also features improved level shifter circuits that make use of the IOREF voltage provided by the Arduino, allowing the shield to work automatically with both 5 V and 3.3 V Arduino boards.
The Wixel Shield for Arduino v1.1 is available by itself and as part of a combination deal that includes a pair of Wixels and a USB cable. See the user’s guide for the shield for additional information.
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 (which looks almost the same as v2.1).
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.
In this post I will show you how to build an expandable robot platform based on a Raspberry Pi and an A-Star 32U4 Robot Controller. With this platform, the powerful Raspberry Pi can take care of high-level tasks like motion planning, video processing, and network communication, while the A-Star, which mounts to the Pi’s GPIO header, takes care of actuator control, sensor inputs, and other low-level tasks that the Pi is incapable of. The total cost of the parts I used is about $120. Continued…
Our A-Star 32U4 Robot Controller SV with Raspberry Pi Bridge is now available, joining the LV version we released six months ago.
Similar to its lower-voltage sibling, the Robot Controller SV is a general-purpose robot controller that includes dual motor drivers and other useful peripherals like pushbuttons and a buzzer. It also has the same level shifters and power circuit that allow it to easily power and communicate with a Raspberry Pi when mounted as an auxiliary controller. Like our other A-Star controllers, the A-Star Robot Controller SV built around an ATmega32U4 microcontroller and ships preloaded with an Arduino-compatible USB bootloader.
This SV version of the A-Star Robot Controller uses an efficient step-down switching regulator, enabling it to operate (and optionally supply power to an attached Raspberry Pi) with input voltages from 5.5 V to 36 V. Compared to the LV version, the Robot Controller SV can also supply substantially more current across its wide operating voltage range:
We’ve been working on some (long-awaited) I²C software to allow the A-Star to be used as a slave controller with a Raspberry Pi master, as well as an example project that shows how to build a robot with this setup. They’re nearly ready, so watch for them on the blog in the coming weeks. But don’t forget that the A-Star board can also be used by itself as a capable robot controller, as my recent sumo robot demonstrates.
To facilitate both of these uses, the A-Star 32U4 Robot Controller SV is available either assembled for use as a Raspberry Pi add-on or in a more barebones configuration that is suitable for customized assembly or standalone use. See those product pages and the user’s guide for more information about the robot controller.