Full rate inverse dynamics on the quad A0

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.

So far, the only control laws I have ported are a simple one which just sends raw commands to each joint, and a somewhat more useful one which commands the end effector of each joint in terms of position, velocity, and force.  Here’s a quick video showing it commanding various constant forces with no position constraints.  The scale isn’t super accurate, nor is the actual force coming out of the device, but I think it should be good enough.

Mammal IK (and now dynamics) revisited

A while ago I derived some closed form solutions for the inverse force dynamics for a 2 dimensional mammal geometry leg.  Now that I want to execute more dynamic gaits, I need to be able to control the velocity and force of the 3 dimensional leg in real time.  That means I need to be able to go forward and back between the two representations.  The first being joint angles, joint velocities, and joint torques — the second being 3D position, velocity, and force.

Rather than derive those myself in 3 dimensions, I decided to save a bit of time now by using the DART kinematics and dynamics routines.  I might need to undo this later if it turns out to be too slow at runtime, but if nothing else it can be a good ground truth for anything I do myself.  I also took this opportunity to do all calculations in consistent rational coordinate frames, where before I had conventions that while documented, were rather unorthodox.

As it turns out, this demonstrated that my old 3 dimensional force calculation, was as I had expected, slightly incorrect.

ik_comparison.png

The shoulder torque was the most affected, being off by 20% or so.

The source is at:

Next up will be using this to actually control a real leg.

mjbots discord server

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:

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!

DART now in bazel_deps

A previous simulator I had built for Super Mega Microbot was based on the “DART” robotics toolkit.  It is a C++ library with python bindings that includes kinematics, dynamics, and graphical rendering capabilities under a BSD license.  I wanted to use some of its dynamics capabilities for future gait work on the quad A0, and eventually re-incorporate its simulation capabilities, so integrated a subset of it into mjbots/bazel_deps.

Failing more gracefully

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.

dsc_1541
Robot down
dsc_1540-1
Nice infill shot

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.

What happened — just the facts ma’am

In this particular instance, I had been running the machine outside continuously outside for an hour or so on a relatively warm day.  This iteration of the servos has basically no heatsinking whatsoever on the servo control board.  With the gearboxes, it isn’t necessary for short duration or low power testing.  However in this case, one of the servos eventually reached its temperature limit and entered a fault state.

As implemented now, any individual servo that hits a hard fault immediately cuts all power.  Also, at that time, the overall gait control, upon sensing any servo failure, immediately cuts power to all the other servos too.  As you can imagine, when a machine that weights 10kg loses all power to all joints with a few milliseconds, it falls down pretty hard.

Areas to improve

There are of course many areas of improvement which this event demonstrates.  One, the servos need better thermal properties.  This was known, and I hope to address in the second revision where I can heatsink the controller properly.  Second, the leg should be strong enough to handle falling down.  And third, it would be nice, if it could, if the machine would do something more graceful when continuing on in a controlled manner isn’t possible.

I tackled that third step right now in two phases.  First, I set up an optional communications watchdog in the servo.  If control commands aren’t received in a timely manner, the servo enters a new mode where it merely commands a zero velocity with no position control at all.  This means that if the control software segfaults, or the primary computer goes out to lunch, the machine will gently lower to the ground rather than dropping like a rock.

Second, I modified the control software’s reaction to an individual servo fault.  Now, it commands this new zero-velocity state of all unfaulted servos so as to minimize the amount of damage done to the overall machine.  If only one or two servos have faulted, this will still result in a relatively gradual let down.

Here’s a quick video demonstrating the two failure types:

 

 

Bringing up FD-CAN on the STM32G4

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:

dsc_1549

dsc_1553.jpg

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

dsc_1555

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.

whole_frame
A whole frame
single_bit
A single bit within the data part of the frame

STM32G4 for mbed

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.

 

OpenOCD for STM32G4

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 resulting work can be found at: https://github.com/mjbots/openocd

Hopefully the dependent OpenOCD gerrit review will eventually land: http://openocd.zylin.com/#/c/4932/ which will clear the way for getting G4 support into master there.

For now, I’ll just live with a custom compiled OpenOCD.

 

mjbots quad A0: October 2019 Roadmap

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.

At a minimum, I’d like to switch to controlling the position and force of the endpoint of each leg and switch to a gait engine that takes into account the actual position of each joint during the gait cycle.  That should enable it to maintain good ground contact with all feet that are intended to be in a stance position.  Now, often feet will skip around, as the servo gains are all relatively high to account for the lack of feedback.

The next level would be to take into account an IMU to ensure balanced feet lift offs.  While I have an IMU in this configuration, it currently isn’t usable due to my improvised attempts to improve the overall system update rate.  I’ll need to update some of the hardware to get an IMU again before I work on this part.

New hardware revisions

I have learned a lot with the moteus controller, servo, and the quad A0 over the last year.  I’d like to take that learning and update the components to achieve:

  • Manufacturability: Many of the sub components now are very labor intensive to produce or assemble.
  • Cost: I have in many cases made things much more expensive than they needed to be in order to shave a bit of time off the prototyping process.  Also, I have enough confidence now to get larger volumes of parts, which further reduces cost.
  • Capability: There are many easy areas where the system performance can be greatly improved.

My overall goals are to make a system that is capable and affordable — to provide an ecosystem of parts and systems for researchers and hobbyists to use.  That means keeping everything open source, and providing access to all subcomponents and designs while still being able to provide a complete system that is capable out of the box.

Here’s a quick rundown of the various areas I’m tackling:

Moteus controller

My next revision of this controller will be a slightly bigger change, in that the form factor, the microcontroller, and the connectors used will all be altered.  I’m planning on switching to an STM32G4 for the controller, using daisy-chained connectors for power in addition to communications, switching to FD-CAN for communications, and reworking the form factor to enable all the primary connectors to exit from one edge of the servo.

Also, I’ll take this opportunity to design for automated end of line test.  That means I will leave enough probe points such that a test fixture can validate the correct operation of a board without intervention.

I don’t anticipate the performance to change a whole lot, although I may increase the allowed input voltage.  Even so this will still be a very capable board, with 3 phase current sensing, >=50A peak phase current, >= 400W peak power and a switching and internal control loop rate of >=40kHz.

Moteus servo

The first round of gearbox servos went through many revisions to achieve something that was functional.  That said, while functional, they are fragile, and require about a full man day of assembly time per servo.  I’m working to get pre-production volumes of around 100 units for all the components such that no post machining will be required and the servos can just be assembled together.

While I’m at it, I intend on switching everything to metal from 3d printed plastic, and reducing the overall dimensions.  It is likely the mass will increase a little from the current 410g, but I’m hoping that it won’t be that much compared to the increased strength and rigidity.

Junction board / raspberry pi 3 hat / pre-charge board

I intend to rework the architecture behind the power and data distribution internal to the quad A0.  Currently there is a raspberry pi3 hat, which merely powers the raspberry pi and provides an RS485 interface.  Then a “junction board” splits out the RS485 bus into four separate connectors as well as splitting out power to all four legs and housing the IMU.  Finally, a separate “pre-charge” board ensured that the servos can have power applied safely.

I intend on moving all data distribution and the IMU onto the board that mounts on the host computer.  Thus it will have power in, an IMU, and 4 (or maybe more) CAN bus outputs.  Then, a separate power distribution board will include the pre-charge circuit as well as connectors for power for all four legs.  Simultaneously, I plan on adding an actual power switch, so that I don’t have to keep pulling the battery in and out to cut power.

Chassis

The quad A0 chassis is a single monolithic 3D printed block.  Actually attaching legs to this is nigh impossible.  It takes a long time, and not all of the joining screws can actually be used because of interference with other pieces.  Also, using the Ryobi style batteries results in a lot of dead space due to the mounting stud.  I am planning on switching this chassis to be printed in multiple components that are assembled together with screws and threaded inserts and switch to a battery form factor that is more compact.

That should also allow for mounting the primary computer inside the chassis, and still leave enough room for a bigger computer, like an NVIDIA Jetson nano.

Legs

I’ve already had one failure in the current iteration of the leg that indicates some redesign is necessary.  Also, the two primary brackets that connect the shoulder to the upper leg, and upper leg to lower leg should be made from aluminum instead of being 3d printed.  Those brackets had to be really big and printed in odd orientations in order to be strong enough, and they could be a lot lighter, more convenient, and more cost effective in metal.

Looking forward

Thanks for all of your positive feedback so far, and I look forward to more exciting times executing these plans!

Quadruped robots: One year in!

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.

Oh, and I’ve decided to give the robot a more memorable name for now.  The “mjbots quad A0”!  Yeah, I’m no marketing whiz, but it will suffice.

Coming up next, is a brief roadmap of where I plan on focusing my efforts in the next 3 to 6 months.