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!
With the release of more flexible I/O support, the moteus controller auxiliary port can be used to monitor encoders using an onboard UART. Now, with firmware release 2023-02-01, those UART pins can be used as an arbitrary logic level serial port controlled by the application! Let’s see how to use it below.
First, you will need to look at the pin configuration table to find pins that support UART functionality, and configure them as UART in the “aux?.pins” configuration tree. Next, “aux?.uart.mode” should be set to “kTunnel”, along with the desired baud rate. That’s it on the configuration front.
The moteus controller, when it implements its control algorithms, uses the internal RC oscillator of the onboard STM32G4 microcontroller to calculate things like velocity and to advance position over time. Typically, this is accurate to within 0.5% which is more than sufficient for most applications. However, there are cases where it does matter.
One common case is when multiple moteus controllers are operated together, and either the relative velocities of the controllers must match closely, or the time required to complete long trajectories must match closely. For example, if a trajectory would take 100s to complete, then a 0.5% difference in clock rate between two controllers would result in one completing 0.5s before the other.
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
While testing moteus controllers, it is often necessary to experiment with high power conditions. For short durations, any decent sized brushless motor can work, as the windings have a non-zero thermal mass and take a little bit to warm up. However, when testing at high power for extended duration, it can be hard to find a way to get rid of all output energy. Even blowing a fan directly onto a motor only gets you so far when you are trying to get rid of 1kW.
Here’s a not-so-brief story about troubleshooting a problem that was at times vexing, impossible, incredibly challenging, frustrating, and all around just a terrible time with the bare-metal STM32G4 firmware for the moteus brushless motor controller.
First, some things for context:
moteus has a variety of testing done on every firmware release. There are unit tests that run with pieces of the firmware compiled to run in a host environment. There is a hardware-in-the-loop dynamometer test fixture that is used to run a separate battery of tests. There is also an end-of-line test fixture that is used to run tests on every board and some other firmware level performance tests.
I documented the first test fixture I built for moteus some time ago. As the shipment volumes have gone up, the fixture became something of a limitation, and also was a little problematic in a few ways.
First, it relied on attaching 3 connectors by hand for each test, which was a decent fraction of the cycle time. Second, the pogo pins it used were non-replaceable, and also connected only to the debug phase wire test vias, which were tiny. They wore out relatively quickly, and replacing them required building a whole new board. Finally, since the pogo pins were PCB mounted, a PCB needed to be printed for any change in the pin locations or which pins to probe.
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.
This is an exciting time for moteus, and the new features will keep coming!
First, if you haven’t already, check out these introductory posts:
Second, this article is available in video form:
Third, the official reference documentation can be read here. This describes in detail all of the possible configuration values.
This will be the final post describing the fundamentals of configuring the new flexible I/O system. There have been a number of previous posts (part 1, part 2, part 3). In this iteration, we’ll cover how to configure the sinks that consume the “source” encoder data. As a reminder, the block diagram of the I/O system looks like:
To perform commutation with field oriented control, moteus needs to know the relationship between the rotor and stator in the magnetic domain. With the addition of the new flexible I/O system, some of the configurable values associated with this remain as they were, where there are some new ones.
