Tag Archives: smmb

quad A0 chassis v2 – design

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 there are separate front and back plates, to which the shoulders can be attached in isolation.  Then the top plate can attach to that, followed by the side plates, the battery holder, and eventually the bottom plates.

Enclosing the electronics

V1 had the primary computer sitting on top of the chassis.  That was a legacy from the first Mech Warfare configuration, where the primary computer sat in the turret.  I’ve decided that for Mech Warfare, I’ll just put a second independent computer in the turret, which frees the robot computer to be placed inside the chassis where it is much less likely to get mangled.


The power distribution board is now mounted to the other side opposite the computer, instead of on the now top-plate.

Power switch and strap

I’ve left room for a recessed top mounted power switch on the top plate.  This should remove the need to unplug and re-plug the battery any time that power needs to be cycled.  That hole is marked in red below.


Also, while I’m at it, I left holes in the top through which a carrying strap can be threaded (marked in blue above).  The old chassis had some M3 inserts that I screwed eye bolts in and then threaded some cord through.  That didn’t work terribly well and was unsightly.


As mentioned in the roadmap, I was going to try and replace the battery with something with a smaller form factor.  I looked through a number of batteries, and got a Milwaukee M18 as the best of the options, but ultimately decided that the Ryobi style was the best compromise for now despite the wasted space.  All the lower profile ones required insertion sliding in from the side, which would have required that the chassis be much longer than it was already.


Thus, I still have the 3D printed Ryobi battery holder, only now it attaches to the top plate with just some bolts instead of a complicated dovetail arrangement I had previously.



Since this is being printed in multiple pieces, I wanted a separate piece to increase the longitudinal stiffness.  That is now just two plates which bolt to the front and back plate, and to the battery holder.


Next steps

Next up is printing and assembling this chassis!

DART now in bazel_deps

A previous simulator I had built for Super Mega Microbot was based on the “DART” robotics toolkit.  It is a C++ library with python bindings that includes kinematics, dynamics, and graphical rendering capabilities under a BSD license.  I wanted to use some of its dynamics capabilities for future gait work on the quad A0, and eventually re-incorporate its simulation capabilities, so integrated a subset of it into mjbots/bazel_deps.

mjbots quad A0: October 2019 Roadmap

My last video gave an overview of what I’ve accomplished over the past year.  Now, let me talk about what I’m planning to work on going forward:

I intend to divide my efforts into two parallel tracks.  The first is to demonstrate increased capabilities and continue learning with the existing quad A0, and second is to design and manufacture the next revision of all its major components.

New capabilities and learning

The first, and most important capability I want to develop is an improved gait and locomotion system.  While the moteus servos in the quad A0 are capable of high rate compliant control, the gait engine that I’m using now is still basically the same one that I made for the HerkuleX servos 5 years ago.  It just commands open loop positions to each of the servos and uses no feedback from the platform at all.  This severely limits what the robot can do.  For instance, if the terrain is not level, legs will drag on the ground or it will not walk at all.  The maximum speed is relatively slow and achieving it requires careful tuning of servo-level gains.  While it is more robust than nearly any other open loop 4 legged walker while standing up, even small disturbances can cause it to fall over.

At a minimum, I’d like to switch to controlling the position and force of the endpoint of each leg and switch to a gait engine that takes into account the actual position of each joint during the gait cycle.  That should enable it to maintain good ground contact with all feet that are intended to be in a stance position.  Now, often feet will skip around, as the servo gains are all relatively high to account for the lack of feedback.

The next level would be to take into account an IMU to ensure balanced feet lift offs.  While I have an IMU in this configuration, it currently isn’t usable due to my improvised attempts to improve the overall system update rate.  I’ll need to update some of the hardware to get an IMU again before I work on this part.

New hardware revisions

I have learned a lot with the moteus controller, servo, and the quad A0 over the last year.  I’d like to take that learning and update the components to achieve:

  • Manufacturability: Many of the sub components now are very labor intensive to produce or assemble.
  • Cost: I have in many cases made things much more expensive than they needed to be in order to shave a bit of time off the prototyping process.  Also, I have enough confidence now to get larger volumes of parts, which further reduces cost.
  • Capability: There are many easy areas where the system performance can be greatly improved.

My overall goals are to make a system that is capable and affordable — to provide an ecosystem of parts and systems for researchers and hobbyists to use.  That means keeping everything open source, and providing access to all subcomponents and designs while still being able to provide a complete system that is capable out of the box.

Here’s a quick rundown of the various areas I’m tackling:

Moteus controller

My next revision of this controller will be a slightly bigger change, in that the form factor, the microcontroller, and the connectors used will all be altered.  I’m planning on switching to an STM32G4 for the controller, using daisy-chained connectors for power in addition to communications, switching to FD-CAN for communications, and reworking the form factor to enable all the primary connectors to exit from one edge of the servo.

Also, I’ll take this opportunity to design for automated end of line test.  That means I will leave enough probe points such that a test fixture can validate the correct operation of a board without intervention.

I don’t anticipate the performance to change a whole lot, although I may increase the allowed input voltage.  Even so this will still be a very capable board, with 3 phase current sensing, >=50A peak phase current, >= 400W peak power and a switching and internal control loop rate of >=40kHz.

Moteus servo

The first round of gearbox servos went through many revisions to achieve something that was functional.  That said, while functional, they are fragile, and require about a full man day of assembly time per servo.  I’m working to get pre-production volumes of around 100 units for all the components such that no post machining will be required and the servos can just be assembled together.

While I’m at it, I intend on switching everything to metal from 3d printed plastic, and reducing the overall dimensions.  It is likely the mass will increase a little from the current 410g, but I’m hoping that it won’t be that much compared to the increased strength and rigidity.

Junction board / raspberry pi 3 hat / pre-charge board

I intend to rework the architecture behind the power and data distribution internal to the quad A0.  Currently there is a raspberry pi3 hat, which merely powers the raspberry pi and provides an RS485 interface.  Then a “junction board” splits out the RS485 bus into four separate connectors as well as splitting out power to all four legs and housing the IMU.  Finally, a separate “pre-charge” board ensured that the servos can have power applied safely.

I intend on moving all data distribution and the IMU onto the board that mounts on the host computer.  Thus it will have power in, an IMU, and 4 (or maybe more) CAN bus outputs.  Then, a separate power distribution board will include the pre-charge circuit as well as connectors for power for all four legs.  Simultaneously, I plan on adding an actual power switch, so that I don’t have to keep pulling the battery in and out to cut power.


The quad A0 chassis is a single monolithic 3D printed block.  Actually attaching legs to this is nigh impossible.  It takes a long time, and not all of the joining screws can actually be used because of interference with other pieces.  Also, using the Ryobi style batteries results in a lot of dead space due to the mounting stud.  I am planning on switching this chassis to be printed in multiple components that are assembled together with screws and threaded inserts and switch to a battery form factor that is more compact.

That should also allow for mounting the primary computer inside the chassis, and still leave enough room for a bigger computer, like an NVIDIA Jetson nano.


I’ve already had one failure in the current iteration of the leg that indicates some redesign is necessary.  Also, the two primary brackets that connect the shoulder to the upper leg, and upper leg to lower leg should be made from aluminum instead of being 3d printed.  Those brackets had to be really big and printed in odd orientations in order to be strong enough, and they could be a lot lighter, more convenient, and more cost effective in metal.

Looking forward

Thanks for all of your positive feedback so far, and I look forward to more exciting times executing these plans!

Quadruped robots: One year in!

While I’ve been working to some degree on quadrupedal robots for the last 5 years, it has been just about 1 year since I kicked up my effort a notch, with my post about improved actuators for SMMB.  I figured it was a good time now to produce a video summarizing what I’ve gotten done over the last year:

Concurrently, I’ve posted a “state of the project” text update on hackaday.io, just to get a wider readership.  If you’ve been reading here all along, there won’t be anything terribly new there, but it is a decent summary of where I stand.

Oh, and I’ve decided to give the robot a more memorable name for now.  The “mjbots quad A0”!  Yeah, I’m no marketing whiz, but it will suffice.

Coming up next, is a brief roadmap of where I plan on focusing my efforts in the next 3 to 6 months.


Improved startup shutdown kinematics

Back when I was getting Super Mega Microbot “Junior” ready for Maker Fair Bay Area 2019, I made it minimally self sufficient through a quick hack of adding some PVC pipe that allowed it to manipulate its feet into a known good position while the robot was safely up in the air.

This worked, but had a number of obvious disadvantages.  For one, it looked ugly!  Second, the machine couldn’t squat down very far before getting stranded on the “resting legs”.  I’ve finally gotten around to doing at least a first attempt at something better!

The basic problem is that normal gaits result in having the feet positioned under the robot.  Then, if you want to sit down, you can’t do it because your feet are in the way.  What I’ve done for now is have the robot take some steps to widen its stance so that the feet are out of the way, then sit down.  Standing up is the inverse.  First the feet are positioned in the widened stance, lowered until the machine is at the correct height, then some steps are taken to get into the normal walking gait stance.

At this point, even this is somewhat of a hack, because the gait generation code is only minimally modified from what I had back in 2014.  When it gets modernized, this standing up procedure will need to be re-implemented, but for now this will let me both lose the ugliness, and experiment with things like bigger jumps.

Enjoy seeing it do its thing in the video below:

Improving the moteus update rate, part 4

In part 1, part 2, and part 3, I looked at what was limiting the update rate of the moteus controller when built into a quadruped configuration and how to improve that.  Now, it is time for the final demonstration!

That video was shot with a 150Hz overall update rate.  The plot shows the commanded and actual position of the three joints in the front right leg, although not all to the same vertical scale.  Updating the servos themselves only used about 3.5ms per cycle, but the gait logic used another 1-1.5ms, which made hitting 200Hz not super reliable, thus running at 150Hz.

Future work

I would still like to be able to perform 1kHz full system updates.  These experiments have let me come up with a plan that I think will achieve that with plenty of margin from the servo side in the next revision.

  • Switch the controllers to use FD-CAN:  I had initially not used CAN as the communication mechanism because I didn’t want to be limited to 1Mbps and 8 byte frames.  However, recent STM32 controllers come with FD-CAN support, which allows up to 64 byte frames and 8Mbps.  The hardware FD-CAN receiver implements CRCs for free, should be more reliable, and manages some amount of pre-filtering and processing, which should further reduce the turnaround time of querying a device.
  • Integrate with the host computer over SPI: While I was able to make serial work by busy loop polling on a dedicated CPU, the SPI bus has an even higher possible bitrate and even if its kernel driver is just as problematic, it can still be polled in the same way.
  • Operate 4 separate busses:  This will be done by having probably 2 STM32’s on the host computer daughterboard, each managing two busses.  This way each leg will have its own CAN bus.


First quadruped jump!

To demonstrate the dynamic capability of the full rotation quadruped, I figured I would start by doing some full machine jump tests to a relatively low height, just to show that it was capable.

Thus, I rigged up an open loop script which squatted a small fraction of the available distance, and then powered up at a relatively small fraction of the available maximum speed.  I don’t have the telemetry yet to extrapolate how high this will be able to go at maximum, but I think it should be a fair amount higher.  For now, I want to do some more instrumentation and walking testing (and have more spares) before I manage to break things by jumping really high.

First walking on the full rotation quad

Last time, I had finished physically assembling all the motors for the updated quadruped with legs that can rotate freely 360 degrees.  After the long summer break, I powered up and configured all the servos.  Then, after setting up the gait engine for the new configuration (for which there are still a TODOs when the lateral shoulder offset is non-trivial as in this configuration), I was able to achieve some amount of walking.  Here is one of the first videos I took, without much in the way of tuning or work.  The control is a little wobbly still, but so far there are no signs of any mechanical failures as with the older design.


Full rotation quadruped build continued

The next step in (re-)building the quadruped with a full rotation leg was getting all the motors ready.  I had to first install reinforcing rings on 6 of the motors:

My epoxying station
4x gearboxes with reinforcing rings installed

Then, I needed to lengthen the power leads on 3 of the motors to serve as the lower leg joint.

Motors with longer power leads

Then I had to assemble all the new legs:

Upper leg joints mounted
Lower leg joints mounted
All three remaining legs built

I mounted them all to the chassis:

All the legs!

And then re-installed the battery stud and “resting” feet:


Next up, will be actually powering them and getting it to walk!