Since the first public release, moteus has always calibrated motors so that a positive command is equivalent to a fixed sequencing of the phase wires. That means that depending upon which order you solder the phase wires, a positive commanded velocity will result in the motor spinning either clockwise or counterclockwise.

As it turns out, since moteus has an absolute encoder that is immune to such vagarities, it is much more convenient to normalize the direction of rotation around the encoder rather than the phase wires. As of release 2021-04-26, and moteus_tool 0.3.22, that is exactly what moteus does.

The moteus controller uses an absolute magnetic encoder to sense the position of the rotor in order to conduct field oriented control of the motor. In many applications, this sensing is also sufficient to measure the output as well, particularly in direct drive applications. However, if the controller is driving the output through a gear reduction, multiple turns of the input are necessary to make one turn on the output. At power on, this results in an ambiguity, where the controller doesn’t know where the output is.

Some of the new features in the moteus 2021-04-09 firmware release are new limits that can make the overall system more robust to faults or environmental conditions.

Velocity limiting

config: servo.max_velocity

Like the position limits, there now is a configurable velocity limit. If the motor is moving faster than this limit in either direction, then the applied torque will be limited, eventually to a value of 0. This can be used to reduce the likelihood of runaway behavior in systems where high speeds are not expected.

Since the moteus controller has been seeing a lot of updates lately, I decided to make a separate hackaday.io page to track its progress in one place. Check it out!

https://hackaday.io/project/179234-moteus-brushless-controller

Since the moteus controller was first released, it has implemented a two-stage controller. The outer loop is a combined position/velocity/torque PID controller, which takes as an input a position trajectory, and outputs a desired torque. The inner loops accepts this torque, and uses a PI controller to generate the Q phase voltage necessary to achieve that torque.

Until now, the constants for that PI controller were left as an exercise for the reader. i.e. there were some semi-sensible defaults, but the end-user ultimately had to manually select those constants to achieve a given torque bandwidth. That isn’t too much of a problem for a sophisticated user, but for the rest of us, it is hard to know how to go from a desired torque bandwidth to reasonable PI gains.

On the mjbots discord, people are often looking for the cheapest possible way to command and monitor a moteus controller. One possible solution that comes up over and over again is the CANBed-FD board, as sold by Seeed Studio (and others). I decided to get one of these in house to see if I could make it work:

The first thing I figured out was that the DB-9 connector used a non-standard pinout for CAN_L and CAN_H. I just switched to the terminal block connections instead of the DB-9 to get around that. For the software, I decided to use the acan2517FD Arduino library, as it was quite a bit more robust and featureful than the one provided by Longan Labs.

I’d like to introduce the newest mjbots product, an updated revision of the power_dist, 4.3b available at mjbots.com today!

This version has a number of improvements over the previously released r3.1:

	r4.3b	r3.1
Voltage Range	10-44V	8-34V
Maximum load capacitance	4,000 uF	400 uF
Quiescent Current	300uA	5mA
Current (Continuous / Peak)	45A / 80A	unrated / 100A
Energy Monitoring	YES	NO
Switch Mode	High Side	Low Side
Dimensions	50x80mm	45x70mm
Price	$139	$79

The only real downsides are that is more expensive and slightly larger.

This is one of a series covering the new mjbots power_dist board. See part 1 and part 2 for more context.

As mentioned previously, hot swap controllers are primarily used to allow a card to be inserted live into a server backplane, while minimizing disruption to the primary power bus while doing so. Additionally, they often implement protection features like over-current and short-circuit protection, and some support energy monitoring.

Typical topology

A typical hot-swap topology looks like:

Last time I covered the limitations of the power_dist r3.1, here I’ll cover some iterations of the design process.

My initial design goals for this version are based largely around improving the major limitations identified before:

• Positive side switching: By switching the positive rail, a whole class of use failures is removed, as most people expect ground to be common throughout a system.
• Increased voltage range: moteus r4.5 and the pi3hat both support 44V, so any new power_dist board should support at least that.
• Lower quiescent current: Ideally, the quiescent current would be measured in microamps, or at least at a level that it does not confuse BMS systems.
• Energy monitoring: Often in the development of the quad A1, I wanted to have a system level power and energy monitoring solution so as to identify the energy cost of various maneuvers and gaits. Tracking that at the power_dist level seems like a logical place.
• Wider load envelope: The 3.1 version had a relatively limited maximum downstream capacitance and turn-on current draw. It was enough to power on 12 moteus controllers and a small computer, but not much else.

To achieve these goals, I decided to try using what is known as a “hot swap controller”. These are integrated circuits that are intended for use in cards that plug into server backplanes. Given that any given card could potentially have a large decoupling capacitance, inserting it live into a backplane could cause arcing, and high currents that cause the overall bus voltage to drop outside of tolerable limits.

The current iteration of the mjbots power_dist board released back in the summer of 2020 is pretty useful. It pre-charges the input, provides a soft switch, and gives you a bunch of output connectors to make wiring easier.

r3.1 Limitations

However, this version did have some limitations and potential problems. The first is that the pre-charge method it uses, a simple on/off pre-charge resistor, is unable to support a wide range of supply voltages. Either the resistor has a low value, in which case large input voltages will cause thermal failure, or for larger values, it isn’t able to actually pre-charge the bus sufficiently before engaging the primary MOSFET.