In another discord moment, someone was asking about the difference between electrolytic capacitors and multi-layer ceramic capacitors. That, plus some desire to re-rate the moteus, inspired me to do another sweep and measure the DC bus voltage ripple for various power levels. I captured this plot with a 24V power supply, with a 5008 motor with 0.061 ohm of winding resistance or so, and each current being applied for 300ms. The voltage ripple is peak to peak measured at the power connector.

I’ve been wanting to build a dynamometer for a while to better characterize the performance of the direct drive and geared versions of the moteus controller. I have now started down that path with a torque transducer, which I calibrated with the below fixture:

I got a what ended up being a low quality load cell amplifier to use with it from the same supplier, although discovered it was total garbage and am now using a SparkFun OpenScale board which seems to be working much better. Soon I’ll hopefully have something wired up that actually has a controller or two on it.

I’ve started some development on higher speed gaits for the quad A1! No real details to report now, just a video showing the first time I tested it not in simulation. I will admit these clips were cherry-picked, as there are problems still, but it is a start!

I’ve worked through a number of different iterations of the stand-up sequence for the quad A1 (2019-05, 2019-09). The version I’ve been using for the last 6 months or so works pretty well, but because it drags the legs along the ground to get them into position, it can have problems when operating on surfaces with a lot of traction, like EVA foam, besides being uselessly noisy.

To make things just a bit more robust, I’ve now tweaked the startup routine so that the shoulders lift legs clear off the ground before positioning the legs, then lowers them back down into place. This makes the stand up routine much more likely to succeed on just about any surface:

In my previous experiments demonstrating torque feedback (full rate inverse dynamics, ground truth torque testing), I’ve glossed over the fact that as the stator approaches magnetic saturation, the linear relationship between torque and current breaks down. Now finally I’ll take at least one step towards allowing moteus to accurately work in the torque domain as motors reach saturation.

Background

The stator in a rotor consists of windings wrapped around usually an iron core. The iron in the core consists of lots of little sub-domains of magnetized material, that normally are randomly oriented resulting in a net zero magnetic field. As current is applied to the windings, those domains line up, greatly magnifying the resulting magnetic field. Eventually most of the sub-domains are aligned, at which point you don’t get any more magnifying effect from the iron core. In this region, the stator is said to be “saturated”. You can read about it in much more depth on wikipedia or with even more detail here. The end result is a curve of magnetic field versus applied current that looks something like this:

My initial design torque for the qdd100 was a little over 17 Nm. However, when I did my first ground truth torque testing, I found that some servos had a lower maximum torque than I had specified. While working to diagnose those, I built a qdd100 that used an alternate stator winding of 105Kv instead of the 135Kv that are in all the beta units. The Kv rating of a stator describes how fast the motor will spin for a given applied voltage. If you assume the same amount of copper mass of wiring, a lower Kv will mean that there are thinner wires that wrap around the stator more turns (or fewer wires in parallel). A higher Kv will have thicker wires with fewer overall turns.

For some upcoming work, I needed to drive the quad A1 around without being tethered to a computer. To date, my control mechanisms have been:

• A web interface driven from a computer with joystick attached.
• A nrf24l01 link driven from a nrfusb attached to a computer.

Note, both of those methods involve being tethered to a computer, which makes it hard to be mobile. As a possibly short term solution to this problem, I went ahead and got a bluetooth “gaming” controller for my phone (non-affiliate amazon link):

I first wrote about the very very simple web UI for the quad A1 some time ago. That UI served its purpose, although it was largely inscrutable to anyone but myself, as the primary data display was a giant wall of unformatted JSON which filled most of the page. It was also pretty easy to accidentally pick the wrong mode, cause the robot to jump instead of walk, or cut power to everything.

I’ve now built 3 or 4 complete quad A1 style robots depending upon how you look at it. Each was somewhat of a one-off, incrementally modified over time as I discovered failure modes and improved the design. Before starting to serially build quad A1 style robots, I wanted to get a better understanding of how much actually goes into making one. The quad A1 has a fair number of sub-assemblies, custom PCBs, harnesses, and assembly steps that go into its production. During previous builds, I kept running into problems where I would run out of some component, fastener, or raw material unexpectedly, then have to wait for its lead time before I could continue.

In my original series on balancing while walking, (part 1, part 2, part 3), I described some heuristics I used to handle changing directions. That was minimally sufficient in 1D, however in 2D it still leaves something to be desired, as there are more possible degenerate cases. The biggest is when spinning in place. There, the center of mass doesn’t really move at all relative to the balance line, but we still need to take steps!