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!
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.
….
But wait, there’s more!
Now, both moteus_tool, tview, and the python bindings more generally can use python-can as a transport. That means tview can now be used with socketcan, pcan, and a bunch of other options. To one up that, most users won’t have to even specify any command line options, as tview and moteus tool will automatically select a fdcanusb or python-can depending upon what is available.
I’ll be updating the devkit introduction video soon, although the commands in there will largely continue working for the time being.
pip3 install moteus_pi3hatVarious 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.
The solution is to manually specify the bus timings when configuring the socketcan link. This makes the MCP2518FD boards work, and also PEAK-CAN-FD USB adapters (and probably every other socketcan CAN-FD adapter) work as well. You can find the timings linked in the moteus reference documentation: https://github.com/mjbots/moteus/blob/main/docs/reference.md#bit-timings
As a result of all this debugging, I made some general improvements to socketcan support in all the client side moteus tools.
Thanks for everyone on discord’s patience as we worked through these compatibility issues!
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.
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.
The r2 boards did have a DB9 pinout that was not industry standard, this time due to Eagle’s DB9 footprint being broken, but that will be easy enough to fix in r2.1.
The software had three things that needed to work, FDCAN, USB, and the finally all the glue logic. Getting FDCAN to work was remarkably easy: I just used the STM HAL APIs and was basically done.
USB was harder. The last time I made a virtual serial port for the STM32, the mjmech gimbal board, I used the STM provided CDC libraries. However, those are released only under a rather restrictive license, confusingly named the “Ultimate Liberty Software License Agreement”. Despite the claims in the title, you actually have very little liberty, in that the software can only be used on STM controllers and has notice provisions as well. As with the rest of the moteus universe, I wanted to be able to release this firmware under a permissive license so needed to look elsewhere.
Github and google found a number of candidates, and the one that I ended up starting from was dmitrystu/libusb_stm32. It was already licensed under the Apache 2.0, and supported controllers which looked like they would be very similar to the STM32G4. Sure enough, the STM32L433 has an identical USB peripheral and was already supported.
I ended up forking that repository into the fdcanusb one and modifying it slightly to be usable with C++ and mbed. Also, interestingly, the CDC demo used the same endpoint for RX and TX, which the linux drivers didn’t seem to like so I just gave them separate endpoints like I’ve done before. I then implemented a wrapper for the CDC class which presents the same asynchronous serial interface as everything else in mjbots/mjlib and was set to go.
The final piece of the software was all the glue and application logic. I just used PersistentConfig and CommandManager from mjlib, which gave a human readable ASCII interface out of the box. Then I wrote up the application logic in CanManager, which didn’t have to do much at this point.
In its current state, the fdcanusb firmware is capable of communicating with the moteus r4.X series controllers just fine. Next I’ll get a few more made to distribute with moteus development kits and see if there is any more demand for them.
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 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.
The notable features:
All for an expected sales prices of around $100.
This does come with some caveats: For one there is no galvanic or optoisolation, you get a common mode range of around +- 12V. Another is that using just a USB 2.0 full speed interface means it may not be able to keep a FDCAN bus fully saturated at high bitrates. Finally, the firmware will start out with just the bare bones capabilities, but can be extended to support features such as error injection, triggers, buffering, and more compact protocols in the future.
I’ve got the first functioning prototypes of these boards in hand now:
Next up I’ll describe bringing up this board.
A Modicum of Fun 