Category Archives: Uncategorized

Up-rating the moteus phase current

When I first posted the moteus controller up for sale, the specifications I listed were based on the design characteristics and the testing I had conducted up until that point. Specifically, the peak phase current was just the maximum that I had verified was safe to operate with.

In the interim, I’ve done a fair amount more testing and have concluded that the controller can safely drive higher phase currents than initially posted. For now, I’m increasing the peak phase current to 100A both on the specification sheet and in the default firmware configuration of all newly shipped boards. If you already have a moteus controller and want to take advantage of the higher phase current, chat us up on the mjbots discord and we’ll show you how.

moteus r4.3 controller at mjbots.com

Updated web UI

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.

In advance of some wider testing, I went ahead and made the first revision to this now. It has the same basic structure as before, in that the robot serves up one each of an html/css/js file, and provides a websocket interface for ongoing command and control. The change here is just that the html and javascript are even minimally usable:

Clearly I’m not going to win any design awards… but since all the styling is done with CSS, it should be not too hard to make something that looks arbitrarily nice without a whole lot of effort. As a bonus, I also added some minimal keyboard bindings for movement, so the joystick isn’t required if you don’t care about precise or aggressive maneuvers.

Improved low speed step selection

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!

Existing state

In that first pass, I relied on limiting the maximum time spent in the stance phase. However, even with that, it was possible to get into situations where the robot would eventually tip over. Here’s a quick clip showing that happen with the maximum stance time artificially increased:

Clearly, something better could be done.

New approach

While I expect to more seriously revamp the step selection method soon to enable gaits with a flight phase, I figured that I could make incremental progress here with a technique that would also be useful going forward. The basic concept is to keep track of how long until any given foot will reach an infeasible position in its configuration space. If that looks to be soon enough, then that leg (well, virtual leg), will be forced to take a step regardless of balance considerations.

The first part of that is determining when a leg position will become infeasible. I chose to make several approximations. When starting up, for each leg, a sampling approach is used to mark out the feasible region in the joint reference frame for the standard height, and for the leg-lifted height. This results in two 2D polygons:

Then, I intersect those two polygons and simplify to find an XY polygon that gives a valid region for the leg hopefully across the entire used Z volume.

At runtime, I use the calculation I made earlier for balancing segment wise, to determine which segment the leg will exit first and at what time. The “virtual leg’s” exit time is just the minimum of its two component legs.

Finally, I extended the logic to determine when a leg should be picked up to incorporate this “invalid time” in addition to the other constraints (it is getting a little unwieldy at this point).

Result

This approach is definitely is much more robust, especially at low speed rotation. Of course, as always, there is still room for improvement, even with this approach, the legs can get into a configuration where the support polygon is very small, and in some cases very large steps are taken. Addressing those will likely require either incorporating knowledge of the support polygon directly or indirectly, or more forward planning than the “step at a time” approach I’ve got now.

Here’s a video where I stress tested the step selection algorithm by aggressively changing requested walking speed and rotation rates, forcing the machine to make sub-optimal steps and recover from them over and over.