All posts by Josh Pieper

moteus servo mk2: Outer housing

The outer housing for the moteus servo mk2 is just a precision round tube with some mounting holes drilled peripherally.  Still, manufacturing it was slightly annoying, mostly because of my available machining resources.



I started off with round tube stock with some extra margin on the inside and outside:


Then I went and used the manual lathe at Artisan’s Asylum to get the correct ID, OD and length:


At this point, I loaded it into the Pocket NC with Sherline 4 jaw chuck, using a 3d printed bracket to align the assembly with the base of the chuck.


Now, I could use the B axis as an indexer, and drill and countersink all the holes.

moteus servo mk2: Planet Input

As the first part of the new moteus servo mk2, and continuing in my series of learning about CNC by building parts for the quadruped, next up I machined the input to the planet gears on my Pocket NC V2-50.  This was a part, that for my quad A0 build, I used a 3d printed part in PETG as it is probably the least stringent part in the gearbox in terms of tolerances and load, although I still expect the plastic ones will likely wear and fail after some time with heavy use.

Part description

In the gearbox, this planet input interfaces to a number of different sub-assemblies:


The planet output inserts into its studs, the planet shafts insert into recessed holes in the face, and the planet input bearing fits into its center.  Bolts fit through the back to pull the planet output towards the input.  There is also an indexing cutaway on the outside for an eventual absolute position system.


I made these from round stock, 1.75in in diameter cut to 1″.  The machining was done in two setups, each using the Sherline 4 jaw chuck mounted to the B axis of the Pocket NC.


In the first setup, the back side was roughed out, the center hole was cut out, and each of the holes for the bolts was bored along with a countersunk region.

The second setup, flipped over, first roughed, then proceeded to finish each of the necessary surfaces.  There were two more interesting bits here.  First, I made an alignment fixture so that I could get the holes from the back and front half to align.  That consisted of a cylindrical shell that fit into the mounting pattern on the B table of the pocket NC and a thin plate that fit under the part.  The thin plate just stays in place during the machining operation, where the shell pulls out.


The other interesting part was that I ended up clearing away a bit of the inside of each stud so that my bit could reach down to finish the bearing mounting surface.  That way I could get away with just using an 11mm flute, which already gave a terrible enough surface finish that going longer would have only made worse.

More pullout

As I’ve observed in the past, I had yet another problem with tool pullout during this part.  Here, the problem was very similar to my past incident, when Fusion left a thin wall, then tried to punch through it.  My fix from then was doing the right thing, however the wall was just too thick I believe, causing the toolholder to lose grip.  In this clip, you can see that after it breaks through the wall, the mill cuts through some stock as it repositions over.  The slip was only about 0.3mm, but that’s enough to mess things up.

However, this time I think I figured out an even better solution.  Simply lie to Fusion 360 about the diameter of the cutting tool and say it is slightly undersized.  That results in fusion leaving the adaptive passes closer together, and thus no thin walls or foils are left behind.  It would be nice if that were just an option in the adaptive settings.  I suppose you could override it in the “Compare and Edit” window, but creating a faux “tool” just for roughing makes it easier for me to see that I’ve applied the override correctly.


Here’s a video showing the different tool paths for the finished part:

4x “good enough” planet inputs

Future work

The stock cut of 1″ is oversized in this part and adds a bit more than an hour to the cycle time over a minimum sized piece of stock.  I need to get a setup for cutting stock smaller than an inch here soon.

Also, I’ve discovered that ekramer3 has been testing the 4mm single flute Datron endmill, which should be able to nearly double the MRR for the roughing passes.  I’ll give that a try on the next part I make.

moteus servo mk2

As described in my roadmap, making a new revision of the moteus servo is up there on my list of things to do.  The initial servos were a work of art, yes, but also pretty fragile, very labor intensive, and still not all that robust.  My goals this time around are:

  • Manufacturability: The servo mk1 took about 2 or 3 man-days of manufacturing time per servo once all the steps were factored in.  I’d like to get that down to an hour or two at most per servo.
  • Robustness: The planet input, outer housing, back housing, and controller cover of the mk1 servo were 3d printed, mostly to save cost and time.  This necessitated adding reinforcing rings on the outer housing, as it is nearly impossible to 3d print something with the required material properties in a single print.  At this point, all of these components should just be made of aluminum like the others.
  • Repairability: Once the mk1 was assembled, there was no way to disassemble it, as installing the stator interfered with the ability to remove the outer housing, and the outer housing in place interfered with the ability to remove the stator.
  • Convenience: The mk1 servo used the r3.1 moteus controller, which had RS485 connectors sticking straight out the back, and bare power wires coming out the back.  That orientation for connecting things was not terribly convenient in the full rotation leg design, and required making extension cables.  The newer moteus controller has the connectors sticking out the bottom, so the servo needs to accommodate that.

CAD explosion

CAD rendering

Changes in moteus servo mk2

The current design for the moteus servo mk2, as the exploded video above shows, has a number of changes.

First, the outer housing has been changed to be purely cylindrical.  This allows it to be machined out of round tube stock, and also assembled and removed in any order.  Thus the front housing now has a slightly larger outer diameter, and has threaded holes around the perimeter and 8 primary mounting holes instead of 6.

The rotor is custom machined, so that the sun gear holder assembly is no longer required.  A not shown in the explosing mini 3d printed adapter will hold the magnet and fit inside the rotor bearing on the back.

The planet input now has a small indexing slot to eventually register a magnet holding assembly that can be used to sense the position of the output stage, and a position sense board is installed in the front housing to sense it.

All of the gears are now custom manufactured (at – Internal Gear, Planet Gear, Sun Gear).  This reduces the cost considerably, improves tolerances, and requires no post-machining.

The back housing has been updated to mount a newer moteus controller, provide heatsinking to it, and also be slightly slimmer due to being manufactured from aluminum.

The overall dimensions are approximately the same as the mk1, with the depth increasing by a few millimeters (largely because of the connectors on the new moteus controller), and the outer diameter decreasing by a few millimeters.  I believe I should be able to get the weight to be about the same as the mk1, around 430-450 grams.

Next steps

First, I’ll make a functional prototype to verify that all the parts fit together and work.  Then I’ll work to get the weight back down to closer to the mk1, after which I’ll start producing enough of these to make more robots.

Thread milling on the Pocket NC v2-50

To date I’ve managed to not do any threading on the parts I’ve made on my Pocket NC v2-50.  However, I’m about to do a number that require both M3 and M2.5 threads, so I figured it was time to figure out how to do it.

Online tutorials are kinda all over the place in both how you handle things in the model, and how you program the CAM.  Some assume you model threads as a hole of the major diameter, some as a hole of the minor diameter, although none that I could find used the new Fusion 360 “threaded” hole type, which is what I wanted to use.  That said, using the “threaded” hole type appears to be treated basically as a minor diameter hole with a minor caveat.  You would expect that since Fusion knows the minor and major diameter, the “pitch diameter offset” would be relative to a zero tolerance thread, but in fact it appears to be relative to the minor diameter as if you had modeled a minor diameter hole.  Oh well, I just experimented with increasing pitch diameters until I had threads that fit relatively tight for the two that I cared about, which fortunately can be both made using identical tools, although the M2.5 hole is only on the edge.

M3 M2.5
Tool Datron 2mm single 5mm flute 0068620G “”
Stickout 14mm “”
Feedrate 400 mm/min “”
RPM 42000 “”
Ramp Angle 2 deg “”
Stock to leave -0.02mm 0.0mm
Top height +1.0mm “”
Bottom height -0.5mm “”
Tool Shars 1/8″ 90 chamfer 416-3509 “”
Stickout 18mm “”
RPM 8500 “”
Chamfer width 0.1mm “”
Chamfer tip offset 0.25mm “”
Tool Lakeshore Carbide 3-SPTRMLB “”
Stickout 16mm “”
Feedrate 300 mm/min “”
RPM 10000 “”
Pitch 0.5mm 0.45mm
Pitch diameter offset 0.538mm 0.430mm
Stepovers 10 7
Stepover 0.05mm “”
Top height +1.0mm “”

Interestingly, Fusion’s simulation reports that the M2.5 holes have a collision when inserting the threadmill, not on the first couple of insertions, but on the 4th and subsequent ones.  This does appear to occur in real life too, as you can hear slight interference when the tool is inserted.  I don’t fully understand this, as I would expect Fusion’s CAM to just stick the tool down the middle the same way each time.


Here’s a video machining a few M3 and a few M2.5 threads in the same operation, then testing them out.

Ramping up for moteus servo mk2

Some time ago I put in orders for all the long lead time items on a second version of the moteus servo.  This is primarily aimed at improving the manufacturability and reliability, along with some minor performance improvements.  I’ve now got at least samples of all the long lead time parts in house!

Loads of bearings
A lot of custom gears
A sample batch of custom rotors and stators

Coming up soon I’ll post a more detailed design update on the servo.


Successful pronking!

While not perfect, now that I have flux braking in place, I have now succesfully pronked around for a while without faulting!  There are a number of outstanding problems that still need to be addressed:

  • Sometimes the landing phase is erroneously cut short
  • There is occasionally a grinding like noise that sounds like some controller is unstable
  • I think the lateral movement is not working correctly
  • The gait needs to be smarter about moving the legs past the center point when in mid-flight, and changing the gait period to achieve different speeds
  • And probably a bunch of other problems I haven’t even identified yet

That said, it is still fun to watch it romp around!

quad A0 chassis v2 – final assembly

In the last post in this series, I conducted a fit test on the new chassis.  After my ignominious belly-flop, I now had a more urgent need to complete the switch.

A busted robot
An even bigger close-up

The chassis cracked in the corner, completely separating.  Doing anything more with this chassis was likely to result in many more things breaking very quickly.

Build process

So, here are the photos as I put everything together.

Raspberry pi attached
All the wiring extracted
Half the legs off the old chassis
Legs re-attached to new chassis!
Battery stud and wiring re-installed
The power board installed
Bottom plates installed
Upright with untidy wires
All set for testing!

Next up is continuing to try and get pronking working!


Flux braking with the moteus controller

When I was trying my first pronking, I kept having over-voltage issues when the servos were trying to dump power back onto the DC bus, no matter how high I set the voltage limit.  During that test, I was running with a nearly full battery, so my working theory is that the battery protection circuit was disconnecting the battery either because of too high a charging current, or too high a system voltage.  When the battery was disconnected, and the servos were still putting power onto the bus, that resulted in the voltage spiking arbitrarily high, followed by a total loss of power when they all faulted and then nothing was powering the bus at all.

Clearly I needed somewhere to dump the power during those transient events.  One option would be to build a brake chopper, sticking a power resistor somewhere and using that to burn off the extra.  But, why bother with that when I already have 12 big power resistors attached to the robot!  Errr… motors that is.

Anyways, my solution for now is to create a “virtual resistor” in the moteus firmware  i.e. “flux braking” that just dumps current into the D-axis of each motor proportional to the magnitude of the DC bus voltage above some configurable threshold.  That results in each servo working independently to keep the overall system voltage from getting too high in a hopefully stable manner.


I ran the programmable power supply through a voltage sweep while commanding zero velocity on all 12 joints to verify this was working as expected.  It did get pretty audibly noisy at the higher voltages, probably because of some feedback with the voltage sensing so I added a little filtering after which the noise was manageable.

HTML + websocket joystick control

Now that I had a controlled jump with the quad A0, I wanted to chain those jumps together into a pronking gait.  The first part of that was creating a mechanism by which I could actually command varying motion commands.  For the previous full rate experiments, all I had built was a CLI that allowed you to type commands.  That sufficed for initiating a single jump, but not really for moving around in space with a dynamic gait.  Something with a joystick would be necessary.

For Super Mega Microbot, we had a Mech Warfare dedicated client application which, for various reasons is something I want to get away from and its control protocol isn’t even that suited to the things that the quad A0 is capable of anyways.  For the quad A0 I want to eventually have 2 command and control systems: a high bandwidth one that uses wifi, and a low bandwidth robust one that uses a spread spectrum RC style transmitter.  For now, I figured I would start by making a first minimum viable product of the high bandwidth diagnostics tool, since it would be more useful initially.


The intended system roughly looks like this:

quad A0 diagnostics architecture.png

The client in this case is a regular web browser.  It connects to the embedded web server which is running in the robot control process and fetches some static assets, including HTML, CSS, and Javascript.  Then, the diagnostics client is a single page javascript application which makes a separate websocket connection to the embedded web server for real-time control and status data.


Initially, I spent a half day making a standalone proof of concept server and client.  The server was based on boost::beast / boost::asio and the client was vanilla JS using the gamepad API.  All it did was render the state of the joystick into a text string at 10Hz, stick that into an HTML element and send it over the websocket connection.  Anything it received over the websocket connection it stuffed into a different HTML element.  The server just sent an incrementing number over.  Once this was working mostly well enough, I felt confident enough to move on and integrate it into the actual robot control application.

For that, I implemented a more generic “WebServer” class which just serves the static files and accepts websocket connections at configurable endpoints.  Then a separate “WebControl” class uses WebServer to report the quadruped status and send commands.  For now, I just exposed the raw C++ status and command structures over the websocket interface as JSON, so the control class doesn’t have a whole lot of work to do.

On the client side, I spent zero effort on presentation, and just dumped raw JSON into HTML elements for now.  There is minimally enough logic to command the robot through the states that are implemented now based on joystick commands.  The result is just about the ugliest web application you can imagine, but it gives me a place to start from both to make it more functional, look nicer, and more importantly lets me once again use the joystick to command variable gaits.

HTML at its finest