For those who have been annoyed by the misplaced I2C connector on the r4.3 moteus model, I’ve finally updated the 2D and 3D mechanical drawings for the moteus controller in github:
https://github.com/mjbots/moteus/tree/main/hw/controller/r4.5
And in the same vein, we received a great user contribution from Rüdiger Koch-Kukies in the form of a solid model of the mj5208 motor!
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!
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:
Thus, the new release, 2021-01-14 which has two improvements / bug fixes:
If you want to upgrade, be sure to use a moteus_tool version 0.3.7 or newer from pypi. Or, if not, make sure that servo.feedforward_scale is set to no more than 0.5 when you’re done!
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!
I’ve been using a relatively inexpensive microscope for SMD soldering work for some time, connected via HDMI to a 24″ monitor.
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.
The only parts I had to purchase uniquely were these 14mm tubes from amazon, some thumbscrews used to tension each of the clamps, a steel plate used to weight the base down, and a new LED lamp. I already had sufficient M4 heat set inserts and mounting bolts to fit everything else together. Here’s a photo from before I had the actual steel weight plate installed:
With new python based moteus tview and moteus_tool available, and the new mj5208 motor being included in all the moteus devkits, I figured it was time to update the moteus getting started video. Here it is!
Welcome to the newest mjbots.com product, the mj5208:
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.
Specifications:
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.
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_pi3hatThe moteus controller is capable of a lot of instantaneous power. However, to fully make use of that power, you’ll need to keep the mosfets cool on the board. moteus has two mechanisms for that:
In addition to the MOSFETs, the gate driver chip, the DRV8323 can produce large amounts of heat, especially when the controller is run at a higher voltage, like the 44V that the moteus r4.5 supports.
Getting the heat out of all those irregularly spaced components on the top can be tricky, thus mjbots.com now has the moteus heat spreader:
This precision machined and stylish black anodized aluminum piece fits over the top of the PCB and mounts flush against both the MOSFETs and the DRV8323 to ensure optimal heat dissipation from all components. It can be used as-is, or with an additional heat sink fixed to the flat upper surface.
Don’t hesitate to ask any questions in the mjbots discord!
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.
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!
Over the Thanksgiving day holiday, I knew I had a bunch of harnesses to build. Rather than being a good corporate steward and actually building them, I instead built a machine to automate the first of the 3 time consuming parts of the harness construction: wire cutting and stripping.
This was just thrown together from two cosmetically damaged moteus devkits, a Raspberry Pi 3 an old development version of a pi3hat, a hand wire stripper, two synthetic rubber bands, an off the shelf 24V supply, and a bunch of 3d printed parts.
Simple automated wire management at the DIY level is not new. It’s been done many, many, many times before. YouTube has decided that every day I need to see someone else’s take on the problem. Look down in the resources at the bottom for my collection of alternate solutions.
What differentiates this version is (1) I built it most from junk parts I had around, (2) since it uses brushless motors it can be both very fast and very precise. Here’s a clip of it executing a few cycles where it strips 3mm from the front end, pre-cuts 3mm from the other end, then cuts the wire to a total length of 5cm. The overall cycle time for all operations is around 1s per wire for the 30cm wires I needed right now.
By replacing the guides and doing some tuning, it should be capable of managing wire between 30 AWG and 18 AWG, although to date I’ve only tested it on 26 AWG.
It did take a bit longer than the weekend — I printed a second revision of everything early the following week, then waited for a panel mount switch to make the power supply look more professional.
Here’s the overview video, with some more shots of it in operation.
The BOM, .3mf’s and source code are in github at https://github.com/jpieper/bstrip. There is a hackaday page here for discussion: https://hackaday.io/project/176211-bstrip-wire-cutstrip
Maybe someone else will find it useful?
