In simple motion control applications with moteus, a common request for the python library is “run a position command until it is complete”. moteus does track when the target position reaches the desired one and reports it in the “trajectory complete flag” (register 0x00b), however until now the application needed to poll that flag on a regular basis to see when the motion is done.

As of pypi moteus 0.3.59, there is now a new method on Controller which can be used to accomplish this, along with an example script. Basic usage is about as simple as one would expect:

When the moteus acceleration and velocity limits were first announced more than a year ago, it was noted that the semantics of using the legacy “stop_position” along with the new acceleration and velocity limits was “not particularly useful”. In the meantime, I’ve seen many cases where people get tripped up by this, even more so since developer kits now come with velocity and acceleration limits configured.

To mitigate that, as of firmware release 2023-09-26, moteus will now fault with code 44 if you attempt to use a stop_position while acceleration or velocity limits are configured. Here’s a quick reminder on how to upgrade:

As of release 2023-09-26, moteus r4 and moteus-n1 now both support the MA732 as an external SPI encoder. The magnetic sensing performance of the MA732 is normally a bit worse than the AS5047P that is used as the onboard encoder with moteus, but it has two possible advantages.

The first, is that it is much smaller, using a 3mm x 3mm QFN package. The second is that it supports off-axis applications. You will need to read the datasheet, and set the 'aux?.spi.bct' configuration parameter correctly, but this can enable operation in interesting geometries, like a ring magnet with a hollow shaft, or where the coaxial placement is otherwise not feasible.

The pi3hat repository, in addition to hosting a library for sending raw CAN frames using the pi3hat, has long had example source code demonstrating how to use that to communicate with a moteus controller. Recently however, C++ bindings were officially added to the primary moteus repository, that provide a more consistent, flexible and complete interface to moteus controllers. I’ve gone ahead and updated the pi3hat library to take advantage of that new interface, so now the pi3hat can be treated as just another transport like the fdcanusb.

In the initial announcement of the new moteus C++ library, the only transport that was supported out of the box was for the mjbots fdcanusb. That has now been upgraded so that Linux socketcan devices are supported out of the box as well!

You need version mjbots/moteus e33f188b035c7 or newer and for simple cases, no changes to source code are required at all.

For a long time, moteus has had a python library, that lets most people quickly develop motion control applications. However, python is not a suitable solution in every domain. Embedded systems often either don’t have access to python, or cannot tolerate the resource or timing penalties it imposes. In some cases, managing interoperability between python asyncio and systems using legacy python IO like ROS can be challenging. For others, python is just not familiar. The new C++ client library included in the moteus repository is designed to handle all of these scenarios with a flexible, yet ergonomic approach that makes simple things simple, and complex things possible.

For a while now moteus has had the ability to configure what action takes place upon a CAN message watchdog timeout during position control mode. If configured with ['servo.default_timeout_s'](https://github.com/mjbots/moteus/blob/main/docs/reference.md#servodefault_timeout_s) moteus requires that CAN messages be sent at a regular rate. If ever a message is delayed by more than the timeout period, the mode switches in a latching manner to the “timeout” mode, where a special action is undertaken. This is configured with ’servo.timeout_mode’ in tview, and as of firmware release 2023-07-25 the available values are as follows:

The perils of technical videos is that they can become out of date pretty quickly. For the moteus getting started guide, it has amazingly held up pretty well, but enough has changed since 2021 that it is time for a new one. Now we can use acceleration and velocity limited commands instead of the deprecated stop position and get nicer 4k b-roll for all the intermissions. Everything in the old video, and in this new one, is applicable to both the moteus-r4.11 and the moteus-n1.

Back last year, I walked through bisecting and debugging an annoying problem that caused the STM32G4 ADC on the moteus controller to exhibit higher than expected noise in result largely to either the exact placement in flash of the initialization code, or to the exact timing of the initialization. While the immediate glaring sharp edge was removed, the resulting performance still was confusing to me, and looked like it was not yet optimal. Further, a moderate percentage (2% or so), of production boards failed end-of-line tests related to the current sense noise in ways that were hard to fix by swapping components. Because of this, I wanted to dive in and investigate further. This is that process.

If you look around online, there are lots of examples of PCB test fixtures used to perform end of line testing. In the low to medium volume scale, nearly all of these are either clamshell or 2 side affairs, where probe pogo pins or interfaces are connected to the bottom and top of the board.

When developing the moteus-n1, one of the challenges was the number of right angle board edge connectors it has. Those right angle connectors are what allow it to maintain a very low overall stack height when installed in applications, but are also much harder to perform testing on, since by definition the access points are not vertical. On the base n1, there are 6 total right angle connectors, 2 on each of 3 sides, and future variants may have additional bottom side CAN and power connectors populated to make 8 total right angle connectors.