Tag Archives: moteus_r4

moteus + Arduino

robots, , ,

The moteus line of brushless motor controllers currently require a CAN-FD host to send commands in order to actually execute a motion profile. moteus has long provided a python library that can be used on desktop operating systems to send commands and parse responses, and recently added a C++ one as well. Next up, and described in this post, is a library for Arduino which provides the ability to command and monitor brushless motors using moteus motor controllers.

I’m impatient! How do I use it?

Just open the Arduino library manager and search for “moteus” and install. Then you can open one of the examples and modify it. ”WaitComplete” is a good one to get started with.

What is supported?

The library now supports many Arduino compatible boards and CAN-FD expansions that use the MCP2517FD or MCP2518FD CAN controllers. Anything that the acan2517FD library supports is fair game. It has been observed to work with:

There are two pieces of configuration that are board and controller specific that must be specified when setting up the library. First, the pin assignments and SPI peripheral must be passed to the ACAN2517FD constructor. That can be derived from the pins you used to connect the CAN-FD controller.

Second, you need to match the CAN-FD base clock rate that the board uses. The CANBed FD uses a 20MHz clock, which is what is set in the example. The Mikroe MCP2517FD Click defaults to a 40MHz clock, but can be configured by jumper. In any case, you need to pass the clock rate that your board in to the ACAN2517FDSettings object.

Caveats

The biggest caveat is that some operations with moteus still require a desktop computer with a standalone CAN-FD adapter, notably calibration and interactive modification of configuration. That means while Arduino can be used once a system is commissioned, you will need at least one desktop compatible adapter to perform provisioning operations. The fdcanusb from mjbots (included in each devkit) is a hassle free way to get that.

The Mikroe MCP2517FD CLICK and possibly other boards do not have onboard termination. A CAN-FD bus is specified to require a 120 ohm terminating resistor between CANL and CANH at each end of the linear bus. Most short busses will operate with only one end terminated, and as the fdcanusb has a built in terminator, with that often nothing else is required. However, with an Arduino shield or adapter that does not have an integrated terminator, an external one is required. You can crimp a 120 ohm resistor into a JST PH3 connector, or get a pre-built PH3 CAN-FD terminator from mjbots.

With some smaller Arduino platforms, notably the Arduino Uno or Longan Labs CANBed FD, the combination of the ACAN2517FD library and the moteus library can consume a significant fraction of the flash and RAM available. For simple applications this isn’t a problem, but if you want to execute something more complex, you may be better served using a more capable Arduino compatible processor, like a Teensy 3/4 or a Nano Sense 33.

Video

See it in action here!

BIG price improvement for moteus-r4

robots, ,

I’m excited to announce a big price drop for the moteus-r4.11 controller for both single units and in volume!

QuantityOldNew
1-10$104$79
10-99$99$75
100-499$94$71

We’ve been scaling up production, which enables these reductions of about 25% across the board. moteus-r4 is now by far the most cost effective motor driver with integrated encoder in its class. Here’s a quick comparison with similar products:

ODRIVE S1Tinymover R5.2moteus-r4.11
Voltage12-50.5V12-38V10-44V
Continuous phase current40ANot specified22A
Peak current80A40A100A
Dimensions66mm x 50mm40mm x 36mm53mm x 46mm
Open sourceProprietary FW and HWGPL FW, Proprietary HWApache 2.0 FW and HW
Price$149$108$79

I personally am looking forward to all the new projects that these lower prices enable! Check it out below or join the mjbots Discord to chat and get some ideas for how you can use a moteus-r4.

New Project: Juggling Robot

robots, , , ,

I’ve been looking for a new motor control project to tackle that is both interesting, and a bit more unique than another Ascento clone. Looking around, I was surprised at the current paucity of robots capable of more advanced juggling feats. There are quite a few that can manage 3 balls, and nearly none I’ve found that can manage more, with the exception of Nathan Peterson’s inclined ball roller. I figure that I have access to lots of factory second moteus controllers, which are capable of quite demanding control applications, so I should be able to put something together.

This is what I’ve got so far:

This is a single 6 DoF Stewart platform controlled by 6 moteus r4.11s with mj5208s acting as the servos. A pi3hat and power_dist are nestled inside a 3d printed hexagon. M4 push rods with tie rod ends connect the servo horns to the upper platform, which has an indent to “catch” the ball. At this point, all I’ve done is some simple open loop toss behaviors without any fine tuning or aiming. It can reliably catch and toss some 50g micro juggling balls up to around 30cm, and can throw (but not catch) up to around 80cm.

My intention is to first get this to be able to throw and catch at higher throws, then do some basic 1 hand patterns with 2 or maybe 3 balls. Once I get that working, then I’ll add in a second platform to make the second hand and see what I can pull off. I’ve got an rpi global shutter camera with the intent to do visual tracking of the balls if necessary, but we’ll see how accurate I can get the tosses just open loop first.

The hackaday project page with an overview is here.

moteus with velocity=NaN

robots, , ,

When commanding a moteus controller, many of the registers defined in the reference documentation give explicit semantics when the value is passed as either a floating point NaN value or the “maximally negative integer” for integer encodings. Those that do not specify a meaning for NaN are “undefined” and anything can happen. For the most part, this isn’t a problem, but in one specific case users were repeatedly caught off guard.

Three common registers often set in position mode, (also accessible by the unlabeled first three arguments to “d pos”), are 0x020 “target position”, 0x021 “target velocity”, and 0x025 “maximum torque”. Target position has a defined meaning when set to NaN: the controller assumes that the target position is the current target position, or the sampled position if the controller is not yet in position mode. Maximum torque also has a defined meaning when set to NaN: it then uses the maximum torque as defined by the maximum phase current limit. However, target velocity had no such definition, and in practice when used, resulted in the controller becoming mostly non-functional.

To remedy that, as of release 2023-09-26, moteus will treat a velocity command of NaN the same as a velocity command of 0.0. That is what nearly all users of it intended from my discussions, and I wasn’t able to come up with any more useful semantics after a decent amount of time thinking about it.

No changes are required in user code, this just means that something which would previously result in a broken system, will now work and likely do what the user expected.

CUI AMT21 series RS485 encoder support for moteus

robots, , ,

As of release 2023-09-26, moteus controllers can now use CUI AMT21 series encoders for any encoder source. CUI’s AMT21 series encoders are rugged, with resolution up to 14 bits, and since they use RS485 for communication can be located a significant distance from the motor driver if necessary. Setting one up is easy with the moteus-n1, which is what I’ll cover here.

Hardware

The moteus N1 has JST GH-6 connector labeled “RS422” with all the pins necessary to power and communicate with an AMT21. Since the AMT21 is RS485, not RS422, it is required to tie the A and Y pins together and the B and Z pins together. An easy option is to do so in the harness, either by crimping multiple wires into the Molex terminal for the AMT21, or by splicing wires. The desired schematic looks like:

Software

With the moteus-n1, the software configuration is straightforward, and basically the same as for the AksIM-2.

aux1.uart.mode 4    # cui_amt21
aux1.uart.rs422 1   # True
aux1.pins.3.mode 3  # uart
aux1.pins.4.mode 3  # uart

Once the aux1 UART is configured, then it can be selected as the source for any of the motor_position sources and selected for either commutation sensing, output/load sensing, or as an auxiliary sensor. For instance, to use it as the primary encoder instead of the onboard one, you would do:

motor_position.sources.0.aux_number 1
motor_position.sources.0.type 2       # uart
motor_position.sources.0.cpr 16384    # AMT21 devices report as 14 bit
motor_position.commutation_source 0
motor_position.output.source 0

moteus-r4

As with the AksIM-2, a moteus-r4 can be used to drive the CUI AMT21 series, but additional interface hardware is required. An example schematic can be found in the “RLS AksIM-2” section of the initial “worked examples” post.

MA732 encoder support for moteus

robots, , , ,

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.

Check it out!

New “hold position” watchdog timeout mode for moteus

robots, ,

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' 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:

0: When set to 0, upon timeout, the driver will enter the equivalent of the “stopped” mode and all power will be removed from the motor phases. This will cause the motor to free spin as if there was no driver attached.

10: “hold position”. Here the controller will first decelerate to 0 speed, and then hold position as if a “d pos nan 0 nan” command were issued. Deceleration happens using the default configured acceleration limit in 'servo.default_accel_limit' and the default PID gains are used to hold that position.

12: “zero velocity”. Here the controller enters a mode where 0 speed is commanded with no constraint on position. It provides a damping effect on the motor to remove energy from the system. The default kd PID gain is used to control this effect and the configured kp and ki terms are ignored.

15: “brake”. For mode 15, the controller shorts all three motor phases together. This also provides a braking force. The amount of braking force is not configurable, but is also not reliant on firmware executing to operate so will function over a larger range of potential failure modes.

Mode “10” was newly released in firmware version 2023-07-25 and it works in the same manner across the moteus-r4, moteus-n1, and qdd100.

moteus getting started video 2023 edition!

robots, , , ,

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.

Enjoy!

More MLCC learning

robots, , , , ,

It seems that I’m learning much about PCB design the very hard way.  Back last year I wrote up my discovery of MLCC bias derating.  Now I’ll share some of my experiences with MLCC cracking on the first production moteus controllers.

When I was first putting the production moteus controllers through their test and programming sequence, I observed a failure mode that I had yet to have observe in my career (which admittedly doesn’t include much board manufacturing).  When applying voltage, I got a spark and puff of magic smoke from near one of the DC link capacitors on the left hand side.  In the first batch of 40 I programmed, a full 20% failed in this way, some at 24V, and a few more at a 38V test.  I initially thought the problem might have been an etching issue resulting in voltage breakdown between a via and an internal ground plane, but after examining the results under the microscope and conferring with MacroFab determined the most likely cause was cracking of the MLCCs during PCB depanelization.

dsc_0415
A very obviously cracked capacitor

Here’s a video describing the problem and potential solutions in way more detail than I’ll go into:

Needless to say, I hadn’t managed to see this failure in the 100 or so previous moteus controllers I’ve built, or I would have figured this out and resolved it!

For this first round of production controllers, I went and replaced every single capacitor near the edge of the board with a TDK variant that has internal soft termination, then tested them all at max voltage and a little beyond.  Future revisions will use that variant of capacitor everywhere, as well as relocating the capacitors to reduce the mechanical stress they experience during manufacturing, handling, and installation.

Production moteus controllers are here!

robots, , , ,

Developing the moteus brushless servo controller has been a very long journey, and while it isn’t over yet I have a reached a significant milestone.  The first batch of production moteus controllers are now available for general purchase at mjbots.com and shipment worldwide for $119 USD each!

moteus_r43_front_left

I’ll repeat some of the specifications here:

  • 3 phase brushless FOC control
  • 170 MHz 32bit STM32G4 microprocessor
  • Voltage: 12-34V
  • Peak phase current: 60A
  • Dimensions: 46x53mm – CAD drawing in github
  • Mass: 14.2g
  • Communications: 5Mbps CAN-FD
  • Control rate: 40kHz
  • Open source firmware: https://github.com/mjbots/moteus

Simultaneously, I’ve got development kits available that give you everything you need to start developing software for the moteus controller out of the box: moteus r4.3 developer kit

moteus_r4_3_devkit_back_left

Many thanks for all the feedback from the beta testers who have been experimenting with the r4.2 version!