To date, the pi3hat CAN channels only supported CAN properties suitable for use with moteus controllers. Given that’s what most people are using them for, that’s fine. However, there was no real constraint behind that, just laziness.
Thus, I’ve released new firmware for the pi3hat that supports configuring the bitrate, FD-ness, and other properties of all 5 CAN channels.
It seems like all the posts I’m writing these days are for new products! Here’s the pi3hat r4.4:
There are two changes from the previous r4.2. First, it now supports voltage inputs up to 44V. Second, in support of future upgrades, the 5th CAN-FD port has been upgraded to support 8Mbps, but downgraded to no longer have a wide common mode voltage range.
THUS, IT IS NOT SAFE TO CONNECT THE CAN-FD PORT ON THE pi3hat r4.4 TO A power_dist r3.X BOARD.
That said, the worldwide electronic supply chain is still in shambles. That combined with the Chinese New Year means that stock may be intermittent, and slight alternate versions to adjust to different parts may be forthcoming.
Sometimes you find bugs, and sometimes the bugs find you! While getting ready to release some updated qdd100 beta servos, I was investigating speed control in the moteus firmware and discovered an unwelcome surprise!
To improve dynamic response under high accelerations, moteus uses a voltage feedforward term as part of its control loop. When trying to command a specific current, it normally applies a PI controller to determine the resulting D and Q phase voltages to apply. The feedforward component of this looks at the phase resistance and the current rotor velocity, and determines a zeroth order estimate of what voltage would be required to achieve that current under a no-load condition, only using the PI controller to determine the difference.
This technique has been in use since my earliest direct drive leg jumping experiments. However, at some point before I added support for gearing reduction in the controller, there was a lot of confusion in the code base around the sign of the torques vs. the sign of the encoder. When that was sorted out, I missed the fact that the resolution ended up leaving the velocity component of the feedforward with a *negative* value. This meant that instead of helping the PI controller, it made the PI controller have to work twice as hard!
The easy, and not-so-easy fix
Fixing this for new controllers involved changing just a single character change from ‘-‘ to ‘+’. However, there is a configuration value which applies an overall scaling to this feedforward term, and has been 1.0 for all released moteus controllers. With the correct sign, a 1.0 scaling factor can result in unstable performance at high velocities.
Knowing this probably won’t be the only complicated upgrade procedure for the moteus controller, I decided to invest in a little infrastructure to make it easier in the future. This is built on two components:
The “firmware version” was always stored in the firmware image and reportable over CAN. Until now, it has always been 0x00000100. I’ve now set this up so that the version is stored as a top level symbol in the firmware .elf file that automated tools can inspect.
moteus_tool now checks the existing firmware version, and the new firmware version. When crossing given firmware versions, it can apply programmatic rules to update the configuration to maintain as close as possible semantic values. To make that robust, it refuses to flash firmware versions newer than it is aware of.
While testing some variants and new versions of the power_dist board, I wanted to be able to simulate the types of loads that it experiences with a fully loaded robot. Some things are easy, like this capacitor attached to an XT30 connector:
I also have giant power resistors in a similar form factor:
However, a dumb load resistor isn’t a particularly representative load. Most likely, the loads that a power_dist will drive are active loads with switching regulators. When the output voltage is lower, the current will be correspondingly higher. That is especially important when validating pre-charge behavior, because it means that the current is much higher during the initial pre-charge window than it would be for a pure resistive load.
Thus, I made a tiny switching regulator to which I can stick a load resistor to the output.
Unfortunately since MacroFab discontinued their prototype tier, it no longer is as convenient to get one offs populated in the US. So this one I did by hand with a stencil, solder paste, a 3D printed frame, and some new tools, a vacuum pick, and a hot plate. I discovered you can get room temperature stable solder paste now — how convenient!
There were a few bugs… I managed to not have 0603 resistors for the voltage sense divider on hand, but had 0402 of the right values so just stuck a blob of solder to connect them. On the same resistors, I also managed to get the PCB labels swapped. Fixing that resulted in a board that does what it is supposed to!
For the price, I’m definitely happy with it, but as I’ve been doing more soldering work, I’ve become less happy with the mounting stand. The arm it mounts to often does not reach far enough to get the optics over the part of the board in question, or the base is too tall or wide to fit under it. If you want to examine something from the side, you have to tip the entire base over. I have resorted to spinning the microscope around and counterbalancing the base with a large weight, which works for some definition of “works” but only improves the reach by a little bit.
I wanted to improve the situation, so built a 3d printed mounting fixture to position the microscope head. It provides for a few more degrees of freedom than the factory issued one, and provides a lot more reach:
The tubes are held together with M4 bolts with each axis having a thumbscrew used to lock it in place. The optics can now be tilted in the pitch or roll direction, and the total reach is around 25cm, up from the stock 7cm.
This is a high quality 5208 sized 330Kv wound brushless motor with short pigtails intended to connect to moteus controllers. All the moteus devkits as of last week are shipping using this motor instead of the previous “semi-random” motor.
Peak torque: 1.7 Nm
Mass (with wires): 193g
Peak power: 600W
There are two bolt patterns on the output, a 3x M3 17mm diameter one, and a 2x M3 pattern spaced at 12mm. The stator side has a 4x M3 pattern spaced at 25mm radially and a 3x M2.5 spaced at 32mm. The axle protrudes a few mm from the stator, making it easy to adhere the diametric magnets needed for moteus.