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

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!

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.

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.

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.

Now that I can do controlled jumps, and have a UI which allows me to use the joystick, I finally started actually working towards pronking gaits.  Too bad for you, this post doesn’t have any details, merely a video snapshot of my learning and debugging process…

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.

After CADing up the second revision of the chassis, I set to work with the 3d printer and printed up all the pieces.

There were a few minor post-modifications I had to make, which were all much faster than printing the pieces again.  All the holes for M3 bolts were slightly undersized, so I drilled them out.  The battery holder had a channel to let the power wires out, which inexplicably terminated before reaching the edge of the holder.  I also had to install all the heat set inserts.

As described in my roadmap, the chassis for the quad A0 was on the verge of failing, or causing the shoulder motors themselves to fail, after only a few hours of walking around.  Also, it was nigh impossible to assemble, disassemble, or change anything about it.  Thus, the chassis v2!

More than one piece

The old chassis was a single monolithic print that took about 35 hours of print time.  Because of its monolithic nature, there were lots of interference problems during assembly.  For instance, the shoulder motors could only have 4 of the 6 possible bolts installed, and 2 more of the bolts extended beyond the chassis entirely.  I decided to break it up into multiple pieces, which uses a lot more inserts and bolts, but should allow for a feasible order of assembly and manageable repair.

Now that I have a full rate inverse kinematics and dynamics solution, I can begin to do more interesting things.  A while ago I did the first jump on the quad A0 – in that video I used a limited technique just to verify that the platform was indeed capable of jumping.  The joints were commanded in an open loop fashion, and really only at the transition points of the jump sequence, relying on the control loops in the servo to actually achieve each stage of the jump cycle.  That resulted in the jump only being minimally controlled… tracking errors would result in the robot taking off from a not-level position and the timing was not super reliable to boot.

Last time I updated my inverse kinematics solution to also include dynamics, velocities and forces.  Now I’m in the process of integrating this onto the robot.

The old SMMB / HerkuleX control software commanded the servo positions in an open loop, which did not take into account the actual position of the joints in any way.  What I’ve done now is implemented a control flow where at each cycle the state of all 12 servos is sampled, then the control laws are applied based on that state, then the resulting commands are sent out.