So now we’ve got everything back in stock once again!
I’d like to introduce the qdd100 beta 2!
This is the newest version of a quasi-direct-drive servo from mjbots. It has a sleek new look, and improved performance all around:
|Beta 1||Beta 2|
|Peak Torque||12.5 Nm||16 Nm|
|Backlash||+- 0.2 degrees||+- 0.1 degrees|
Additionally, the M3 mounting holes are now 3mm deep instead of the previous 2mm, which gives more flexibility when designing mounts.
It is in stock at mjbots.com now, with more production becoming available in the next weeks and months.
Here’s the approximately annual giant video update:
If you’re interested in any of the topics in more detail, I’ve collected links to individual posts for each of the referenced items below.
Thanks for all your support in the last year!
Announcement of moteus r4.3: Production moteus controllers are here!
Automated programming and test setup: Programming and testing moteus controllers
Continuous rotation: Unlimited rotations for moteus
The virtual wall control mode: New “stay within” control mode for moteus
Handling magnetic saturation: Dealing with stator magnetic saturation
Discussion of the overall design, and details on individual sub-components:
- moteus servo mk2
- moteus servo mk2: Planet Input
- moteus servo mk2: Outer housing
- moteus servo mk2: Front housing
- moteus servo mk2: Back housing
- moteus servo mk2: Functional test
- Making the reduced weight servo mk2
- moteus servo mk2: Reduced weight test
And the pre-production mk2 servos: Pre-production mk2 servos
Ground truth torque testing: Ground truth torque testing for the qdd100
Skyentific’s telepresence clone: qdd100 telepresence demo
kp and kd tuning: Spring and damping constants
quad A1 – Hardware
Lower leg updates:
- The first quad A1 leg: Update leg design for mk2 servo
- The first foam cast foot: quad A0 – Improved foot design
- Longer and with a knee gear reduction: quad A1 leg updates
- A fixture to assemble legs: Quad feet construction fixture
- One of the feet failures: Another foot failure
Cable conduit changes: New leg cable management
quad A1 – Software
Cartesian coordinate control: Cartesian leg PD controller
Pronking: Successful pronking!
tplot2 and its sub-pieces:
- Updated serialization library
- Revised mjlib serialization design
- C++ serialization API
- Log file format
- Video in tplot2
- 3D rendering in tplot
- Video and telemetry synchronization
Simulation: Resurrected quadruped simulator
nrf24l01 transceiver and its sub-components
- Spread spectrum RF control and telemetry
- Spread spectrum protocol design
- Spread spectrum implementation
- Spread spectrum integration
Smooth leg motion: Improved swing trajectory
- Primitive gait balancing – 1D
- Balancing gait in 2D
- Balancing on estimated terrain
- Testing real-life hill operation
Improved stand up sequence: quad A1 stand-up sequence part N
When I first posted the qdd100 beta on mjbots.com, I performed a simple “continuous torque” test where I measured the torque that could be applied indefinitely without thermal limiting in a lab environment. It has come to my attention that other servos rate their “continuous torque” for a much lower value of “continuous”, sometimes only 30s. To make the situation clearer, I measured the time to thermal limiting at a range of torques and updated the product page.
For this test, at each torque value I started with the qdd100 in thermal equilibrium with an ambient 20C lab environment, then applied the given torque and waited until thermal throttling set in. No forced airflow was present and no conductive or radiative cooling enhancements were used.
|Torque||Time to Thermal Limit|
|12.5 Nm||< 5 s|
|8 Nm||120 s|
|6 Nm||300 s|
|4 Nm||800 s|
I saw a recent Skyentific video and decided to have a try at it myself, check out the result:
I’ve worked through a number of different iterations of the stand-up sequence for the quad A1 (2019-05, 2019-09). The version I’ve been using for the last 6 months or so works pretty well, but because it drags the legs along the ground to get them into position, it can have problems when operating on surfaces with a lot of traction, like EVA foam, besides being uselessly noisy.
To make things just a bit more robust, I’ve now tweaked the startup routine so that the shoulders lift legs clear off the ground before positioning the legs, then lowers them back down into place. This makes the stand up routine much more likely to succeed on just about any surface:
In my previous experiments demonstrating torque feedback (full rate inverse dynamics, ground truth torque testing), I’ve glossed over the fact that as the stator approaches magnetic saturation, the linear relationship between torque and current breaks down. Now finally I’ll take at least one step towards allowing moteus to accurately work in the torque domain as motors reach saturation.
The stator in a rotor consists of windings wrapped around usually an iron core. The iron in the core consists of lots of little sub-domains of magnetized material, that normally are randomly oriented resulting in a net zero magnetic field. As current is applied to the windings, those domains line up, greatly magnifying the resulting magnetic field. Eventually most of the sub-domains are aligned, at which point you don’t get any more magnifying effect from the iron core. In this region, the stator is said to be “saturated”. You can read about it in much more depth on wikipedia or with even more detail here. The end result is a curve of magnetic field versus applied current that looks something like this:
To date, moteus assumes that you are operating completely in the “Linear” region, where the torque and current are linearly related.
Operating in the Rotation Region
To operate in the “rotation” region I ended up using the following formula:
Where is the input current, is the motor torque constant, , and are three constants that I fit to measured torque data. With some approximations, this can be calculated relatively efficiently on the STM32G4 that drives the moteus controller, adding only a microsecond to the overall loop time to go in both directions.
I then ran a torque sweep with my load-cell fixture from before, and sure enough, the input and output torque match much better now across the entire range of operation, despite the fact that the phase current needs to start growing very rapidly near the top end:
My initial design torque for the qdd100 was a little over 17 Nm. However, when I did my first ground truth torque testing, I found that some servos had a lower maximum torque than I had specified. While working to diagnose those, I built a qdd100 that used an alternate stator winding of 105Kv instead of the 135Kv that are in all the beta units. The Kv rating of a stator describes how fast the motor will spin for a given applied voltage. If you assume the same amount of copper mass of wiring, a lower Kv will mean that there are thinner wires that wrap around the stator more turns (or fewer wires in parallel). A higher Kv will have thicker wires with fewer overall turns.
On paper, if you assume a perfect controller, this shouldn’t make much of a difference. The same input power should be required for the same output torque. The only differences should come into play once you have a controller with either a limited maximum voltage or a limited maximum current. The higher Kv motor will be able to go faster given a fixed maximum voltage, and the lower Kv motor will have more torque for a given maximum current.
I wanted to verify that this was true as part of my evaluation to identify the cause of my decreased torque, so I used a slightly upgraded torque testing fixture:
For now, I rigged up the world’s cheapest load cell from amazon to a Nucleo configured to report the load in grams over the serial port. I also wired up my Chroma power supply over USB using the linux USBTMC driver. With those two things hooked up, I was able to run tests that sweeped across torque commands, while recording output torque, phase current, and input power.
At higher torques, the input power was pretty sensitive to the temperature of the windings — hotter windings increased the resistance, which increased the power required to achieve a given phase current, thus my plot isn’t perfect as it was grabbed over several different runs. For the highest power samples I couldn’t use my Chroma, as it is limited to around 600W. Thus those samples don’t record the input power.
Plotting the input power vs output torque on the same chart shows that indeed, modulo some measurement error, they are the same for the two stators:
So, this experiment reaffirmed my understanding of stator magnetics and confirmed that the stator winding was not the cause of my decreased torque.
One of my goals with mjbots is to make building dynamic robots more accessible to researchers and enthusiasts everywhere. To make that more of a reality, I’m lowering the prices in a big way on the foundational components of brushless robotic systems, the moteus controller and qdd100 servo.
|moteus r4.3 controller||$119||$79|
|moteus r4.3 devkit||$199||$159|
|qdd100 beta devkit||$599||$469|
Don’t worry, if you purchased any of these in the last month, you should be getting a coupon in your email equivalent to the difference.
As I am working to improve the gaits of the mjbots quad A1, one aspect I’ve wanted to tackle for a long time is improving the compliance characteristics of the whole robot. Here’s a small step in that direction.
Existing compliance strategy
The quad A1 uses qdd100 servos for each of its joints. The “qdd” in qdd100 stands for “quasi direct drive”. In a quasi direct drive actuator, a low gearing ratio is used, typically less than 10 to 1, which minimizes the amount of backlash and reflected inertia as observed at the output. Then, high rate electronic control of torque in the servo based on current and position feedback allows for dynamic manipulation of the spring and dampening of the resulting system.
Another option is a series elastic actuator, which uses a traditional high gear reduction servo with a mechanical spring or elastic mechanism inline with the load. Sometimes a separate motorized actuation mechanism can be used to vary the damping properties of the elastic element. This is in principle similar to the quasi direct drive approach, but suffers from a limited overall control bandwidth. Despite being “springy”, QDD servos are still able to have a very high effective mechanical control bandwidth, on the order of hundreds of hertz.
For the quad A1 to date, the compliance it exhibits is largely due to the qdd100’s internal control algorithms, and to a very minor extent, flexing in the mechanical structures of the quad A1 itself. This does work, and gives decent results.
The biggest limitation of solely using this approach, is that since the compliance is performed at the joint level, it has no knowledge of the current 3d configuration of the leg. The resulting compliance in 3D space is highly non-linear and depends upon where in configuration space the leg is at that point in time. For instance, if the back legs are configured to have the knee very bent, but the front legs are not, then the back knee needs a much larger restorative torque per unit rotation to have the same linear restorative force at the tip of the leg.
That results in artifacts like shown in the video at the bottom. When the robot falls with the legs not in an identical configuration, the robot ends up pitching or rolling depending upon how the compliance interacts with the current leg geometry.
In my original designs for the moteus controller, I had left a high rate “inter-leg” bus option in the design, where each controller could exchange IK information at the full control rate, so that all compliance could be performed in the 3D space, rather than in joint space. However, as the design progressed, and I failed to implement it, I dropped that capability to simplify and reduce costs.
Here, I ended up implementing something purely in software which doesn’t have the same level of performance as that system would have, but also doesn’t require additional dedicated high rate communication transceivers on every servo control board. The 3D PD controller is just run on the raspberry pi at the regular control update rate (400Hz currently). That makes the control flow look like this:
While this solution isn’t perfect, it does give better results in many scenarios. I applied some disturbances to the robot with either solely joint level controllers, or joint plus XYZ controllers. For the two cases, I tried to tune the controllers to a similar level of stiffness and damping to make the comparison as fair as possible. Walking is generally improved as well, even with just a constant compliance throughout the gait cycle.