Tag Archives: moteus

Production moteus controllers are here!

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 shop.mjbots.com and shipment worldwide for $119 USD each!

moteus_r43_front_left

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

moteus_r4_3_devkit_back_left

Many thanks for all the feedback from the beta testers who have been experimenting with the r4.2 version!

Pre-production mk2 servos

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.

dsc_0261-1
Shafts inserted into the planet input
dsc_0251
Output bearing on the planet outputs
dsc_0272-1
Planet output and internal gears onto the front housing
dsc_0273
Rotors with bearings and sun gears
dsc_0284
Stators installed
dsc_0300
Planet inputs with planet gears
dsc_0303
Planet inputs installed
dsc_0309
Back housing installed
dsc_0311
Moteus controller soldered
dsc_0313
All buttoned up

Now I need to test these on a quadruped!

 

Building the moteus controller dev kits

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:

dsc_0143
Machining the bracket
dsc_0155
A bunch of CAN cables
dsc_0156
A motor mounted on the bracket
dsc_0165
Mounted into the “desk stand”
dsc_0168
A bunch of brackets and stands
dsc_0169
STM32 programming cables
dsc_0170
Motors getting ready for installation
dsc_0172
A number of assembled kits

A big thanks to all the beta testers!  With the next revision of the controller, I’ll continue to have a development kit with roughly the same properties for those wishing to get started in an easy way.

If you have devkit envy, you can get a little fix watching this video showing how to set it up and use it.

 

CAN bootloader for moteus r4.x

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.

Thankfully, the ST HAL sources are BSD licensed, otherwise I’m not sure I could have gotten the FD-CAN and flash peripherals to work just given the reference manual.  With it, copying out the necessary constants made for an easy solution.

 

moteus servo mk2: Reduced weight test

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.

Making the reduced weight servo mk2

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.

dsc_0095
Soooo much PocketNC time for naught!

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:

dsc_0098

dsc_0096-1

Because of the multiple tries on the large-for-me front and back housing, I had to make soft-jaws and prepare stock in a more efficient manner.

I also had to get new workholding solutions for the PocketNC in the form of the wcubed vise.

Design updates

Every one of the pieces got reworked in some manner or designed from scratch for the things that did not exist previously.

Front housing: Here I iterated on how much material to remove from the central cavity.  Initially I removed more, but it gave the primary output bearing problems to be loaded intermittently.  Also, I had adhesion problems with the ring gear when too little material was left there.  I settled on a continuous ring for the output bearing and a decent amount of material for the internal gear.

20200107-front-housing-left20200107-front-housing-right

Back housing: I tweaked the back housing mounting points so that the outer housing could be symmetric.  Also, I added a facility for the wire cover to guard the phase wires entering the controller.

20200107-back-housing-left20200107-back-housing-right

Outer housing: The outer housing was largely unchanged from my initial weight reduced design, although I produced one bad one due to a simple mistake locating the mounting hole, and a second because the stud lengths between the front and back were different in an earlier iteration.

20200107-outer-housing

Planet output: The planet output design changed only to add some weight reducing cutouts.  This was the last part for which I was still using mk1 servo spare parts for, so now I actually manufactured a prototype in house.

20200107-planet-output-left20200107-planet-output-right

Planet input: Here there are now weight reducing cutouts, and the mating studs use less material.

20200107-planet-input-left20200107-planet-input-right

Back cover: The back cover design is basically unchanged, I just had to make one for the first time.

20200107-back-cover-left20200107-back-cover-right

Wire cover: The wire cover is a part of the design I had deferred until now.  It bolts to the back housing and shrouds the phase wires.

20200107-wire-cover-right.png20200107-wire-cover-left

Assembly

Here’s some assembly pictures:

dsc_0093
All the machined pieces prior to assembly

 

dsc_0099.jpg
Bearings installed in front housing and planet output
dsc_0101
Planet output and ring gear installed
dsc_0103
Stator installed
dsc_0104
Planets installed and pins in planet input
dsc_0106
Rotor and outer housing
dsc_0112
Back housing, controller, and wire cover
dsc_0113
All put together!

DSC00168

DSC00171

 

C++20 coroutines and moteus_tool

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.

Still, I’ve wanted to consolidate these tools for a while now, and while working towards other telemetry and development tool goals, I decided to make another pass at removing the duplicity.  I figured it was time to try using the new C++20 coroutines to implement the asynchronous logic in C++ and see if I could get rid of the python tool.  Since I’m currently vendoring all the compilers and libraries for the C++ applications, I am already running clang-9.0 with libc++ and boost 1.72 for all the host side tools which theoretically should all support coroutines just fine.

Why coroutines?

To recap, typical callback based boost::asio code looks something like this:

void DoSomething() {
  boost::asio::async_write(
    *stream_,
    boost::asio::buffer("command to send"),
    std::bind(&Class::DoneWriting, this, pl::_1));
}

void DoneWriting(boost::system::error_code ec) {
  FailIf(ec);
  boost::asio::async_read_until(
    *stream_,
    response_,
    "\n",
    std::bind(&Class::HandleRead, this, pl::_1));
}

void HandleRead(boost::system::error_code ec) {
  FailIf(ec);
  // Do something with the result.
}

This gets even worse if you have embedded control flow.  Typically the best you can do is construct an object to hold the state, and bind it around to keep track of things:

struct Context {
  int iteration_count = 0;
};

void Start() {
  auto ctx = std::make_shared<Context>();
  Write(ctx);
}

void Write(std::shared_ptr<Context> ctx) {
  message_ = fmt::format("{}", ctx->iteration_count);
  boost::asio::async_write(
    *stream_,
    boost::asio::buffer(message_),
    std::bind(&Class::HandleWrite, this, pl::_1, ctx));
}

void HandleWrite(boost::system::error_code ec,
                 std::shared_ptr<Context> ctx) {
  FailIf(ec);
  ctx->iteration_count++;
  if (ctx->iteration_count >= kLoopCount) {
    Done();
  } else {
    Write(ctx);
  }
}

Now, when coroutines are used, you can relinquish control with a simple “co_await”, and all the logic can be written out as if it were purely procedural:

boost::asio::awaitable<void> Start() {
  for (int i = 0; i < kLoopCount; i++) {
    auto message = fmt::format("{}", i);
    co_await boost::asio::async_write(
      *stream_,
      boost::asio::buffer(message),
      boost::asio::use_awaitable);
  }
}

Not only is this significantly shorter, it more directly expresses the intent of the operation, and lifetime of the various values is easier to manage.  No longer do we have to keep around the buffer as an instance variable or a shared ptr to ensure it lives beyond the write operation.  It stays in scope until it is no longer needed like any other automatic variable.

moteus_tool

Switching moteus_tool to coroutines was straightforward, and resulted in a big reduction in the verbosity required.

Moteus controller devkit PCBs in house

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!

I expect the development kits to clock in at $199, and include everything you need to power and communicate with the moteus controller, as well as a brushless motor to test with.

dsc_0133
Some fdcanusb boards
dsc_0150
The moteus controller r4.2
DSC00164.JPG
An in-progress moteus development kit
dsc_0149
Lots of moteus controllers!

 

 

Lots of frameless stators and rotors

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.

dsc_2225
It’s almost taller than me!
dsc_2228
Some stators
dsc_2230.jpg
A rotor

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!

Now it’s time to start building some servos!

 

wcubed vise for Pocket NC

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.

vise.jpg

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.

What it does allow though, is clamping narrow things.  The stock vise bottoms out at around 0.5″.  This vise can go all the way down to 0.

That came in handy with some recent moteus servo parts that I wanted to do a “5-axis” style toolpath from 3/8″ thick bar stock.

dsc_0045
Is it really that tall?

The vise provided plenty of clamping power to hold and machine at the tip of this awkwardly long bar.  This cut does chatter like crazy, but that’s about what you would expect.