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!
To date, I’ve used the moteus controllers exclusively for joints in dynamic quadrupedal robots. However, they are a relatively general purpose controller when you need something that is compact with an integrated magnetic encoder. For the v3 of my Mech Warfare turret I’m using the moteus controllers in a slightly new configuration, with a gimbal motor, one for each of the pitch and yaw axes.
Gimbal motor theory and current sensing
From an electrical perspective, gimbal motors are not that all that different from regularly wound brushless outrunners. The primary difference being that they are wound with a much higher winding resistance. That enables them to be driven with a much lower current, at the expense of a lower maximum angular velocity. In this case, I’m using the GM3506 from iFlight which has a winding resistance of 6 ohms, that results in working currents being on the order of 2A maximum.
The moteus controllers are designed to drive motors with phase currents in the 20-60A range. To operate in current control mode, they use a current shunt resistor connected to a dedicated amplifier for each phase. The current sensing resistor determines the range of currents that can be accurately sensed. The resistor that the controllers have by default measures 0.5 milliohms, which gives a reasonable tradeoff between accuracy and power dissipation for 60A operation. However, for 2A operation, it results in pretty low resolution current feedback. Thus for this application, I substituted in 5 milliohm current shunts:
Control modes and noisy velocity
The other potential challenge, is that the velocity signal that can be derived from the AS5047 absolute magnetic encoder in the moteus controller is relatively noisy when operated with no gearbox reduction. That limits how much derivative gain can be used in a position control loop. You could get around that by incorporating more plant knowledge in a filter or state observer, but that shouldn’t be necessary here.
Fortunately for this application, I won’t be controlling position based on the absolute magnetic encoder, but instead based on the inertial measurement unit in the primary controller. The absolute magnetic encoder will be used solely for performing the DQ transform to implement torque control, for which the noise in velocity is irrelevant.
Next up is making these controllers actuate the turret.
Developing the moteus brushless servo controller has been a verylongjourney, and while it isn’t over yet I have a reached a significant milestone. The first batch of production moteus controllers are now available for general purchase at shop.mjbots.com and shipment worldwide for $119 USD each!