Category Archives: Uncategorized

moteus firmware release 2021-01-14

Sometimes you find bugs, and sometimes the bugs find you! While getting ready to release some updated qdd100 beta servos, I was investigating speed control in the moteus firmware and discovered an unwelcome surprise!

Voltage feedforward

To improve dynamic response under high accelerations, moteus uses a voltage feedforward term as part of its control loop. When trying to command a specific current, it normally applies a PI controller to determine the resulting D and Q phase voltages to apply. The feedforward component of this looks at the phase resistance and the current rotor velocity, and determines a zeroth order estimate of what voltage would be required to achieve that current under a no-load condition, only using the PI controller to determine the difference.

This technique has been in use since my earliest direct drive leg jumping experiments. However, at some point before I added support for gearing reduction in the controller, there was a lot of confusion in the code base around the sign of the torques vs. the sign of the encoder. When that was sorted out, I missed the fact that the resolution ended up leaving the velocity component of the feedforward with a *negative* value. This meant that instead of helping the PI controller, it made the PI controller have to work twice as hard!

The easy, and not-so-easy fix

Fixing this for new controllers involved changing just a single character change from ‘-‘ to ‘+’. However, there is a configuration value which applies an overall scaling to this feedforward term, and has been 1.0 for all released moteus controllers. With the correct sign, a 1.0 scaling factor can result in unstable performance at high velocities.

Knowing this probably won’t be the only complicated upgrade procedure for the moteus controller, I decided to invest in a little infrastructure to make it easier in the future. This is built on two components:

  1. The “firmware version” was always stored in the firmware image and reportable over CAN. Until now, it has always been 0x00000100. I’ve now set this up so that the version is stored as a top level symbol in the firmware .elf file that automated tools can inspect.
  2. moteus_tool now checks the existing firmware version, and the new firmware version. When crossing given firmware versions, it can apply programmatic rules to update the configuration to maintain as close as possible semantic values. To make that robust, it refuses to flash firmware versions newer than it is aware of.

Version 2021-01-14

Thus, the new release, 2021-01-14 which has two improvements / bug fixes:

  1. The aforementioned feedforward sign error.
  2. Temperature values are now minimally filtered before being used for derating or faults.

If you want to upgrade, be sure to use a moteus_tool version 0.3.7 or newer from pypi. Or, if not, make sure that servo.feedforward_scale is set to no more than 0.5 when you’re done!

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

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.