Tag Archives: actuator

BE8108 motor disassembly

To build the 8108 class gearbox with the geartrain inside, first I need to get the motor apart and separate out the individual pieces that I needed.  Here’s the first in a few posts about the modifications.

The original unmodified 8108 motor looks like:

Unmodified BE8108 Motor
Unmodified BE8108 Motor

To begin with, I needed to separate the rotor from the stator.  First, there is a small screwed on plate which needs to be removed — it just has normal Phillips head screws.

Front plate removed
Front plate removed

After that, the rotor is pressed onto bearings.  The magnets exert quite a lot of force on the stator, which makes removing them challenging by hand.  I wasn’t able pull it off with all the force available just from my arms.  For my first experiment, I built a simple fixture from two plates of aluminum and some bolts.

Motor in Removal Fixture
Motor in Removal Fixture

I bolted each half of the motor to one plate, and gradually tightened the bolts.  This eventually liberated the rotor from the stator.  Clearly something more robust and repeatable would be necessary to do this more than a couple of times, but this worked for a first iteration.

BE8108 gearbox

As mentioned last time, I’m working on a parallel track to accelerate my quadruped development efforts.  The current plan is to try and use a BE8108 class brushless motor, with a planetary geartrain mounted mostly inside the existing bounds of the motor.

Here’s a rough exploded view of the CAD model:

Key takeaways are:

  • The rotor and stator of the existing motor are disassembled, with the original back half of the stator discarded.
  • The rotor has its center drilled out.
  • All the non-gear/shaft/bearing parts are currently designed to be printed in plastic as a fit and function test.  That means things are thick and most holes that would be threaded instead have a big hole for a heat-set insert.  I’ll switch them over to aluminum once I get things basically working.
  • Metric modulus 0.5 gears are used; everything is stock with the exception of the 100 tooth internal gear which has a reduced outer diameter.
  • Bearings are used to interface all the rotating components.
  • The front plate mounts to the original stator and the internal gear, and acts as the primary outer housing.
  • Absolute position is measured via magnets attached to the planet input and a ring shaped PCB.
  • The back plate supports the back of the rotor.

If this looks an awful lot like Ben Katz’s model, that’s because it is!  The basic mechanism is the same, and a lot of the features are similar-ish just because it was easier to make something that looked roughly the same where it didn’t matter.

More details to come…


Quadruped lateral control challenges

So, after applying power to the robot for the first time, I coded up some simple scripted maneuvers I was going to use to work up to a gimmick jump video.  Unfortunately, I discovered that one of my assumptions was not well founded, and some more work will be necessary.


I started in on this project intending to create a semi-standard servo motor with integrated gearbox which could be used for all the joints.  The brushless motors I am dealing with are only just barely capable of their task without additional gearing.  Along that development path, I built some prototype integrated gearboxes for a 50 sized brushless motor, and even took some videos of it jumping.

However, the gearboxes I have built so far were not terribly ideal from a mechanical perspective.  Primarily, they were too wide, and also too heavy, for the amount of torque and power they used.  In trying to get a quadruped up and running as quickly as possible, I decided to try a parallel effort with nearly direct drive motors.  My experiments at the time indicated that it should be just on the edge of possible.  I had a full 3 degree of freedom leg jumping for several hours nonstop in that configuration (albeit with forced air cooling).  The plan was to use an 81 sized motor for the upper leg purely in a direct drive configuration, a 60 sized motor for the lower leg with a belt gear reduction, and a 60 sized motor for the lateral movement in a direct drive configuration.  I figured that the lateral axis didn’t matter that much for a first effort, as I wouldn’t be doing anything much dynamic, and if the machine is standing upright, no steady state torque is required at all from the lateral motors.

The problem(s)

When I powered up the whole machine for the first time, I quickly realized that there were problems with my assumptions.  While yes, the lateral servos were capable if the machine was perfectly upright, even small disturbances required significant amounts of torque.  Due to the geometry, as the disturbance grows, the torque required grows very rapidly.  It doesn’t have to be more than a few degrees off before the torque capability of the 60 sized motor is exhausted.

Here’s a quick video demonstrating the problems.  First, you can see the chassis oscillating about the yaw axis.  The actual position oscillation in the lateral servos is very small in that video, on the order of 0.3 degrees, yet it still results in noticeable chassis movement.  At the end, I push a little bit too much laterally, and one of the lateral servos faults for over-temperature.  They have to work really hard to compensate for what are relatively minor disturbances.

Secondly, the noise on the position encoder limits the amount of damping that can be configured in the position control loop.  With the initial gearbox experiments, I noticed no problems in this area at all.  However, in the direct drive version, with 5x less gearing, the position control stiffness and damping both got worse by an equivalent amount.  It was not possible to both have stiffness sufficient to keep the machine upright, while still damping out yaw oscillations.  Compounding the problem, turning up the damping to the maximum results in a large amount of audible noise as the position noise manifests as velocity noise, which manifests as commanded torque noise.

Possible solutions

I’m currently going down two parallel solution paths to attempt to get something that works.  The first, is just to swap the 60 size lateral motors in for 81 sized lateral motors.  This will give roughly twice the torque capability, although it doesn’t really improve the damping ability at all.  However, it is relatively easy.

The second is to accelerate my development efforts on a geared mechanism.  Since Mini-Cheetah was released, I was quite impressed by the idea to stash the gear train on the inside of an 81 sized motor, and I’m working towards adjusting my gearbox design in that direction.

While I’m doing both in parallel, they unfortunately both require waiting for more stuff to ship and arrive, as well as more process development.  Coming up, more details on the gearbox work.

moteus RS485 bootloader

After getting the whole robot assembled, I quickly realized that changing the firmware on each of the 12 servos was going to be a big annoyance.  Doubly so, because the lateral servo programming ports were unreachable with this chassis design without disassembly.  Thus, I bumped up a deferred piece of work to implement a bootloader that would allow for reflashing the primary application over the RS485 communication bus.

Pre-bootloader state

The moteus controller currently uses an STM32F446 controller, which has 512kb of flash memory.  The memory map pre-bootloader looked like:

Sector Size Purpose
0 16kb ISR
1 16kb PersistentConfig
2 16kb unused
3 16kb unused
4 64kb application
5 128kb application
6 128kb application
7 128kb application

The ISR section currently just contains the ISR table.  It really isn’t even used beyond the reset vector, as the application moves the ISR table into RAM during initialization.  The PersistentConfig section stores application settings and can be rewritten by the application.  The application binary itself is stored in sectors 4-7.

Bootloader design

Rather than have a standalone bootloader, I decided to just implement something that assumed the controller was already configured properly and would be invoked directly from the application code.  This has some advantages and disadvantages.  The ups are that it means the bootloader can be much smaller.  I don’t have to duplicate the setup code, or manage how to share settings like what the current baud rate or multiplex ID are.  The downsides are that if the application code is bricked, then there will be no way to flash new firmware aside from the SWD port.  Given that using the SWD port on rare occasions isn’t that big of a deal, I figured this was a fair trade.

As far as placement goes, I figured that sector 3 was a fair place to stick the bootloader for now.  In the future, you could imagine saving a sector by putting it in sector 1, and actually hard-coding the ISR table to just include a reset vector.  Currently, some of the ISR vectors are defined in flash, and others by the application in RAM.  By forcing the application to define all of them in RAM, it means that there is no need to ever update the ISR table as part of updating the application.  For now however, it was easiest to leave the status quo alone and continue to consider the ISR table as part of the application.

Since the bootloader can assume the part is already configured correctly, it is implemented as just a regular C linkage function with a linker script that includes none of the normal pre-main or main initialization logic.  The application linker script forces that symbol to be defined at the start of sector 3, so that it can be just called as a regular function, albeit one that never returns.

The result

The resulting source is in a single translation unit (bootloader.cc / bootloader.h), although it does use some of the common libraries to help interoperate with the RS485 based protocol that moteus uses.  I haven’t really tried to optimize the size at all, but it clocks in at 3900 bytes, which is well within the 16kb for sector 3.


moteus_tool has been enhanced to drive the flashing operation and doing all 12 servos currently takes around 5 minutes with no cable plugging or disassembly required.  I could speed that up in a number of ways, but it is good enough for now.

First time powering all the motors!

After getting everything wired up and mechanically assembled, next was zeroing all the encoders and doing the first position control.  I discovered a number of problems that turned up by having a full 12 servos on the bus at the same time, which were resolved pretty easily, as well as many more pain points which I’ll need to address.

But, here is the pretty video (it ends when I push down enough to over-current my lab supply):


Assembling all the legs

Last time we had a dozen motors, controllers, and brackets assembled.  In this installment we’ll build up the mammal legs.

First is mounting the upper leg and upper pulley on each motor and assembling the lower leg:

Partially assembled legs
Upper leg, pulley, and lower leg assembled
Lower leg close-up
Lower leg close-up
Upper leg close-up
Upper leg close-up
Upper pulley close-up
Upper pulley close-up

Then we stick the upper leg, pulley, and lateral motor together, leaving the lower leg loose:

Four mostly assembled legs
Four mostly assembled legs

Next I created wiring harnesses to connect all the pieces together:

Leg wiring harnesses

And finally, put them all together!

Next time, we’ll mount everything up on the chassis.

Assembling individual actuators

Now that I have all the parts in hand, and all the controllers populated, it is time to start the big build!

First up was installing magnets on all the motors:

Motors with magnets attached

Next up is mounting the motors into the brackets:

Motors mounted in brackets
Motors mounted in brackets

Then I soldered the phase wires onto each of the motors, including shortening the BE8108 wires:

Controllers soldered to motors
Half the controllers soldered to motors

After that was thermal pasting and bolting the controllers to the brackets.  The BE8108’s I got for this run were slightly different, and required more spacing of the sensing magnet.  Thus I ended up using two heatsink plates back to back.  At this point I powered, flashed, and calibrated each of the motors.


Next up, the remainder of the leg hardware!


Populating r3.1 moteus controller boards

I am a big fan of MacroFab.  They’ve built a PCB + assembly + more service that is transparent, high quality, and nearly completely self service.  They appear to be making money, so hopefully they will stay in business for some time.

On top of that, they offer a “quick turn” option which gives you populated boards shipped 10 business days after you order them (and I’ve even had them ship out a few days early from time to time)!  The only annoyance is that the quick turn option is limited, as I’ve mentioned before, to boards that meet certain criteria, among them having 20 or fewer items on the bill of materials.  To try and get this first quadruped prototype up and running quickly, I’ve been exclusively relying on quick turn boards, which means making some compromises.  Even after some moderate design sacrifices, I haven’t been able to get the servo controller board to 20 parts.  At the moment it is 23.  Thus, when I received the first big-ish PCB order I’ve made (qty 28), I got to spend a morning populating the remaining 3 components on all 28 boards.

Unfortunately, as painful as that was, it was still worth it as opposed to waiting an additional 3 weeks for the non “quick turn” service.

For posterity’s sake, the only difference between the r3 and r3.1 board is some silk screen changes, and one or two equivalent part substitutions.


All parts received!

I’ve now managed to get all the custom and long lead time parts in house for the first version of a quadruped based on the new actuators I’ve been designing.

All The Parts!
All The Parts!

That includes all the motors, custom brackets, and at least moderately working versions of all the custom PCBs.  Now I just have to get the local rework done, get the software into a semi-reasonable state, and put it all together!