Some time ago I put in orders for all the long lead time items on a second version of the moteus servo.  This is primarily aimed at improving the manufacturability and reliability, along with some minor performance improvements.  I’ve now got at least samples of all the long lead time parts in house!

When I was trying my first pronking, I kept having over-voltage issues when the servos were trying to dump power back onto the DC bus, no matter how high I set the voltage limit.  During that test, I was running with a nearly full battery, so my working theory is that the battery protection circuit was disconnecting the battery either because of too high a charging current, or too high a system voltage.  When the battery was disconnected, and the servos were still putting power onto the bus, that resulted in the voltage spiking arbitrarily high, followed by a total loss of power when they all faulted and then nothing was powering the bus at all.

In my quest to create a more dynamic quadruped, I’ve started accumulating a lot of parts from bulk buys that could be reasonably useful to other hobbyists and experimenters.  To maybe make life easier for everyone, I’ve started up what may be the worlds ugliest online shop where you can buy some of these components.  For now, I have some bearings and custom gears that are useful when building servos for dynamic robots.

Now that I have a full rate inverse kinematics and dynamics solution, I can begin to do more interesting things.  A while ago I did the first jump on the quad A0 – in that video I used a limited technique just to verify that the platform was indeed capable of jumping.  The joints were commanded in an open loop fashion, and really only at the transition points of the jump sequence, relying on the control loops in the servo to actually achieve each stage of the jump cycle.  That resulted in the jump only being minimally controlled… tracking errors would result in the robot taking off from a not-level position and the timing was not super reliable to boot.

Last time I updated my inverse kinematics solution to also include dynamics, velocities and forces.  Now I’m in the process of integrating this onto the robot.

The old SMMB / HerkuleX control software commanded the servo positions in an open loop, which did not take into account the actual position of the joints in any way.  What I’ve done now is implemented a control flow where at each cycle the state of all 12 servos is sampled, then the control laws are applied based on that state, then the resulting commands are sent out.

Over the last couple of months, I’ve had an increasing number of people looking for help with self-built moteus controllers which is great!  However, until today there hasn’t been a great way to get help.  Blog comments fall off the front page quickly, and there is no real other mechanism.

Thus, I’ve created a discord server:

• mjbots discord server

There you can chat about the moteus controller, servo, or the quada0 and get feedback and help in closer to real time.  Thanks for collaborating!

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.