Probably one of the most frequently asked questions in the mjbots Discord is “how fast can I send new commands to moteus”, or “how fast can I read the status from moteus”. That may be because you want to perform torque based control in your application and require high bandwidth, or just because you have a high torque to inertia ratio system that reacts on very short time-scales. No matter the reason, the principles that control the maximum rate you can send updates are the same.

While it may not be technically spring outside, it is spring for product announcements here at mjbots, and I’m excited to announce the next evolution of CAN-FD adapter hardware we’re offering, the mjcanfd-usb-1x:

The major changes from the fdcanusb:

• USB-C instead of USB micro

• Smaller form factor - 30x18mm

• PH3 CAN-FD connector instead of DB9

• Less expensive, only $39

This makes the mjcanfd-usb-1x better suited for in-application deployments and just all around better as a development tool. It can be mounted down more easily, uses the same connector and pinout as moteus, and is compatible with our existing PH3 cables.

mjbots.com had a week long run where we were completely out of fdcanusbs, which meant that we were also out of all development kits too. Well, a production run just came in:

So now we’ve got everything back in stock once again!

• fdcanusb
• moteus r4.5 development kit
• qdd100 beta 2 development kit

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.

To get ready for the initial limited release of fdcanusbs, I needed to program a whole bunch of them.  Further, I wanted to be able to scale up a few factors of two without being too annoyed with manual steps.  Thus, enter my minimal programming fixure:

It isn’t much, just a raspberry pi 3b+, the official 7" rpi touch screen, a STM32 programmer, a “fixtured” fdcanusb to drive the device under test, and a label maker.  The touch screen is mostly there to display the results if anything goes awry, as in normal operation there is just one button to push.  The final cycle time to program a fdcanusb and install it into the enclosure is around two minutes, which is good enough for now.

I’ve received my first production run of the fdcanusb CAN-FD USB adapters and they are up for sale at mjbots.com!

While this is necessary for interacting with the moteus controller, it is also a fine general purpose CAN-FD adapter.  At the moment, the USB interface is a platform independent line based serial one (Windows, Linux, MacOS).  It doesn’t yet interoperate with SocketCAN on linux, but hopefully that will be resolved in the not too distant future.

To get ready for initial limited production of the fdcanusb I wanted to make some kind of enclosure so that you didn’t have to just grab the raw PCB and risk ESD failures.  I also wanted to be able to expose the status LEDs without having to do a window or anything else with multiple materials.

So for now, I just used a translucent PETG print, with light pipes and a thin wall above each of the LEDs.  The result isn’t too bad, you can clearly see the status LEDs and it feels plenty rugged for desk work.

I introduced the fdcanusb previously, now I’ll describe some of the process and challenges in getting it to work.

Hardware

My initial challenges were around the PCB design and manufacturing.  To begin with, my very first revision was sent out for manufacturing with the same incorrect pinout as the moteus controller r4.0 and thus was only really usable as a paperweight.  Second, the supply of STM32G474 chips seems to be spotty now, so for r2 I had to scavenge chips from the boards that had broken pinouts.

One of the necessary pieces for bringing up the moteus brushless controller and for ongoing development with it is being able to communicate with the device on the desk.  There aren’t many options for desktop FDCAN communication currently, and certainly none that are in the affordable range occupied by the [CANUSB family of devices](http://CANUSB family of devices) which I’ve used before and was very happy with.  Thus I created “fdcanusb”, a USB to FDCAN converter that allows one to communicate with FDCAN devices via a USB interface using a documented protocol, no drivers necessary.