r4.11 is electrically, mechanically, and software compatible with r4.3, r4.5, and r4.8.
This revision supports two alternate footprints for the CAN-FD transceiver to better support component availability and refines the power stage for the DRV8353 gate driver. moteus r4.8 was the first version to use the DRV8353 because of, once again, component availability issues. However, it was developed on a very abbreviated schedule. With r4.11 the EMI is much improved over r4.8 and r4.5, and the efficiency is much better than r4.8 at all input voltages and PWM frequencies.
95% / 0.28W
94% / 0.20W
95% / 0.30W
92% / 0.25W
93% / 0.35W
88% / 0.25W
90% / 0.38W
85% / 0.30W
91% / 0.36W
84% / 0.30W
89% / 0.40W
84% / 0.35W
moteus r4.11 and r4.8 thermal efficiency and idle power driving nearly stationary motor
The matching development kit will be available shortly, once the r4.8 developer kits sell out.
While testing some variants and new versions of the power_dist board, I wanted to be able to simulate the types of loads that it experiences with a fully loaded robot. Some things are easy, like this capacitor attached to an XT30 connector:
I also have giant power resistors in a similar form factor:
However, a dumb load resistor isn’t a particularly representative load. Most likely, the loads that a power_dist will drive are active loads with switching regulators. When the output voltage is lower, the current will be correspondingly higher. That is especially important when validating pre-charge behavior, because it means that the current is much higher during the initial pre-charge window than it would be for a pure resistive load.
Thus, I made a tiny switching regulator to which I can stick a load resistor to the output.
Unfortunately since MacroFab discontinued their prototype tier, it no longer is as convenient to get one offs populated in the US. So this one I did by hand with a stencil, solder paste, a 3D printed frame, and some new tools, a vacuum pick, and a hot plate. I discovered you can get room temperature stable solder paste now — how convenient!
There were a few bugs… I managed to not have 0603 resistors for the voltage sense divider on hand, but had 0402 of the right values so just stuck a blob of solder to connect them. On the same resistors, I also managed to get the PCB labels swapped. Fixing that resulted in a board that does what it is supposed to!
Meet the newest revision of the moteus controller!
Yes, it does look mostly the same as the r4.3 that has been getting a lot of use lately. This revision exists mostly to improve manufacturability, but I snuck in a minor design improvement while at it. Now, the maximum voltage input is rated up to 44V from the 34V of the r4.3! (Note though, that the pi3hat and power_dist still are limited to 34V). Otherwise the new controller is fully electrically, mechanically, and software compatible with the r4.3.
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.
Thus I spun a new revision r3, basically just to fix all the blue wires so that I could have some spares without having to worry about the robustness of my hot glue. While I was at it, I updated the logo:
As seems to be the way of things, a few days after I sent this board off to be manufactured, I realized that the CAN port needed to actually be isolated, since when the switches are off, the ground is disconnected from the rest of the system. Sigh. Guess that will wait for r4.
Finally returning back to other pieces of my quad roadmap, I finished getting an updated power distribution board ready for the quad A0. This board is one I had made many months ago and mostly brought up, but then didn’t quite finish. The r1 was when I first discovered my unfortunate stm32g4 pinout problems that doomed 3 of my in flight boards. The pictures here are of r2, which suffered from yet more pinout problems, resulting in more than my usual number of blue wires. Fortunately, identifying those problems here let me fix them ahead of time for the fdcanusb and moteus r4 boards.
This version has a probably overkill XT90 input connector, 6x XT30 output connectors, a connector for a lighted toggle switch and an FD-CAN port. The CAN port will eventually allow me to implement a soft power off, although I haven’t done that yet.
When hooked up to a moteus dev kit, it does do the proper pre-charging thing:
Update 2020-01-15: All the development kit slots are full. Thanks for your interest!
I’ve now received all the supplies I need to make up development kits for the moteus controller and to make a test quadruped!
I’m planning on making a few development kits from this production run so others can experiment with the moteus brushless controllers. Some people have already expressed interest in getting one — you have hopefully been contacted earlier. If you are interested in getting an opportunity to buy an early access kit and haven’t heard from me yet, fill out this form!
One of the necessary pieces for bringing up the moteus brushless controller and for ongoing development with it is being able to communicate with the device on the desk. There aren’t many options for desktop FDCAN communication currently, and certainly none that are in the affordable range occupied by the CANUSB family of devices which I’ve used before and was very happy with. Thus I created “fdcanusb”, a USB to FDCAN converter that allows one to communicate with FDCAN devices via a USB interface using a documented protocol, no drivers necessary.
The notable features:
USB 2.0 full speed host interface
ISO 11898-1: 2015 FDCAN interface on industry standard DB9 connector
Standards compliant bitrates up to 1/5Mbps supported
Software controllable termination
Frame sizes up to 64 bytes
Non-standards compliant bitrates allowed
Documented CDC ACM based host protocol (virtual COM port)
Apache 2.0 licensed firmware based on the STM32G474 controller
All for an expected sales prices of around $100.
This does come with some caveats: For one there is no galvanic or optoisolation, you get a common mode range of around +- 12V. Another is that using just a USB 2.0 full speed interface means it may not be able to keep a FDCAN bus fully saturated at high bitrates. Finally, the firmware will start out with just the bare bones capabilities, but can be extended to support features such as error injection, triggers, buffering, and more compact protocols in the future.
I’ve got the first functioning prototypes of these boards in hand now: