I saw a recent Skyentific video and decided to have a try at it myself, check out the result:

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.

Just a video update… I’m not generally offering the quad A1 for sale *yet*, but if you’re interested in an alpha version, you can write info@mjbots.com

You can of course already get nearly all the non-3d printed parts at https://mjbots.com

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!

Someone contacted me not too long ago who wanted to use the moteus controller, but wasn’t sure if it would be able to hit their target mechanical velocity of 6000rpm. I honestly wasn’t either, so I tested it. After a quick firmware fix, the devkit motor when run at 34V seems to be able to do it no problem.

It should be noted that the current firmware assumes you are within a thousand or so revolutions of 0. You can exceed that pretty quickly running at 120 revolutions per second!