Tag Archives: fixture

Resistive heater dummy load

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.

Thus enter my resistive dummy load:

This is just a block of DC water heaters screwed into a plastic container. They are wired in series with some high current inductors to roughly approximate the inductance and resistance of a motor in the range of what is normally driven by moteus. When conducting a test, the container can be filled with water to greatly increase the available thermal mass (and if need be boil away the water).

Parts and Assembly

I have used this fixture with two different elements, a 24V 900W one, and a 12V 600W one depending upon what resistance I want to test with:

The container is just a basic polyproplene plastic one, so that it should be safe up to at least the boiling point of water:

The inductors are 33uH, 30A:

To assemble, I used a 1.25″ hole saw to cut each of the holes, then used a 1″ NPT nut to fasten each element in place. Each phase connected to 3 of the inductors in parallel in series with 4 of the heating elements. All three phases were tied together in the center to form a wye topology.

Gear testing fixtures

The qdd100 servo uses a planetary geartrain as the transmission reducer. This consists of an outer ring gear, an inner sun gear connected to the rotor as the input, and 3 planets connected to the output. The tolerances of these gears directly impacts the performance of the servo, namely the backlash and noise.

To date, I’ve been hand-binning these and testing each servo for noise at the end of production. To make that process a bit more deterministic, and with less fallout, I’ve built up a series of manual and semi-automated gear metrology fixtures to measure various properties of the gears.

Some of the simple ones are just tools to hold micrometers in convenient locations relative to gears or meshing gears, like this one to measure the OD of the ring gears at various points:

Or this one to measure the meshing of the sun gear with a rack gear:

Or this one to measure the meshing of a ring gear with a reference sun gear:

Semi-automated tools

As I went to use these techniques for production, manually measuring the gears both was tedious, and still not as useful as it could be. It wasn’t feasible to do more than record a minimum and maximum when measuring a gear by hand, and for some parameters, measuring it at many points around the circumference is helpful. Thus, I’ve started on some automated gear testing fixtures.

The first is one that tests sun gears against a reference planet:

This has a few pieces. The motion platform is a moteus devkit motor with a reference planet gear attached. This spins a “test” sun gear which rests on a linear rail. Then a dial indicator is positioned to record the position of the carriage. An arduino connects to the SPC data port on the dial indicator to programmatically read the position. I used a technique similar to this forum post, except that my iGaging dial indicator runs off about 3V, so I didn’t bother with a separate pull down transistor and just toggled the REQ pin between input and output low to initiate readouts. That meant I could just plug the 4 wires directly into the Arduino.

When this runs, the reference planet is spun through small increments and the micrometer reading is captured at each point. This measures the “double flank” mesh distance of the gear pair. Here, the indicator spring applies a pressure to the test gear, forcing it to mesh with the master gear.

To make this work, I characterized the reference planet gear by running a reference sun gear (which is a 20 tooth M0.5 gear), at all 20 different phases relative to the planet. Then I took the median of the distance across all the runs as the “reference curve” for this planet.

Then test gears are measured relative to that reference curve. That shows the delta between the center distance at each point and the reference distance, so should be relatively well calibrated for the fact that my master gear is not perfect, nor mounted perfectly concentric. Here is a plot from the same gear taken four times at different phases, shifted laterally to compensate for the phase difference and shows that it is relatively consistent and repeatable.

The process is unfortunately slow, primarily because the dial indicator SPC port only emits data at 2Hz, and it takes about 2 readings to settle after each motion. I was using 8 points per planet tooth for the above plot, which works out to 320 total samples per evaluation. At 1.5s per sample, that is around 7 minutes per gear! Fewer points still give reliable results, at a corresponding reduction in fine resolution.

Forgiving the slow speed, this does seem to give profiles that are repeatable to within about 10 microns, which is good enough for the binning I am doing now.

Quad feet construction fixture

The quad A1 was the first robot I built with foam cast feet.  When I did the first feet, I jury rigged a fixture from some old toilet paper rolls to hold things in place while they were curing.  When I went to rebuild with my most recent leg geometry, I figured it was time to get at least a little more serious.  Thus, my new leg casting fixture:

dsc_0578

When an insert is cast into place, it is set on one of the trays, the tray is inserted into a slot, and then a weight can be placed on top and constrained by the fixture.

dsc_0579

This makes the casting process more repeatable and faster as I scale up production.  As a bonus, it can also be used as a fixture to epoxy the lower leg to the insert:

dsc_0591

Leg zeroing fixture

As part of provisioning a quad A1, or anytime the mechanical configuration has been changed, I need to go and record where the zero position of all the joints is.  The “0” position for the software now is with the shoulders perfectly horizontal, and the upper and lower leg sticking straight down.

Up until now, every time I’ve done this it has just been by eyeballing and with lots of foam and bubble wrap to shim things into place long enough to record the level.  Sometimes I had to go back and try a few times, as even determining when something is straight is not, well, straightforward.

So, I made two new fixtures to help with this process:

dsc_0608

One that rests on a flat surface and supports the shoulder to be exactly level, and forces the upper leg to be exactly at a 90 degree angle.  This assumes the robot is flipped over on the same flat surface.  The second snaps between the upper and lower leg, forcing them to be exactly straight.

With these two fixtures, I was able to get repeatability of my calibrations down to less than half a degree, which should be good enough for now.

 

Programming and testing moteus controllers

Like with the fdcanusb, I built a programming and test fixture for the moteus controllers.  The basic setup is similar to the fdcanusb.  I have a raspberry pi with a touchscreen connected via USB to a number of peripherals.  In this case, there is a STM32 programmer, a fdcanusb, and a label printer.  Here though, unlike with the fdcanusb fixture, I wanted to be able to test the drive stage of the controllers and the encoders too.

My solution was to create a mechanical fixture that each board slots onto, with pogo pins that connect to test points for the phase outputs.

dsc_0428

While it doesn’t make as good a connection as the solder through holes normally used to connect a motor, it is good enough to verify that the controller works.  As a side-bonus, it also makes it trivial to test that the absolute magnetic encoder works properly.

This video shows how the programming and testing process works, and walks through testing a few boards.

Programming a lot of fdcanusbs

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:

dsc_0188

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.