UART command and control for moteus

Features

It has been quite some time since moteus gained the ability to be controlled or monitored over a different communication channel. In fact, the last time was with the permanent switch from RS-485 to CAN-FD way back in 2019 with the first moteus-r4. So, I’m happy to share that as of firmware 1.1.2 moteus now has a second supported communication transport out of the box, logic level UART!

Why UART?

Often it is useful to deploy moteus in a system where it is controlled and monitored by a microcontroller, there is only a single moteus controller, and the total distance between the microcontroller and the moteus is short and without significant electromagnetic interference (EMI). In those cases, using a logic level UART on the microcontroller can save the additional complexity and cost of integrating a CAN-FD controller and transceiver into the host system.

A UART, or universal asynchronous receiver-transmitter, sends data using one signal line for transmission and a separate signal line for receiving. The bit rate and other communication parameters must be agreed upon by both sides beforehand. Nearly every microcontroller in existence today has support for at least one, if not many UART peripherals.

Using moteus with a UART transport

By default, all moteus controllers shipped by mjbots with firmware 1.1.2 or newer have a UART transport configured on the following auxiliary port pins:

  • moteus-r4: AUX2 TX=A, RX=B
  • moteus-c1: AUX2 TX=C, RX=D
  • moteus-n1/x1: AUX1 TX=E, RX=D

Communication parameters: 921600 8N1

After connecting the moteus TX pin to the UART peripheral RX and vice versa for moteus RX, communication is possible. The standard moteus python tools can be used out of the box by explicitly specifying the UART device like:

python -m moteus_gui.tview --fdcanusb /dev/ttyUSB0

or

python -m moteus.moteus_tool --fdcanusb /dev/ttyUSB0 -t 1 --info

The python and C++ library similarly have support as does the moteus-arduino library. You can take a look at the documentation to see how to use them there:

Downsides of UART with moteus

The biggest downsides common to any UART link are:

  1. It is a point to point link. That means one moteus per UART peripheral.
  2. It is more sensitive to electromagnetic noise. That means wires must be short and not run parallel to high power signals like input power and phase wires.

Then there are some downsides specific to moteus:

  1. Microcontrollers, whether using a UART or not, can not yet calibrate a new motor with moteus. That means that provisioning must be done with a computer capable of running python. It is possible for this host computer to use a logic level UART to do the provisioning.
  2. moteus does not support flashing new firmware using the UART transport, only CAN-FD and the SWD st-link port can be used.
  3. moteus uses auxiliary port pins to support the UART transport. That means those pins cannot be used for other things, like external encoders if the UART transport is used.
  4. There are practical challenges to configuring other pins on an auxiliary port used for UART based control and monitoring that make it relatively difficult while communicating over the UART transport.

Under the hood

moteus implements this by “pretending” to be a fdcanusb. That means that clients will end up sending commands like this over the UART:

can send 8001 01000011001f01130d505050 *C9
rcv 00000100 2100002f0100c83cbebab7f0b900000000230d2f1d00 *B6

The only difference with what is sent to a regular mjcanfd-usb-1x over a USB CDC link is that there is a trailing checksum. Since a UART link otherwise has no data integrity mechanisms, this reduces the likelihood that electrical interference will cause a command or response to be mis-interpreted.

Upgrading

Like all recent features to date, this can work with any moteus controller in the field by upgrading to the most recent firmware. You can read how to upgrade your firmware by following this link to the documentation: