Tag Archives: release

moteus-c1

robots, , ,

I’m excited to announce the newest addition to the moteus line of BLDC controllers, the moteus-c1! The moteus-c1 is a smaller, lower power, lower cost version of the moteus-r4 and moteus-n1, but still packs a big punch.

The top of the line performance metrics for the entire moteus lineup now look like:

moteus-c1moteus-r4moteus-n1
Input Voltage10-51V10-44V10-54V
Peak Phase Current20A100A100A
Continuous Phase Current5A / 14A11A / 22A9A / 18A
Dimensions38mm x 38mm46mm x 53mm46mm x 46 mm
I/OAUX1 D and E are present as through hole pads.

AUX2 is identical to moteus-n1		AUX1: SPI, Hall, ADC

AUX2: I2C and UART
3.3V only		AUX1 and AUX2 support SPI, UART, Quadrature, Hall, and I2C.

5.5V and 3.3V provided on each connector.

I2C pullups are configurable on each connector.
RS422NoneNoneBuilt-in transceiver for RS422 based encoders
CAN fault tolerance58V12V58V
Price$69$79$149

The upshot is that for low current motors where RS422 is not required, it is nearly as capable as the moteus-n1 for less than half the price!

Compatibility

The moteus-c1 is fully electrically and software compatible with the moteus-r4 and moteus-n1. It uses the same connectors for power, CAN, and AUX2 and it has the same through hole layout for power and phase terminals as the moteus-n1. While the moteus-c1 requires firmware version 2024-04-30 or newer, the same firmware image can be used across the entire moteus line and all functionality that is available based on the connectors present are available on all controllers.

Accessories

The controller itself isn’t the only thing available at a price that is an exceptional value. The moteus-c1 developer kit has been updated to use the mjcanfd-usb-1x and entirely 3D printed brackets. One omission from this lower cost kit is the stm32 programmer, which is still available separately. This gets the overall price of the moteus-c1 developer kit down to the almost crazy point of $149, which around the same as a single moteus-n1!

As with the moteus-r4 and moteus-n1, we also stock a heat spreader for the moteus-c1 for applications where you want to push the thermal envelope. This heat spreader now comes with thermal tape rather than paste, which should make installations less messy.

Intro Video

Finally, here is a short introduction video. The observant viewer will notice many not yet announced demonstrations and projects! Those should get written up in the following months as time permits.

External daisy chain boards and new PH3 cable lengths

robots, , ,

It continues to be the spring of new products at mjbots (see the mjcanfd-usb-1x from earlier), and today I have some basics that are newly added to the store to make building machines just a bit simpler.

First are two tiny boards to make daisy chaining power and CAN-FD connections easier for boards that don’t have built-in daisy chain connectors like the moteus-n1. First is a junction board for PH3 cables:

And the second is a similar junction board for XT30 cables:

Finally, we now have our JST PH3 jumper cables in a wider variety of lengths. You can now get them in any of:

That’s it for today, but it isn’t it for our new spring products. Some of the most exciting are yet to come!

Forbidding stop_position with acceleration limits

robots, ,

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:

OldNew
d pos nan V T sXd pos X 0 T vV aA

Where:

  • X – target position
  • V – velocity to use to achieve that position
  • T – maximum torque
  • A – the maximum acceleration (the old formulation had no acceleration limits)

Some further notes:

Note that in the modern formulation, the velocity and acceleration limits will come from servo.default_velocity_limit and servo.default_accel_limit if nothing is specified in the current command. Values given in the current command will override those.

In the new formulation, it is possible to specify a non-zero velocity target. In that case, the trajectory profile moteus follows includes continuing motion at that constant velocity until the next command is received.

The same upgrade principle should be used if the commands are sent via the register protocol or the python or C++ library. For the register protocol, do not use register 0x026. Instead, command a 0 target velocity in register 0x021 and either configure velocity or acceleration limits, or use registers 0x028 and 0x029 to override them on a per-command basis.

moteus firmware releases

robots, , ,

I don’t normally post about moteus firmware releases, but there have been many in the last few months that fix some long standing bugs and regressions. First, the current release as of this post is:

With that out of the way, here some of the fixes:

Position drift with non-unity gear reduction

It is embarrassing how long this issue has been outstanding, but ever since the flexible I/O system was introduced, there has been an issue where if the gear reduction was configured to a value other than 1, then the output position would drift from the source encoder over time. If control was not active, you would see the position drift, and if control was active, then moteus would report the correct position, but the actual position would drift.

Non-zero goal velocities with limits

Last year, when acceleration and velocity limits were implemented, the semantics of a command with a non-zero velocity was that the controller would try to reach the exact position as stated in the command while traveling at that velocity. If the velocity was non-zero, that often meant that the controller would need to back up a lot, then re-accelerate. Needless to say this is not the most useful semantics.

Now, moteus treats a command with non-zero velocity as “follow the trajectory x = x_command + v_command * t”. This is what most users expected and is more useful.

Bootloader operation in degraded CAN environments

The primary moteus firmware has long had two mitigations for degraded CAN environments. First, if a query message has the BRS (bit rate switch) flag disabled, then the controller will respond in kind. This allows the host to force operation at 1Mbps instead of the normal 5Mbps. Second, moteus will automatically attempt to rejoin the CAN bus if a busoff event occurs, say because some device was connected with an incorrect bitrate.

Those were helpful, but the bootloader lacked those fixes, so flashing new firmware in a degraded CAN environment was either unreliable, or not possible at all. No longer!

Misc

That wasn’t even all, a number of smaller fixes were made:

  • It used to be possible to trigger a firmware assert if position mode was commanded within a few ms of power on.
  • The “conf default” command would reset the configuration, but those new values would only actually be used for a subset without further action.
  • It was possible for the initial position to be outside the range of -0.5 / +0.5.
  • The ADC performance variability with firmware versions is now hopefully resolved for good (to be detailed in a later post).

Thanks for all your feedback to help find and fix issues!

power_dist r4.5b

robots, , ,

Here is yet another new product announcement! In the same line as the new pi3hat, here is a new minor revision of the power_dist, the r4.5b:

The changes are largely the same as for the new pi3hat:

  • The input voltage range is extended from 10-44V, to 10-54V.
  • The CAN-FD port has +-58V bus fault protection, up from +-12V.
  • Additionally, the measurement noise of the output current has been improved from 300mA to approximately 30mA.

Check it out at mjbots.com today!

moteus-n1 beta release

robots, ,

Implied by my previous writeup on pin selection for external connectors, we’ve got a new variant of the moteus controller to announce today in beta form, the moteus-n1!

This variant is intended to be more feature-full, higher performance (and higher cost). Here are some bullet points of the biggest differentiators with r4.11:

moteus n1moteus r4.11
Price$159 USD @ qty 1$104 USD @ qty 1
SizeAs small as 46mmx46mmx8mm with optional back connectors omitted.

58% of the volume, 87% of the top down footprint size of r4.11		53x46x12mm
External PeripheralsEach of the auxiliary connectors supports SPI, UART, ADC, SW & HW Quadrature, Hall sensors, and I2C.

5V and 3.3V is provided on each connector to power peripherals (100mA for each voltage available combined between both connectors).

I2C pullups are configurable on each connector.

All 4 pins on AUX2 are 5VT, the two non-SPI pins on AUX1 are 5VT.		ENC (AUX1) supports SPI, Hall and ADC.

ABS (AUX2) supports UART and I2C and are both 5VT.
RS422Built in RS422 transceiver for communicating with RS422 / BiSS-C encoders (BiSS-C / SSI not yet supported in software).None
Voltage8-54V, 48V nominal8-44V
Peak Output100A output phase current, 1200W100A output phase current, 500W
Continuous Output9A output phase current ambient, 18A w/ thermal management11A output phase current ambient, 22A w/ thermal management
CAN fault tolerance58V bus fault tolerance12V bus fault tolerance
Power ConnectorsSolder pads for DC bus input, one always present XT30, one optional XT302x XT30

The short form is that the n1 does not really expand the set of motors that can be usefully driven, but does enable operation in 48V systems, is more compact and electrically robust and provides significantly improved external peripheral support.

Don’t worry, the existing r4.11 controllers aren’t going anywhere and are still being produced. The moteus-n1 series just complements them by enabling new applications.

Firmware

Both the moteus n1 and r4.11 share the same open source firmware, although the n1 requires a newer release to operate. Command, control, and monitoring work identically on both, including tview, the python library, and all CAN formats. The only exception is that the n1 has more external pin configurations possible as shown in the reference documentation’s pin capability table.

Accessories

The mechanical form factor of the n1 is different from r4.11, and thus the existing devkit bracket and heat spreader can not be used. New variants exist for both of those that are compatible with the n1.

The XT30 and JST PH3 board connectors are now available for sale separately in order to convert n1’s to have daisy chain connectors.

Finally, all the external peripheral connectors use JST-GH connectors, so we now have headers and pre-crimped wires available for the JST GH6 (used for the RS422), JST GH7 (used for AUX2) and JST GH8 (used for AUX1).

Beta availability

Starting today we’re making some moteus-n1 units available in a paid beta program, with errata documented here. Up to 2 controllers in either devkit or bare board form (both bare board and devkits variants count towards the total) can be ordered per customer via the links above. There is no technological limit if you try to exceed that, you will just have your order cancelled with a note to try again with fewer.

Good luck!

pi3hat r4.5

robots, ,

I’m excited to announce a minor upgrade to the mjbots pi3hat product line, the pi3hat r4.5!

This has a few upgrades over the old r4.4b:

  • The input voltage range is expanded from 8-44V to 8-54V.
  • All CAN-FD ports have +-58V bus fault protection, up from +-12V.
  • 0.1″ pin headers are present for the Raspberry Pi I2C, UART, and for 3.3V and 5V outputs

Check it out at mjbots.com today!

moteus firmware 2023-02–01

robots, ,

Partly to celebrate moteus controllers being back in stock and partly because a lot of important work has backed up, we’ve just released a new firmware version for moteus (2023-02-01) that has a little bit of something for everyone. Future posts will examine some of these features in more detail, but for now you just get the bullet list:

  • Support sending and receiving arbitrary data from a UART configured on either of the auxiliary ports
  • Permit I2C encoders to operate at up to 1kHz
  • Report control position, velocity, and torque as well as the errors in tracking them over the register protocol as 0x038-0x03d
  • Provide support for synchronizing the clock of a moteus controller with a host application
  • Report hall effect errors
  • Expose the drv8353 error flags as register 0x140 and 0x141
  • Fix register 0x006 (ABS port position) to be reported in revolutions

moteus firmware release 2022-07-11

robots, , ,

It has been on github for a few days now, but I’m excited to announce the newest moteus firmware release, 2022-07-11. This release includes some big features, and some quality of life improvements all around.

  • Flexible I/O subsystem: This release includes the new flexible I/O subsystem. This adds support for many new encoder types and lets you connect them up in a wide variety of ways.
  • Cogging torque compensation: Preliminary support for cogging torque compensation is present in this release. It works pretty well on a number of motor types already, future articles will describe it in more detail.
  • Encoder eccentricity compensation: This feature lets you linearize the output position and velocity in the face of non-linear encoder readings. A write-up for it is also forthcoming in the not-too-distant-future.
  • Transparent no-BRS CAN-FD communication: If your CAN-FD network is only capable of operating at 1Mbps, and you send queries frames with BRS turned off, moteus will now respond in kind. This eliminates most needs to change the CAN bus frequency due to marginal electrical properties.

This is an exciting time for moteus, and the new features will keep coming!