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.

Another of the tasks I’ve set for myself with regards to future Mech Warfare competitions is redesigning the turret.  The previous turret I built had some novel technical features, such as active inertial gimbal stabilization and automatic optical target tracking, however it had some problems too.  The biggest one for my purposes now, was that it still used the old RS485 based protocol and not the new CAN-FD based one.  Second, the turret had some dynamic stability and rigidity issues.  The magazine consisted of an aluminum tube sticking out of the top which made the entire thing very top heavy.  The 3d printed fork is the same I one I had made at Shapeways 5 years ago.  It is amazingly flexible in the lateral direction, which results in a lot of undesired oscillation if the base platform isn’t perfectly stable.  I’ve learned a lot about 3d printing and mechanical design in the meantime (but of course still have a seemingly infinite amount more to learn!) and think I can do better.  Finally, cable management between the top and bottom was always challenging.  You want to have a large range of motion, but keeping power and data flowing between the two rotating sections was never easy.

Developing the moteus brushless servo controller has been a very long journey, 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 mjbots.com and shipment worldwide for $119 USD each!

I’ll repeat some of the specifications here:

• 3 phase brushless FOC control
• 170 MHz 32bit STM32G4 microprocessor
• Voltage: 12-34V
• Peak phase current: 60A
• Dimensions: 46x53mm - CAD drawing in github
• Mass: 14.2g
• Communications: 5Mbps CAN-FD
• Control rate: 40kHz
• Open source firmware: https://github.com/mjbots/moteus

Simultaneously, I’ve got development kits available that give you everything you need to start developing software for the moteus controller out of the box: moteus r4.3 developer kit

To build a second demonstration quadruped and to generate some development kits, I’ve built up a set of 20 of the mk2 servo.  The production process is working out fairly well, in fact slightly better than I had predicted for overall cycle time.  The servos so far are coming out great, moving smoothly with full power.

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:

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!