# Brushless actuator control board, r2

The first revision of the brushless servo control board for SMMB was successful in getting a leg to jump.  I ended up doing a small-run second revision that addressed a few minor problems and added a couple more capabilities.

• RS422 Debug/Link Port: I had a 3.3V serial port exposed previously for debugging, however it caused my USB-serial converter to dislike itself due to common mode ground shifts and it wasn’t reliable at high baud rates (>3Mbps).  I also wanted to support “linked” modes, where two servos would perform control in the actuator space at full rate.
• Debug through holes: r1 had a number of debug connections, all of which were unpopulated SMD pads.  I decided that through holes were easier to connect debug wires to.
• Vertical SWD connector: I had initially thought I would hide the SWD connector within an enclosure.  However, the initial enclosure prototypes made that seem less desirable, so I switched it to vertical.
• More debugging points: When bringing up the first board, I ended up doing a lot of carefully balancing scope probes on various pins, when there was plenty of board room to just have through hole debug points.  Lesson learned.
• FET temperature sensing: r1 just had an external temperature sensor port, r2 additionally has a thermistor next to the FETS.

Macrofab’s current pricing scheme provides a great incentive to keep your BOM below 20 parts, as that is the only way to get quick turn service.  Otherwise you pay an extra 2 or 3 weeks of calendar time.  In r1, I went to some lengths to stay under 20, however, it just wasn’t going to work with r2, so I left a few easy-ish or non-critical parts unpopulated to do them myself: the connectors, LEDs, and one really big diode.

# Pinions, set screws, and glue

One of my intermediate goals for building new actuators for SMMB is to get them robust enough to jump continuously for some duration of time.  Progress is slow, as things break, new parts are ordered, repairs are made, and jumping resumes.  The most recent failure is at least interesting enough to me that it is worth writing up.

To recap, I’m building a brushless servo based around a Turnigy Elite 3508 brushless motor and a custom 5x planetary gearbox.  The 3508 is intended for quadcopter applications, so to install a spur gear I first extracted the original shaft, then pressed in a new shaft with two flats on it.  One flat for the set screw attaching the rotor to the shaft (which had a press fit), and a second for the set screw attaching the spur gear to the output of the shaft.

While jumping, the set screw holding the spur gear kept freeing itself, no matter whether thread lock was applied or not.  In retrospect, the reason should have been obvious.  In all my previous RC motor experience, pinions were attached with set screws and a slip fit.  However, all those previous applications also used a motor that spun fast with a high ratio gearbox, so the actual torque applied to the motor shaft through the spur gear was relatively low.  In this application, with just a 5x gear reduction and relatively large amounts of torque, the spur gear was seeing torque on the order of 1 N*m.

As the internet will tell you, set screws are not an appropriate attachment mechanism for anything but the smallest of loads.  Even with a shaft with a flat, the entire torque load ends up being concentrated in just one tiny bit of the set screw until it elastically deforms and eventually either destroys or frees itself.

Ben Katz, who built the inspiration for this work, used a shrink fit to attach the spur gear to the motor.  I knew that, but didn’t have sufficient machining tolerances easily available to me to make that happen.  Other simple mechanical options, like a dowel pin didn’t seem like they would be that much more effective than the set screw.

What seemed like more of an option after a little calculation, was glue!  Or rather, LOCTITE 680 brand retaining compound .  The shaft is 4mm in diameter, and the spur gear covers about 8mm of the shaft’s length.  That means there is $\pi * 4mm * 8mm =100mm^2$ of contact surface area.  A 1 N*m torque at 2mm radius thus results in $1 N*m * 2mm / 100mm^2 ~= 5 MPa$ of shear strength required.  LOCTITE 680 has a shear strength when cured of approximately 25 MPa, which gives a 5x safety margin.

Retaining compound was applied, jumping recommenced, at least until the next thing broke…

# Slow motion leg jump

After the initial leg jumping with the prototype brushless actuator for SMMB, I spent some time actually tuning the control loops and making the firmware not incredibly convoluted to get started.  I also acquired a high speed camera for analysis.

So, here is a brief update of the final jump before I seem to have toasted one of my DRV8323 motor drivers.  It jumped for about 400ms of hang time, running at about half of the maximum current the system should be capable of pulling.

# More robust jumping fixture

In my first foray into 80/20, I built a slightly more robust jumping fixture for the SMMB leg jumping test:

Overall it is much more rigid than the old one, and looks a little nicer.  To top it off, I laid down a neoprene sheet for surface protection and friction enhancement, which is a step up from the old cardboard surface both in aesthetics and function.

# First day jumping!

I continue to make progress on the improved actuators for SMMB.  To briefly recap, these are based on a home-built brushless servo consisting of off the shelf gears, bearings, 3d printed assemblies, and a custom control board.

Moving on from closed loop vector (FOC) control, I’ve now built up a second motor, set both of them communicating over the same RS485 bus, and wired up a minimal makeshift jumping fixture.  The leg didn’t jump as well as I had expected: I was only able to achieve about 300ms of air time and there are a lot of other minor problems/deficiencies as well.  But on the other hand, I don’t appear to have permanently broken anything yet, so improvement will hopefully be mostly continuous!

Obligatory video:

# First closed loop vector control

I’ve reached a minor milestone in developing improved actuators for Super Mega Microbot.  Previously I demonstrated basic closed loop control using a VESC.  Now I have a custom control board running closed loop vector-based current and position control on a single brushless servo!  I’ll hopefully write up pieces in more depth later, but this post can serve as a proof of existence.

First, boards as received from MacroFab:

Mounted onto the planetary gearbox:

And finally, a brief video of operation, with tview (from the mjmech gimbal) alongside.

Amazingly, I’ve needed no blue wires or rework of any kind so far.  Next up is to get it communicating over the RS485 link instead of serial, build a second gearbox, and get it jumping!

# rules_mbed – bazel for mbed

When working on the firmware for Super Mega Microbot’s improved actuators, I decided to try using mbed-os from ARM for the STM32 libraries instead of the HAL libraries.  I always found that the HAL libraries had a terrible API, and yet they still required that any non-trivial usage of the hardware devolve into register twiddling to be effective.  mbed presents a pretty nice C++ API for the features they do support, which is only a little less capable than HAL, but still makes it trivial to drop down to register twiddling when necessary (and includes all of the HAL by reference).

Most people probably use mbed through their online IDE.  While this is a remarkable convenience, I am a big fan of reproducibility of builds and also of host based testing.  mbed provides mbed-cli which gets part of the way there by letting you build offline.  Unfortunately, it still doesn’t provide great support for projects that both deploy to a target and have automated unit tests.  It actually has zero support for unit tests that can run on the host.

## Enter bazel

As many have guessed, I’m a big fan of bazel https://bazel.build, for building software projects.  Despite being raw around the edges, it does a lot of things right.  Its philosophy is to be fast, correct, and reproducible.  While it doesn’t support flagless multi-platform builds yet (#6519), it does provide some minimal multi-platform support.  It also has robust capabilities for pulling in external projects, including entire toolchains and build environments.  Finally, it has excellent support for host based unit tests.

To make it work, you do have to configure a toolchain though.  That I’ve now done for at least STM32F4 based mbed targets.  It is published under an Apache 2.0 license at: https://github.com/mjbots/rules_mbed

## rules_mbed features

• Seamless toolchain provisioning: It configures bazel to automatically download a recent GNU gcc toolchain from ARM (2018q2).
• Processor support: Currently all STM32F4 processors are supported, although others could be added with minimal effort.
• Host based testing: Common modules that rely only on the standard library can have unit tests run on the host using any C/C++ testing tools such as boost::test.
• Simultaneous multi-target configuration: Multiple targets (currently limited to the same CPU family) can be built with a single bazel command.  Multiple families can be configured within the same source tree.

Once you have it installed in a project, building all host based tests is as simple as:

tools/bazel test //...

and building all binary output files is as simple as:

tools/bazel test -c opt --cpu=stm32f4 //...

# Shapeways dimensional tolerances

The first version of the planetary gearbox as 3d printed from Shapeways required a fair amount of post-machining to get all the pieces to fit together.  I wanted to get to a point where I could just order some parts and have a reasonable expectation of them mostly working out of the box.  To make that happen, I’d need to get a better understanding of where the tolerances were coming from.

## Understanding the problem

Shapeways provides a fair amount of documentation on the processes and accuracy you can expect generally.  Most of this is detailed in “Design rules and detail resolution for SLS 3D printing“, however the results there have some limitations.  Primarily, they are only applicable to the specific geometries tested.  Shrinkage is qualified as +- 0.15% of the largest dimension, and is likely influenced by the exact printed geometry.  Secondarily, in the documented tests, the designers had full control over the part alignment in the print.  The standard shapeways platform does not allow you to orient parts, you are at the whim of their technicians where the Z axis will end up.

For the gearbox, I had numerous fit points that needed to have controlled tolerances.  The input and output bearing both needed a press fit for both sides.  The internal gear for the planetary gearing needed a press fit, and the front and back shells also have a lip which would be more rigid if the fit was snug.

## Brute force

My solution?  Print slight variants of the relevant pieces of each fit point with each radial dimension printed in increments of 0.1mm.

For each part, I broke out the calipers to measure the as printed size, and also attempted manual press fits of each part.  I didn’t manage to put any identifying features on each of the prints, which probably annoyed the Shapeways technicians and made my life a bit harder.  I just assumed that the sizes came back in increasing order despite the part number markings, which I’m pretty sure were incorrect.  This resulted in the following table:

## Conclusion

The second version of the gearbox had many other changes in addition to these, but this let me get a lot closer to the correct fit on the full assembly.

# Improved actuators for SMMB

One of the major challenges SMMB had in Robogames 2016 was in overall walking speed.  It is using HerkuleX DRS-201 servos, which are roughly comparable to the Dynamixel servos that other entrants were using, but the physical geometry of the robot is such that is hard to get it to move quickly with that class of servos.  The center of gravity is too high, especially with the gimbal mounted turret. The R-Team bots all use very low slung machines that scoot along.  I could go that route, but why do things the easy way?

Instead, I’ve been working to take some ideas from fellow Boston-ite Ben Katz and build some actuators that would permit truly dynamic motion.  He got a leg jumping using Hobbyking brushless motors with some simple FOC control  The biggest differentiators vs the Dynamixel / HerkuleX class of actuators would be low mechanical inertia, high transient power, low backlash, and high speed.  I’m just getting started here, but have managed to build up a 5x planetary gearbox driven by a Turnigy Elite 3508 (so a fair amount smaller than what Ben did, but more appropriately sized for Mech Warfare), and a VESC 6 as an interim motor controller.  It is designed for electric skateboards, but has minimal position control support.  Although, as my bruised hand can attest, it isn’t super stable and flips out occasionally.

The first prototype is assembled and has been spun up, although a fair amount of dremel time and shims were required to get everything to fit together.

And finally, the pretty videos: