# 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!

# Configuring bazel to cross compile for the Raspberry Pi 3

In the previous post, I described the motivation for switching the mjmech build system to bazel.  For that to be useful with Super Mega Microbot, I first had to get a toolchain configured for bazel such that it could produce binaries that would run on the raspberry pi.

All the work in this post is publicly available on github: https://github.com/mjbots/rpi_bazel

## Compiler and sysroot

First, I needed to pick the compiler I would be using and how to get the target system libraries available for cross compilation.  In the past I’ve always done the gcc/binutils/gnu everything cross toolchain dance, however here I thought I would try something a bit more reproducible and see if I could make clang work.  Amazingly, a single clang binary supports all possible target types!  clang-6, which can be had through a PPA on Ubuntu 16.04 and natively on Ubuntu 18.04 supports it out of the box.

For the target system libraries, I wrote a small script: make_sysroot.py which when aimed at a live raspberry pi, will extract the Linux kernel headers and glibc headers and binaries.  These are stored in a single tar.xz file, with the latest version checked into the tree: 2018-06-10-sysroot.tar.xz.

## Bazel configuration

bazel has a legacy mechanism for configuring toolchains, called the CROSSTOOL file.  It is not exactly pretty, is moderately underdocumented, but at least there are a few write ups online for how to create one.  The CROSSTOOL I created here is minimally functional, with options for both host/clang and rpi/clang with a few caveats:

1. It isn’t hermetic, it relies on the system installation of clang
2. It includes hard coded paths to micro releases of clang
3. The C++ main function isn’t handled correctly yet, and you have to ‘extern “C”‘ it to link applications

With a functioning CROSSTOOL, the next step is to declare the “cc_toolchain_suite” and “cc_toolchain” definitions.  Those are defined in the tools/cc_toolchain/BUILD file and don’t have anything particularly complex in them.

Finally, I created a repository.bzl which is intended to be imported in client projects.  This provides a relatively simple API for a client project to import the toolchain, and gets the sysroot extracted properly.

## Using it in a bazel project

The top level README gives the steps to use the toolchain, which while not too bad, still requires touching 4 non-empty files (and 2 possibly empty files).  Once that is done, you can use:

bazel test --config=pi //...

To build your entire project with binaries targeted to run on the raspberry pi!

# 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:

# Raspberry Pi 3 B+ for SMMB

Super Mega Microbot, that beloved and neglected creation, is due for a facelift. The biggest challenge we had at the last competition was the instability of the USB bus on the odroid-U2 when we had both a USB camera and USB 5GHz wifi adapter attached. Cue 2.5 years of waiting, and one aborted attempt, and it looks like the problem is solved!

## The aborted attempt

The challenge in this problem is that almost no single board computers in the odroid-ish form factor have both:

1. a non-USB camera option that works
2. integrated 5GHz wifi, or any kind of high speed interface that would allow for a non-USB based 5GHz wifi

There are many contenders which have one or the other, or a nominal camera interface, but the board support package that is released to amateurs doesn’t support it.  Not only that, almost no boards have any high speed interfaces except USB, which means there aren’t even options for doing anything better.

For a moment though in 2017 I thought I had the problem solved with the introduction of the Intel Joule.  On paper it ticked all the boxes, dual camera ports, with software that worked, integrated 5GHz wifi, a supported GPU, and on paper enough of a community that support would be not an issue.  The only downside was that as a system on module, it required a fair amount of a carrier board to be able to actually use it in an end application.  That said, I did try, and built up a carrier board to be able to mount it in the turret of SMMB.

However, I wasn’t actually able to get the Joule to boot on this carrier board, despite it matching the reference board schematic in every way I could check.  To double down on the failure, Intel discontinued the Joule shortly after I had the prototype carrier board in hand which, unsurprisingly, reduced my incentive to try and get it working.

## More promising

Lo and behold, with sufficient time, comes the announcement of the Raspberry Pi 3 Model B+.  On paper it solves nearly every problem as well as the Joule, including needing much less support from a carrier board to be functional.

Pluses:

1. Onboard 5Ghz wifi
2. Camera port, with off the shelf camera modules and functional software
3. Onboard ethernet (although through USB, sigh)
4. Onboard serial which can run at high data rates (>= 1Mbps)
5. Stock debian based linux
6. A production guarantee until 2023!

Downsides:

1. Not quite as fast as the Joule or Odroid
2. The GPU doesn’t support any form of GPGPU very easily
3. Only 1G of RAM

I ordered some and got to work, with results that are definitely more promising, although not without their share of stumbles and pitfalls, and it will definitely take more than one post to describe.  So… more for next time.

# Super Mega Microbot in Robogames 2016

Earlier in April we took Super Mega Microbot out to California to compete in Mech Warfare during Robogames 2016. Thanks to the R-TEAM organizers who made the event happen this year. We were really excited, and the event as a whole went off really well! There were a lot of functional mechs attending, and many fights that were exciting to watch.

We managed to play 5 official matches, in the double elimination tournament, finishing in 3rd place overall. When it worked, SMMB worked really well. Our first loss was a very close battle, the score keeping system had us winning by 2 and the judges had us losing by 2. (The scoring system wasn’t super reliable, so there were human judges calling hits). Our second loss was caused when the odroid’s USB bus on SMMB stopped working mid-match, causing us to lose camera and wifi.

## Takeaways

Since our last matches, we tried to improve a number of things, while some worked, not all of them are entirely successful yet:

• Faster walking: The new mammal chassis is about twice as fast as the old lizard one, but we didn’t get much time to make it work really well, so we were still one of the slower mechs at Robogames. Also, the shoulder bracket, even on its second revision, still had several partial failures during matches and will need to be rebuilt in metal to be strong enough.
• Stabilized camera: The new gimbal stabilized turret actually worked really well. We were able to reliably hit moving targets from the full length of the arena while in motion. It still has room for improvement, but overall was very reliable.
• 5GHz Video transport: We updated our video to use a custom protocol over multicast 5GHz wifi, so that we could completely control the amount of link layer retransmissions. When it worked, this worked very well. We were able to get 720p video with 200ms latency, even in the presence of significant interference. However, adding the external 5GHz wifi card to our odroid seems to have made the USB bus overall somewhat unstable, and one of our matches ended prematurely when the entire USB port died, taking our camera and wifi with it.

## Matches

Thanks to Kevin from R-TEAM, we managed to capture overhead video of all our matches, and have the video as seen on our operator console for each official match as well.