I am a big fan of MacroFab. They’ve built a PCB + assembly + more service that is transparent, high quality, and nearly completely self service. They appear to be making money, so hopefully they will stay in business for some time.
On top of that, they offer a “quick turn” option which gives you populated boards shipped 10 business days after you order them (and I’ve even had them ship out a few days early from time to time)! The only annoyance is that the quick turn option is limited, as I’ve mentioned before, to boards that meet certain criteria, among them having 20 or fewer items on the bill of materials. To try and get this first quadruped prototype up and running quickly, I’ve been exclusively relying on quick turn boards, which means making some compromises. Even after some moderate design sacrifices, I haven’t been able to get the servo controller board to 20 parts. At the moment it is 23. Thus, when I received the first big-ish PCB order I’ve made (qty 28), I got to spend a morning populating the remaining 3 components on all 28 boards.
Unfortunately, as painful as that was, it was still worth it as opposed to waiting an additional 3 weeks for the non “quick turn” service.
For posterity’s sake, the only difference between the r3 and r3.1 board is some silk screen changes, and one or two equivalent part substitutions.
I’ve now managed to get all the custom and long lead time parts in house for the first version of a quadruped based on the new actuators I’ve been designing.
That includes all the motors, custom brackets, and at least moderately working versions of all the custom PCBs. Now I just have to get the local rework done, get the software into a semi-reasonable state, and put it all together!
The full quadruped robot needs to both distribute power from the primary battery and RS485 serial network to all 12 servos. To make the wiring of that easier, I’ve made up a junction board to provide power connectors, distribute the data network, and act as the IMU for when that is necessary.
The RS485 network is bridged between two halves of the robot. One connection comes in from the controlling PC and two separate links go out, one for the left side and one for the right side. This could eventually allow the controller on the junction board to take intelligent actions itself, such as querying the force applied on all 12 servos. It could then return the result in a single RS485 transaction to the host computer. I am expecting that will be necessary to achieve closed loop control approaching 1kHz.
It also includes a Bosch MEMS IMU. The junction board will be rigidly mounted to the quadruped chassis, which means it is an ideal location for an attitude reference. I haven’t integrated the IMU software from the gimbal yet, but have verified that the IMU is operational.
Finally, it has a 3.3V regulator on board to power all the logic level chips from the primary 18V supply. I managed to toast two of these by not having sufficient input capacitance, and hot-plugging a lab supply to the power lead. The inductive transient caused the regulators to over-voltage, resulting in a short from power to ground. This is apparently a relatively common design mistake with this part according to TI’s E2E. I attempted to rework replacement parts on the board, but due to a cascade of failures from USPS to my soldering, I gave up and just spun another revision.
In the meantime, I took one board and manually powered its 3.3v supply to bring up the firmware, and I’ve converted the other to a “dumb” mode, where it has no 3.3v supply and all the RS485 ports are just hard-wired together. (Note the very tidy blue-wiring and hot glue.)
That should be enough to make progress with getting the full mech working, even if the control frequency is limited.
After my self-education on MLCC derating I spun yet another low-volume prototype run of the servo controller. This one has more than double the effective capacitance by doubling the number of capacitors and by selecting capacitors that have less derating. I also fixed an incorrect pad geometry for the 6 pin ZH connector, optimized the BOM count a bit and reselected parts that were no longer available.
To validate that this controller revision was robust enough to get a full mech’s worth of them made, I wrote up a simple test tool which ran the leg through a continuous jump cycle. The goal was to validate the thermal design of the controller and motor, and while I’m at it, test the robustness of the 3d printed mechanical leg parts.
I knew endurance testing would be a process. That said, this was a pretty interesting one.
First up: The RS485 cable joined into a screw terminal in part of the cable that moved up and down during a jump. This had been coming loose on and off for me previously, and now was a limiting factor. The fix was simple, move the terminal block further down the cable harness so that it didn’t move during a jump.
Next, an even simpler problem. The leg wore through some gaffer tape I had on my sheet of jumping foam and it became stuck to the adhesive. I just moved the leg so that it didn’t jump on tape.
Now, an exercise in thermal management. I gradually decreased the current used during the jump and landing phase until the steady state temperature of the controllers didn’t exceed my somewhat arbitrary 60C. At that point, the 3d printed parts were starting to outgas a bit, so I figured that was a decent upper limit.
With those changes, I was able to get it pogo-sticking pretty reliably for 6 or 7 minutes at a time. Here’s a video of the end of one of those runs, at which point you can see the next problem.
A more vexing problem
As seen above, after jumping for approximately 6 or 7 minutes, eventually the yaw axis would fail in a way that resulted in the electrical phase detection becoming offset. The offset appeared to grow over time. Eventually, this resulted in a loss of control in the lateral axis servo, when the D and Q currents became swapped.
This problem was most mysterious. The lateral motor is basically doing nothing in these tests, the overall torque applied is maybe 1/50th of that which the upper and lower leg motors are generating. My first thought was that perhaps the magnet which was attached to the shaft was faulty or had become demagnetized. So I swapped it out, and while I was at it, added a spacer so that the magnet was closer to the magnetic encoder.
No dice. Same failure, although this time I got 15 minutes of jumping in before it failed.
Another thought was that the rotor was somehow slipping on the axle. However, the set screw was definitely still firmly in place, and this seemed pretty unlikely anyhow, since there was almost no torque on it. The upper and lower leg motor with 100x the torque were not slipping.
Finally, I concluded that the bracket itself was deforming, resulting in the magnet changing alignment with the magnetic sensor. In this configuration, the entire leg is cantilevered out. Additionally, the linear rail fixture results in a large amount of torque being applied to the yaw bracket.
I already had beefier brackets coming in for other reasons. I swapped them in, along with some new leg hardware to be described later. Now with some forced air cooling I was able to even jump a reasonable height without stopping. Here’s an endurance run showing the most aggressive jumping it could do indefinitely.
And here’s another video showing the max height I could get on this jumping fixture, which it could do for about 2 minutes before exceeding my safe temperature limit.
And for fun, a snapshot of my desk while recording one of the endurance videos. It is quite tedious to let the leg jump for hours at a time while hoping nothing goes wrong!
The controllers for the improved actuators for SMMB have a moderate amount of power to deal with. During jump maneuvers they can put 60 amps of phase current into the motor, and I’ve applied for very short intervals over 500W of power to a motor. The FETs on the board are relatively high performance, but there is still a fair amount of heat that has to be dissipated.
When getting started, I knew I would likely have to do something to get heat out of the board and had a two stage plan. The first was to heatsink the back of the controller board and second, if that wasn’t enough, heat sink the front of the board.
The back of the board has copper planes on the bottom-most layer which are connected by many vias to the primary FETs, with the express intent of heatsinking to them. A heatsink on that side can thermally couple the control board, through the solder mask, to the motor mounting bracket and the motor itself.
I went with just a simple waterjet cut aluminum plate of appropriate thickness and some kapton tape covering the holes that lacked soldermask on the back of the board. Here’s a bunch of the first revision back from eMachineShop:
Installed onto the controller and motor, this looks like:
I tested thermal dissipation of the controller with no back heatsink, with a back heatsink but no thermal paste, and with the heatsink and thermal paste. In each case, I tried to let the temperature reach steady state while wiggling the motor around to apply approximately equal power to all phases.
Backplate w/o Paste
Backplate w/ Thermal Paste
For these motors, the motors themselves have thermal problems even at 25A continuous, so this means that just the back plate with thermal paste is enough to make the controller not be the limiting factor. Thus there’s no need to mess with what would be a more complex to design and manufacture front heatsink as well.
The first revision of the brushless servo control board for SMMB was successful in getting a leg to jump. I ended up doing a small-run second revision that addressed a few minor problems and added a couple more capabilities.
RS422 Debug/Link Port: I had a 3.3V serial port exposed previously for debugging, however it caused my USB-serial converter to dislike itself due to common mode ground shifts and it wasn’t reliable at high baud rates (>3Mbps). I also wanted to support “linked” modes, where two servos would perform control in the actuator space at full rate.
Debug through holes: r1 had a number of debug connections, all of which were unpopulated SMD pads. I decided that through holes were easier to connect debug wires to.
Vertical SWD connector: I had initially thought I would hide the SWD connector within an enclosure. However, the initial enclosure prototypes made that seem less desirable, so I switched it to vertical.
More debugging points: When bringing up the first board, I ended up doing a lot of carefully balancing scope probes on various pins, when there was plenty of board room to just have through hole debug points. Lesson learned.
FET temperaturesensing: r1 just had an external temperature sensor port, r2 additionally has a thermistor next to the FETS.
Macrofab’s current pricing scheme provides a great incentive to keep your BOM below 20 parts, as that is the only way to get quick turn service. Otherwise you pay an extra 2 or 3 weeks of calendar time. In r1, I went to some lengths to stay under 20, however, it just wasn’t going to work with r2, so I left a few easy-ish or non-critical parts unpopulated to do them myself: the connectors, LEDs, and one really big diode.
While working on the improved actuators for SMMB, I wanted to be able to perform some quantitative experiments to design the thermal transfer of the controller board and enclosure. I figured that feeling with my fingers probably wasn’t scientific enough to make consistent progress.
It has a resolution 220×160, reads up to 300C and being intended for construction inspection has at least a little software support for reading out actual temperatures and capturing images for reports. The only downside is the focal length. It really can’t focus on anything less than about a meter away. That isn’t too great for PCB inspection.
Enter this eevblog thread, describing at least one person who added a lens for a macro mod. I gave it a try, getting an appropriately specified laser cutter lens from Amazon: ZnSE w/ approximately 100mm focal length labeled as “Laser Engraver”. A non-affiliate link for the exact one I got is: https://www.amazon.com/gp/product/B01DP2HSAY
I could have 3d printed a fancy lens mount, but decided I would see how well a quick and dirty hot glue gun job would work:
And the answer is pretty good — I can resolve individual 0603 components on the board just fine.
As part of preparing Savage Solder for events this spring, I’ve been overhauling the computer and sensing platform to have higher reliability and lower weight. One of the changes was a new LCD and input interface.
I wrote up the previous LCD here before, which was the width of the car, pretty heavy, and not resistant to the elements. For this version, I wanted to use a smaller screen, and remove the possibility of moisture getting into the case, while still maintaining roughly the same USB interface.
PCB and Assembly
The display I ended up using was the 2.2″ TFT LCD from Adafruit. It is color, has sufficient pixels to display everything we wanted, and has a SPI interface. The other half of the solution is the input device, for which I decided to use an off the shelf MPR121 capacitive touch sensor controller, with a breakout board, also from Adafruit.
As before, these were glued together with a custom board holding an ATMega32U4 and a few other miscellaneous components. It is mezzanine mounted to the LCD and touch board, and has and external JST connector for USB. Also custom printed was the touch sensor itself. It is nothing more than a PCB with solder-masked copper where each of the touch sensitive areas should be, pulled out to a connector on the back.
The entire assembly was designed to be mounted to the lid of an off the shelf enclosure with a clear polycarbonate lid (which is where the rest of the electronics is going). The LCD and touch board each have four mounting holes, which are attached with a bolt, nut and lockwasher assembly. Sealing is accomplished with neoprene o-rings on the outer surface of the lid.
The MPR121 has a lot of options, many of which influence the performance of the device. The enclosure I am using is an off the shelf one from BUD (PN-1324-C amazon link). It has a polycarbonate lid approximately 1/8″ thick, which is kind of at the extreme of what you can get capacitive touch sensors to work through. I was inspired by Adafruit’s MPR121 library, but rewrote it to not require Arduino. I had to tweak a number of the MPR121 constants as well to work under the thick polycarbonate:
0x20 (32uA charge current)
For rendering text on the display, I also based my code on the Adafruit ILI9340 library. Since this LCD controller has to render text one pixel at a time, it was much slower than the HD44780 text-based controller we were using previously. To get remotely acceptable performance, I had to make the AVR keep a framebuffer around, and only re-draw characters which had actually changed.
One of the improvements we made for this year’s Savage Solder entry into the Sparkfun AVC (and maybe other competitions, I’m looking at you Vecna Robot Race), is an updated baseboard. Our old baseboard was a Teensy 2.0+ soldered onto a hand-built protoboard and then wired up to an external IMU mounted on the front of the chassis. For fun, I decided to replace that board with a more integrated unit which installs more cleanly into the car chassis and is based on the firmware I’m developing for the ARR.
The board hardware includes:
3 servo inputs: The Savage Flux RX receiver has 3 outputs, for throttle, brake, and an auxiliary channel.
4 servo outputs: We are only using 2 channels currently, but it was trivial to wire up 2 more.
Pins and mounting for stacked MiniIMUv2: Rather than have the IMU need a long-run cable and dedicated mounting, it is now integrated into the baseboard. The I2C can be run at a 400kHz in this configuration, and thus the IMU can be sampled at a higher rate if necessary.
USB device port for connection to host PC: We use a small form factor Intel motherboard as a host computer, the USB connection, while not particularly reliable, is sufficient for the competitions Savage Solder enters.
Sensored motor feedback for odometry: This provides the primary odometry for the car.
General purpose digital inputs for emergency switch, and bumper switches: Our emergency override switch and robomagellan bump switches can all be treated as simple logic inputs.
Battery voltage sense: One ADC channel was wired to a connector to measure the drive battery voltage.
This was another oshpark.com job, and the layout was relatively straightforward. The biggest wrinkle was that the first revision was non-functional due to a broken AVR eagle package. Who would figure that the no-name library I downloaded from some shady site didn’t have a ground pad? The crazier thing was that it kind of worked, despite all the vias that it placed under the part were shorted out by the pad.
The board was mechanically designed to fit into an otherwise unused space forward of the steering servos on our Savage Flux chassis. There are two screws there that attach the chassis to some suspension components on the underside. I just replaced those two screws with slightly longer ones, and added a spacer underneath.
As I mentioned before, the firmware was based on that I am creating for the ARR. The basic architecture is the same, in that a master computer communicates with the baseboard over USB, and the baseboard provides high rate servo, I2C communication, and other miscellaneous functionality. I’ve written up the basic servo functionality and engineering test fixture of the firmware previously. Versus our previous controller, the servo control is much improved, both in the precision and accuracy of input and output, as well as having access to more channels. While the firmware supports 8 input and 8 output channels, the Savage Solder baseboard only has 3 inputs and 4 outputs routed to any connectors.
I added a few new pieces of functionality to make the firmware usable for Savage solder, namely:
Configurable Emergency Passthrough / Override: The controller can be configured with two very short functional scripts which can be used to evaluate various servo and GPIO conditions. One determines whether all servos should be placed in the pass through configuration, and the other determines if computer control should be allowed. These allow both for the Savage Solder emergency safety scheme, as well as any I will use on ARR in the future.
Encoder operation: Savage Solder uses the sense leads from our sensored brushless motor as an encoder. The firmware measures these to report total distance traveled. Versus the old firmware, it now counts in true quadrature, giving 4 times the resolution.
GPIO operation: The board exposes control and sensing of a few general purpose input and output pins. They are used to control the LEDs on the board, sense the onboard emergency override button, and sense the bump switches we use for robomagellan style competitions.
The baseboard has been installed in the car since late July 2013. Yes, this post is very belated! In that time, it has been used for all of our testing and appears to be working quite well. Or rather, it hasn’t been the source of any problems yet!