I have been continuing to iterate on the control and mechanical aspects of the improved actuators for SMMB.  While working on an alternate board mounting strategy, I ended up with a magnet that was much much further from the absolute encoder than before.  This resulted in significant errors in the estimated motor phase at various points in the revolution of the absolute encoder.  In the spirit of copying every single thing Ben Katz did in his project, I implemented a piecewise linear encoder calibration technique.

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.

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.

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.

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.

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!

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:

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.

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?

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: