I’ve been wanting to build a dynamometer for a while to better characterize the performance of the direct drive and geared versions of the moteus controller. I have now started down that path with a torque transducer, which I calibrated with the below fixture:
I got a what ended up being a low quality load cell amplifier to use with it from the same supplier, although discovered it was total garbage and am now using a SparkFun OpenScale board which seems to be working much better. Soon I’ll hopefully have something wired up that actually has a controller or two on it.
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.
Someone contacted me not too long ago who wanted to use the moteus controller, but wasn’t sure if it would be able to hit their target mechanical velocity of 6000rpm. I honestly wasn’t either, so I tested it. After a quick firmware fix, the devkit motor when run at 34V seems to be able to do it no problem.
It should be noted that the current firmware assumes you are within a thousand or so revolutions of 0. You can exceed that pretty quickly running at 120 revolutions per second!
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.
https://shop.mjbots.com is now https://mjbots.com (don’t worry, the old site redirects)! The functionality is largely the same, you can still get your qdd100 actuators or moteus controllers. The biggest differences are 1) it looks slightly nicer, and 2) shipping rates are improved, and international shipping rates drastically so. For instance, DHL “Express” 2 day shipping to some points in Europe is now under $35 USD, whereas previously 2 day shipping was over $300. That is often cheaper than even USPS International Priority — which is typically 2-4 weeks.
I’ll be adding some more products over the next couple of weeks, and I wanted to make them as accessible to a worldwide audience as possible!
It seems that I’m learning much about PCB design the very hard way. Back last year I wrote up my discovery of MLCC bias derating. Now I’ll share some of my experiences with MLCC cracking on the first production moteus controllers.
When I was first putting the production moteus controllers through their test and programming sequence, I observed a failure mode that I had yet to have observe in my career (which admittedly doesn’t include much board manufacturing). When applying voltage, I got a spark and puff of magic smoke from near one of the DC link capacitors on the left hand side. In the first batch of 40 I programmed, a full 20% failed in this way, some at 24V, and a few more at a 38V test. I initially thought the problem might have been an etching issue resulting in voltage breakdown between a via and an internal ground plane, but after examining the results under the microscope and conferring with MacroFab determined the most likely cause was cracking of the MLCCs during PCB depanelization.
Here’s a video describing the problem and potential solutions in way more detail than I’ll go into:
Needless to say, I hadn’t managed to see this failure in the 100 or so previous moteus controllers I’ve built, or I would have figured this out and resolved it!
For this first round of production controllers, I went and replaced every single capacitor near the edge of the board with a TDK variant that has internal soft termination, then tested them all at max voltage and a little beyond. Future revisions will use that variant of capacitor everywhere, as well as relocating the capacitors to reduce the mechanical stress they experience during manufacturing, handling, and installation.
Like with the fdcanusb, I built a programming and test fixture for the moteus controllers. The basic setup is similar to the fdcanusb. I have a raspberry pi with a touchscreen connected via USB to a number of peripherals. In this case, there is a STM32 programmer, a fdcanusb, and a label printer. Here though, unlike with the fdcanusb fixture, I wanted to be able to test the drive stage of the controllers and the encoders too.
My solution was to create a mechanical fixture that each board slots onto, with pogo pins that connect to test points for the phase outputs.
While it doesn’t make as good a connection as the solder through holes normally used to connect a motor, it is good enough to verify that the controller works. As a side-bonus, it also makes it trivial to test that the absolute magnetic encoder works properly.
This video shows how the programming and testing process works, and walks through testing a few boards.
This post will be short, because it is just re-implementing the functionality I had in my turrets version 1and 2, but this time using the raspberry pi as the master controller and two moteus controllers on each gimbal axis.
I have the raspberry pi running the primary control loop at 400Hz. At each time step it reads the IMU from the pi3 hat, and reads the current state of each servo (although it doesn’t actually use the servo state at the moment). It then runs a simple PID control loop on each axis, aiming to achieve a desired position and rate, which results in a torque command that is sent to each servo. Here’s the video proof!