Tag Archives: actuator

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.

Shapeways Dimensional Tolerance Test
Shapeways Dimensional Tolerance Test

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:

Measured dimensional accuracy of gearbox parts
Measured dimensional accuracy of gearbox parts

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.

dsc_1056
Some SDP-SI gears for the prototype
dsc_1054
The 3508 with its stock shaft extracted
DSC_1057.JPG
New shaft installed, with spur gear alongside
dsc_1070
AS5047 wired up to the VESC
DSC_1072.JPG
Shapeways arrived!
dsc_1073
Housing mounted onto motor
dsc_1076
Planet carrier assembled
dsc_1077
Planet carrier inside housing
dsc_1081
Final assembled gearbox

And finally, the pretty videos: