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.

As mentioned previously, I’m releasing moteus controller development kits to a few lucky beta testers.  Building these wasn’t too hard, but was my first foray into low-volume production for someone who wasn’t myself.  Here are a few pictures of the build:

To get ready for initial limited production of the fdcanusb I wanted to make some kind of enclosure so that you didn’t have to just grab the raw PCB and risk ESD failures.  I also wanted to be able to expose the status LEDs without having to do a window or anything else with multiple materials.

So for now, I just used a translucent PETG print, with light pipes and a thin wall above each of the LEDs.  The result isn’t too bad, you can clearly see the status LEDs and it feels plenty rugged for desk work.

One final piece of porting that needed to happen for the moteus controller r4.x series was the bootloader.  The r3.x series has a bootloader, which allowed re-flashing the device over the normal data link, but that was largely specific to the RS485 and mjlib/multiplex framing format.  Thus, while not particularly challenging, I needed to update it for the FD-CAN interface used on the r4.x board.

The update itself was straightforward: https://github.com/mjbots/moteus/compare/406f01…1123a9

For now, on the assumption I will in the not too distant future deprecate the r3.x series, just duplicated the entire bootloader, replacing all the communication bits with FDCAN and stm32g4 appropriate pieces.  As before, this bootloader is designed to only operate after the normal firmware has initialized the device, and also is required to be completely standalone.  To make code size easier to manage, it makes no calls to any ST HAL library and manipulates everything it needs purely through the register definitions.

Because my working environment is otherwise too idyllic and peaceful, I’ve been running the new moteus servo mk2 through its paces.  All day long.  8 hours a day.

This is the same test I ran to verify the controller, only now I’ve done it several times longer to get a better feel for if there are any weak links.  Somewhat surprisingly, the ball doesn’t drop all that often, only once an hour or two.

Earlier I described my design plan for reducing the overall mass of the moteus servo mk2.  Constructing a prototype of this turned out to take many more iterations and time than I had expected!  Along the way I produced and scrapped two front housings, two outer housings and a back housing.

I made one complete prototype which only had the weight reduction applied to some of the parts and lacked a back cover and any provision for a wire cover.  It was the one from the moteus controller r4.1 juggling video:

I’ve had a confusing mismash of development tools for the moteus servos for a while now.  My original development tool was in python, which worked just fine.  Coroutines allowed me to express complex asynchronous logic succinctly, the program itself was rather simple, and I could easily integrate it with matplotlib for plotting.  However, when looking to run this on the raspberry pi, I needed a newer python version than came with raspbian, which turned out to be a royal pain to get installed in a repeatable manner.  Thus I rewrote a portion of the moteus_tool in C++ and just used my normal cross-compiling toolchain to generate the binaries.  What I didn’t do was port the calibration logic, as the state machine required with standard boost::asio would have bloated the logic size by 5x, and I didn’t really need to calibrate servos from the raspberry pi ever.

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!

While gearing up to make some dev-kits followed by a pre-production run of the moteus servo mk2, I recently received a bunch of frameless rotors and stators.

As with the other custom items, I’ve got some spares of these for sale at shop.mjbots.com if you’re building along with me!  [UPDATE no longer!]

Now it’s time to start building some servos!

Just because I’m generally looking for workholding solutions for the Pocket NC, I recently picked up a vise designed for it from wcubed.co.

Unlike the stock vise that comes with the PNC, this has two movable aluminum jaws.  It can probably hold with greater force than the stock vise, since there is a larger contact area, although the screw mechanism doesn’t necessarily apply the force all that uniformly.  Also, since both jaws are movable, you have to take some care to either manually center things, or do some edgefinding, which isn’t terribly easy on a PNC.