My outdoor filming for the project update video was cut short when the machine cut power to the motors, fell down, and one of the legs snapped off.  Fortunately, I already had plenty of footage when that happened, so it didn’t really impact the video.

First, this demonstrates the not too surprising fact that this particular part of the leg design could use to be improved.  Second, and the topic of this post, is improving what the machine does when the inevitable failure does occur.

To verify that I could make FD-CAN work in the next revision of the moteus controller, I made a simple desk setup between two NUCLEO-G474RE boards.  I started by soldering up some breakout boards for the TCAN334G CAN transceiver I’m planning on using:

And then wired those up with a lot of jumper wires:

After a fair amount of fiddling, bisecting against the ST CUBE example project, and fixing some problems with my STM32G4 support in rules_mbed, I ended up with some 16 byte CAN frames being sent and received with a data rate of ~4Mbit.

While working on the next revision of the moteus controller, I started by bringing up a software toolchain on a NUCLEO-G474RE board.  Unfortunately, even the most recent mbed 5.14 doesn’t yet support that processor.  Thus, I have a half-baked solution which pulls in the ST CUBE sources for that controller into the mbed tree as a patch.

https://github.com/mjbots/rules_mbed/blob/master/tools/workspace/mbed/stm32g4.patch

The patch only implements wrappers for the things I care about, so it isn’t a complete solution. Since I am not really using any mbed libraries anymore in any project, that isn’t a whole lot.  Right now I’m just using it for the one function that sets up the board, a linker script, and the pin mappings.  I will probably eventually just make a rules_stm32 and ditch mbed entirely but for now that is more work than it is worth.

While bringing up an STM32G4 for the new revision of the moteus controller, I wanted to be able to flash and debug the system, and thus needed a working OpenOCD installation.  The NUCLEO-G474RE board has an ST-LINK-V3 debug interface, which no released version of OpenOCD supports, although thankfully that is working just fine at HEAD in git.  However, to make the STM32G4 work I had to pull some patches from the sysprogs/openocd tree.

My last video gave an overview of what I’ve accomplished over the past year.  Now, let me talk about what I’m planning to work on going forward:

I intend to divide my efforts into two parallel tracks.  The first is to demonstrate increased capabilities and continue learning with the existing quad A0, and second is to design and manufacture the next revision of all its major components.

New capabilities and learning

The first, and most important capability I want to develop is an improved gait and locomotion system.  While the moteus servos in the quad A0 are capable of high rate compliant control, the gait engine that I’m using now is still basically the same one that I made for the HerkuleX servos 5 years ago.  It just commands open loop positions to each of the servos and uses no feedback from the platform at all.  This severely limits what the robot can do.  For instance, if the terrain is not level, legs will drag on the ground or it will not walk at all.  The maximum speed is relatively slow and achieving it requires careful tuning of servo-level gains.  While it is more robust than nearly any other open loop 4 legged walker while standing up, even small disturbances can cause it to fall over.

While I’ve been working to some degree on quadrupedal robots for the last 5 years, it has been just about 1 year since I kicked up my effort a notch, with my post about improved actuators for SMMB.  I figured it was a good time now to produce a video summarizing what I’ve gotten done over the last year:

Concurrently, I’ve posted a “state of the project” text update on hackaday.io, just to get a wider readership.  If you’ve been reading here all along, there won’t be anything terribly new there, but it is a decent summary of where I stand.

Back when I was getting Super Mega Microbot “Junior” ready for Maker Fair Bay Area 2019, I made it minimally self sufficient through a quick hack of adding some PVC pipe that allowed it to manipulate its feet into a known good position while the robot was safely up in the air.

This worked, but had a number of obvious disadvantages.  For one, it looked ugly!  Second, the machine couldn’t squat down very far before getting stranded on the “resting legs”.  I’ve finally gotten around to doing at least a first attempt at something better!

In part 1, part 2, and part 3, I looked at what was limiting the update rate of the moteus controller when built into a quadruped configuration and how to improve that.  Now, it is time for the final demonstration!

That video was shot with a 150Hz overall update rate.  The plot shows the commanded and actual position of the three joints in the front right leg, although not all to the same vertical scale.  Updating the servos themselves only used about 3.5ms per cycle, but the gait logic used another 1-1.5ms, which made hitting 200Hz not super reliable, thus running at 150Hz.

Back in part 1 and part 2, I looked at problems that limited the rate at which the host computer could command the full quadruped and some of the solutions.  Now, in part 3, I’ll cover more of the solution.

More solution steps

Previously, I switched to using PREEMPT_RT, switched bridging strategies, and optimized the turnaround of the individual servo.  Now, I’ll move on to optimizing the host software.

4. Host C++ software micro-optimizations

The primary contributor in the host software to the overall update rate is the time it takes to turn around from receiving a reply from one servo, to sending the next command.  I first did some easy micro-optimizations which came up in profiling.

Back in part 1, I looked at the driving factors that limited the update rate of the full quadruped.  Now in part 2, I’ll cover the first half of the solution.

Background

To begin with, there were two major paths that I could take based around the network topology.  In one path, I would remove the active bridging capability from the junction board, and rely on the Raspberry Pi to drive all the servos directly, and in the other the active bridge would stick around.  There were a number of key disadvantages to both approaches: