Welcome to the Pololu Blog, where we provide updates about what we and our customers are doing and thinking about. This blog used to be Pololu president Jan Malášek’s Engage Your Brain blog; you can view just those posts here.
The RoboClaw 2x60A motor controller (V5) we’ve been carrying has been replaced by the new RoboClaw 2x60A Motor Controller (V6). This powerful motor controller can drive two brushed DC motors with 60 A continuously at voltages from 6 V to 34 V, and it allows for peak currents up to 120 A. Version six adds a protective aluminum plate to the board bottom and ports for connecting optional cooling fans that are controlled based on the board temperature.
RoboClaw 2×60A Motor Controller (V6), bottom view.
The RoboClaw motor controllers from Ion Motion Control can control a pair of brushed DC motors using USB serial, TTL serial, RC, or analog inputs. Integrated dual quadrature decoders make it easy to create a closed-loop speed control system, or analog feedback can be used for position control.
For more information, see the product page.
We’ve added this Micro-USB wall adapter to our catalog. It can supply up to 2.4 A at 5.25 VDC (the USB specification’s maximum bus voltage), allowing for voltage drop due to power draw when powering 5 V electronics. It features a 1.5 m to 1.8 m (5 ft to 6 ft) DC power cord with 20 AWG wires that is terminated by a USB Micro-B connector, which makes it great for powering devices like a Raspberry Pi (especially newer Raspberry Pi models, like the Pi 3, which can draw a lot of current!).
Raspberry Pi connected to a Wall Power Adapter: 5.25VDC, 2.4A, 20AWG MicroUSB Cable.
For more details, see the product page.
This tutorial shows how to build a basic Raspberry Pi robot with the Romi chassis and the Romi 32U4 Control Board, our Arduino-compatible microcontroller board designed specifically for the Romi. With this setup, the powerful Raspberry Pi can take care of high-level tasks like motion planning, video processing, and network communication, while the Romi 32U4 Control Board takes care of low-level tasks that the Pi is incapable of, such as motor control and sensing. Continued…
Don’t hold your applause: we are now offering the Verbal Machines VM-CLAP1 Hand Clap Sensor! This board is a low-power, microprocessor-based audio sensor that can detect hand claps or finger snaps while ignoring background noises such as human speech or music. It operates from 2.5 V to 5.5 V and offers a simple interface: when a clap or snap is detected, the output pin goes low for 40 ms, and the integrated blue LED lights up.
It has been over a year since my last/first blog post about my mini sumo robot. Since then, I have been busy studying to earn a mechanical engineering degree at the University of Nevada, Las Vegas, working at Pololu, and, of course, building cool robots. Recently, I have been working as part of a UNLV team, Rebel Robotics, to build a robot to compete in an intercollegiate competition organized by the American Society of Mechanical Engineers (ASME) called the Student Design Competition. My team’s robot, the Rebel WIP (work in progress), competed against teams from colleges across the western half of the United Sates in the Student Design Competition at an engineering festival hosted by UNLV and ASME called E-Fest West. Continued…
One of our customers built this six-foot tall balancing robot. The main microcontroller is a Teensy 3.6, and the stepper motors are driven by ST-M5045 drivers. For its drive train it uses two 3 A stepper motors connected to Pololu 90 mm wheels via Pololu universal aluminum mounting hubs.
Here’s what they have to say about using stepper motors:
I used stepper motors to take advantage of high torque at low RPM and zero backlash. This allows very steady stand-still performance. But dealing with the stepper-induced mechanical vibration was an issue. This was mostly solved with analog filters on the IMU and with an Extended Kalman Filter in software.
Additional description and pictures are available on the project page.
This is the fourth post in a series about how to make a Balboa 32U4 robot balance. In earlier posts I covered the basic sensors and mechanical parts used for balancing; in this post I will show you how to put everything together to make the robot actually balance.
From earlier posts we have obtained six basic variables for use in balancing:
angleRate: the rate of rotation
angle: the angle relative to vertical
speedRight: motor speed
distanceRight: motor distance
I was not specific about this before, but to get the details of the algorithm right it is important to know the signs of these variables. Here is a diagram showing what I mean by positive or negative angles, as well as driving “forward” or “backward”:
Angle convention used by the Balboa 32U4 balancing example.
These signs are consistent with the ``y`` angle drawn on the PCB silk screen and the Balboa library’s motor drive functions, as long as you soldered your motors according to the instructions. So now let’s look more at how these variables work.
Motor speed and distance are easy enough to understand, since they just measure the effects of applying power to the motors, but the angle variables are related to gravity in a way that is not as intuitive. For the angle variables, I find it helpful to make some plots showing the trajectory of the robot over time. Suppose we take a Balboa with its motors off, start it leaning forward, and give it a little push toward vertical. Initially,
angle is positive and
angleRate is negative. As the robot rises toward vertical,
angleRate decreases until it runs out of momentum, stops, and starts falling forward. It continues to fall forward, faster and faster, until it hits the floor. The blue curve in the graph below shows approximately what the trajectory looks like:
Now suppose we push it harder, so that it falls over onto its other side. This time, it continues rotating as it passes through vertical, then falls backwards onto the floor:
Somewhere between these two paths lies a perfectly-balanced trajectory, indicated by the gray dashed line. If we could give it the exact right push, it would follow that line, rising up to vertical just as the rate of rotation falls to zero, and remain balanced forever.
This snippet of code from our Balancer example project computes how far off we are from this ideal rising trajectory:
// This variable measures how close we are to our basic // balancing goal - being on a trajectory that would cause us // to rise up to the vertical position with zero speed left at // the top. This is similar to the fallingAngleOffset used // for LED feedback and a calibration procedure discussed at // the end of Balancer.ino. // // It is in units of millidegrees, like the angle variable, and // you can think of it as an angular estimate of how far off we // are from being balanced. int32_t risingAngleOffset = angleRate * ANGLE_RATE_RATIO + angle;
In the code,
ANGLE_RATE_RATIO is a constant that must be determined through experiment. (A value of 140 worked well for the units we used and our Balboa’s configuration.)
When a Balboa is actively balancing, it “pushes” itself by adjusting the speed of its motors. When the motors make a sudden change in speed, they give a push to the chassis (the combined effect of direct motor torque and of the horizontal motion of the wheels). The effect on the angle variables is the same as if you pushed the chassis by hand: the rate of rotation suddenly changes.
If you think about it a little, you should see that applying backwards acceleration makes the rate of rotation increase (in the positive direction). So how could a Balboa on a trajectory like the one above save itself? It needs to apply just enough backwards acceleration to bump it up onto that ideal dashed gray line:
We don’t know the exact relationship between acceleration and change in rate of rotation, and acceleration is not actually instantaneous, but the basic point is that we should adjust our motor speed by a factor proportional to the
risingAngleOffset variable determined earlier. Here’s approximately how we do that in our code:
int32_t risingAngleOffset = angleRate * ANGLE_RATE_RATIO + angle; motorSpeed += ANGLE_RESPONSE * risingAngleOffset;
In this case
ANGLE_RESPONSE is a constant that needs to be adjusted experimentally until the robot can “catch” itself from a variety of starting conditions, ending up as vertical as possible.
But what happens after the robot catches itself? It reached a balanced position by changing the motor speed, so now the motors are driving off in some direction. It is balanced, so there is no reason for it to accelerate or decelerate, and it will drive away until it bumps into something or falls down, which is clearly not ideal behavior.
That’s where the encoder-based variables come in to play. We can prevent the robot from driving away by adding additional adjustments to the motor speed that depend on the speed and distance varaibles. Counterintuitively, the way to stop it from driving away in one direction is to accelerate even faster in the same direction, causing it to fall back toward where you want to be. Two additional terms are enough to get it to come back to its starting point:
int32_t risingAngleOffset = angleRate * ANGLE_RATE_RATIO + angle; motorSpeed += ANGLE_RESPONSE * risingAngleOffset + DISTANCE_RESPONSE * (distanceLeft + distanceRight) + SPEED_RESPONSE * (speedLeft + speedRight);
Again, each variable is multiplied by a constant that must be calibrated experimentally. Of course there is a lot more code required to put everything together; you can see the details in our balancer example on GitHub. Here are some additional considerations addressed in the example code:
- The two motors will have different responses, especially at low speeds where friction is important. So we adjust the power applied to the left and right motors depending on the difference between
- To get the units to work out when all the variables are integers, the motor speed needs to be divided by a large number, approximately 10,000. (Alternatively, we could have written each term above as a division, like
risingAngleOffset / ANGLE_RESPONSE, but I think that makes the parameters harder to understand.)
- In the example we include a configuration parameter
GEAR_RATIOto make it easier to adjust everything to be approximately right at a different gear ratio.
- As mentioned in the last post, this works best if run at a regular interval. The example code takes care of running the algorithm once every 10 ms.
The final result is similar to a PID algorithm, but it responds to both rotational and translational motion with a single output, the motor speed. You can probably get similar results just by starting with the angle and distance variables, creating all six possible PID terms, and adjusting their constants to optimize the motion, but it can be hard to get so many constants right at the same time without a clear understanding of what each one means.
The following video shows our balancing algorithm in action:
The yellow, green, and red LEDs visible in the second part of the video display what the Balboa thinks of its state, with each of the eight possible color combinations indicating a different eighth of the graph. The figure below shows the LED colors in each section of the graph along with the approximate trajectory of the robot after being pushed, so that you can try to follow along with the video:
One thing you can see from the graph is that the amount of forward acceleration and backward acceleration are about the same, so that overall effect is to drive forward then decelerate to a stop. It’s also important to note that the graph makes it look like the robot only does two large corrections, while in reality it is constantly making small adjustments to the motor speed. Its actual trajectory might look like a smoothed-out version of the blue line, without sharp corners.
There is something major in the video that I have not yet covered: “popping up” from a lying-down position. I will talk about that next week!
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.
One of our customers used our custom laser cutting service to cut the birch plywood panels for his retro-gaming TV system that he sells on Etsy. The birch panels are stained with shellac. The system runs on a Raspberry Pi 3 Model B, to which you can connect (not-included) controllers with Bluetooth or USB. The Raspberry Pi’s Ethernet port, SD card slot, and 4 USB ports are accessible in the back.
Customer Lujing Cen’s team built two semi-autonomous 14-DOF quadrupeds using Mini Maestros for their high school class project at the California Academy of Mathematics and Science. The project syllabus includes making two separate robot designs and three total robots that work together. These quadrupeds were the “pack robots” described in the syllabus. An 18-channel Mini Maestro USB servo controller controls the twelve leg and two head servos. The project code includes a rewrite of Pololu’s Maestro C# USB SDK library in Python. The robot uses a camera and an RFID scanner to track its targets.