Since the fdcanusb, and subsequently the mjcanfd-usb-1x, have been released, the only interface they presented to a PC host was a USB CDC (communication class device). That meant they appeared as a modem, on linux as /dev/ttyACMx and on Windows as COMx. Sending and receiving frames was pretty simple using a basic line based protocol.

This works fine as long as you are either using the mjbots tools, or designing a complete custom application. However, if you want to use the adapter with other CAN or CAN-FD based applications on Linux, there wasn’t a whole lot you could do. There was a simple daemon which, with a fair amount of effort, would make the hardware appear as a slcan device, but that was finicky and hard to get working and not terribly reliable.

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.

After receiving many requests via youtube, discord, and email, I’ve finally gone ahead, bitten the bullet, and updated all of the moteus tools to be pure python and work in a cross platform manner. Now, the only thing you need to do to install pre-compiled versions of tview and moteus tool on most* platforms is:

pip3 install moteus_gui
python3 -m moteus_gui.tview    # (or maybe just tview)
python3 -m moteus.moteus_tool  # (or maybe just moteus_tool)

I’ve personally tested these on Linux, Windows, and Raspberry Pi, and others have at least verified basic operation on Macs. Python 3.7 or greater is required.

Various users have been trying to use lower-cost Raspberry Pi CAN-FD adapters for the moteus controller for some time (like this one from Seeed), but have had problems getting communication to work. I buckled down and went to debug the problem, discovering that the root of the issue was that the linux kernel socketcan subsystem calculates very sub-optimal CAN timings for the 5Mbps bitrate that moteus uses. This results in the adapters being unable to receive frames sent at the actual 5Mbps rate, but instead only slightly slower.