Recent improvements to the mjcanfd-usb-1x and the pi3hat were stepping stones to improved reliability for long daisy chains of moteus controllers. Another step in that process is the feature I’ll describe here, hardware CAN ID filtering in the moteus firmware. Let’s talk about how things used to work, what the problems were and how this new feature helps.

moteus_tool has long served as the primary interface to moteus controllers from the command line for provisioning and diagnostics, especially so when used in headless environments where running a graphical tool like tview is not an option. As anyone who has debugged a moteus system from the command line can attest to, finding the contents of diagnostic stream channels is annoying at best and that is only if you know how to do it. In short, you have to use --console, and then type some undocumented text incantations .

Thus a new feature in moteus_tool: the --read CHANNEL command line flag, which reads a single instance of an arbitrary diagnostic channel from the device, then prints it to the console as JSON formatted structured data. Let’s check out what that looks like:

The tview graphical monitoring application has been getting a lot of work lately. First was support for enumerating controllers by UUID, then monitoring faults and graphically highlighting them and then decoding textual values for fault codes. I’m excited to announce yet another improvement for tview, this one on the larger side: an interactive python REPL (read-evaluate-print-loop)! Available now in pypi moteus-gui v0.3.93.

The bottom console now has two tabs, the first and default remains the diagnostic console, where you can see what diagnostic messages the devices are emitting and send diagnostic channel commands directly to connected devices. The new, second tab, is labeled “Python” and provides access to a fully functional Python evaluation environment with full access to the moteus python library, including asynchronous operations.

Read on to see how to use it.