Here’s a small new addition to the mjbots product portfolio, the mjuart - a FT231X breakout board, now available at mjbots.com.

This USB to 3.3V level UART adapter includes appropriate cables to connect to all of the possible auxiliary ports on each moteus controller:

• moteus-r4 ABS: A ZH4 to ZH4 cable with RX/TX swapped
• aux1: A ZH4 to GH8 cable
• aux2: A ZH4 to GH7 cable

The FT231X can communicate without problems at up to 3 Mbps, which lets you capture high rate debug information from a moteus controller. It also works just fine with the yet-to-be-announced UART based control at its default baud rate of 921600 (or up to 3Mbps if you like living on the edge).

When developing features for the moteus controller, testing on actual hardware has long been the primary way that new motor control features were validated. That includes “hero” testing on the lab bench, and the hardware-in-the-loop (HIL) dynamometer fixture used to validate each new firmware release.

While those are valuable techniques, dynamometer testing is not something that you can do rapidly, is limited to validating a small number of things at a time, and has a non-zero fraction of false positive failures due to unmodeled effects. To enable more rapid feature development, I wanted to test a lot of what was validated on the dynamometer fixture in a host side simulation. This would provide a lot of benefits:

• It could run much faster than real time
• 100% deterministic
• Multiple instances can run in parallel
• Agents can use it as success criteria for validating development

Read on to see how it was done:

When using a servo controller, any time the motor needs to either decelerate or resist an external torque, the controller may “regenerate” energy that has to go somewhere. By default, moteus will apply that energy back to the input bus, potentially charging a battery if that is used as the power source. When the input voltage rises too high, either because the battery impedance is high or because a PSU is as the source, then moteus will apply “flux braking” to dissipate the energy in the windings of the motor instead of allowing the voltage to grow without bounds. This often works great, but in some common scenarios flux braking by itself can be inadequate. In order to operate stably, flux braking need to use a filtered version of the bus voltage. This means that if the bus voltage rises fast enough, the maximum configured voltage can be exceeded before flux braking has had a chance to actually begin dissipating significant energy in the motor.

Hot on the heels of BiSS-C encoder support intended for high end applications, I am excited to announce that moteus now supports the RLS Orbis SPI protocol for lower-end systems as of firmware version 1.0.0.

The RLS Orbis is an absolute magnetic encoder suited for use with diametric ring magnets and can be configured to use a number of different communication protocols. If you have a moteus-n1 or moteus-x1, then the newly released BiSS-C support already lets you communicate with them. However that left out the moteus-c1, which does provide the 5V necessary for an Orbis to function, but does not have a built-in RS422 transceiver.