Previously, I described the overall plan for my improved foot. To make that work, I needed to cast a 3d printed part into the squash ball such that it would likely stay attached during operation, be suitable rigid and yet damped, and do so repeatably.
To start with, I used a random single yellow dot squash ball with a hole cut in one side using a pair of side cutters. For the casting foam, I just used Smooth-On Flex Foam-IT 17, which is what Ben Katz originally used at least. Initially I just mixed up a batch, poured it in to a random level, stuck my bracket in and hoped for the best.
Well, something sure happened! But not exactly what I wanted. The foam didn’t fill in the interior cavity, nor make a great connection overall with the bracket. On top of that, the process wouldn’t exactly be described as “repeatable”. Since I just eyeballed the level of foam, there was no way to get the same amount in.
For my next runs, I decided to do everything by weight. I tried a few different foam masses, curing orientations, and venting strategies. Eventually, I got something that seems to look pretty good. We’ll see how well it works on the actual machine shortly!
Here’s a bunch of different intermediate attempts:
And here’s a cutaway of the process I’ve settled on for now. This particular one has a slight bit of overfill on one edge that is more than is typical, but the inside fill is pretty good:
As mentioned long ago in my post on failing more gracefully, it was obvious I wanted to strengthen the lower leg and foot mechanism to remove the point of failure observed there. For now, I’m attempting to basically copy the original Mini-Cheetah foot principle, although with more 3d printing and less machining.
The basic idea is to print the entire lower leg in a single go laying on its side, so that delamination is unlikely. The foot bracket will be cast into a squash ball, then epoxied onto the lower leg.
One of the parts on the original quad A0’s leg that was prone to failure was the “knee stud”, a little cylinder that acted as the mating interface between the upper leg and the lower leg. It directly attaches to the upper leg, and has bearings that ride between it and the lower leg. The entire tension of the leg belt is born in shear by this part.
In the mk1 leg, this part was 3d printed with heat set inserts used to form the threaded holes. This mostly worked, although occasionally the stud could shear along the 3d printed lamination lines. Thus, for the mk2 leg, I’m making this part out of 6061.
The first op takes a 0.875 inch cylinder, and does all the work on one of the sides. That includes roughing it down to length, getting the outer diameter that the bearing rests on accurate, and drilling and threading the holes.
At that point, the part is turned over and bolted into a 3d printed fixture.
Then, all the tool paths are repeated on the other side, as well as the middle being cut away. I didn’t really worry about surface finish on the middle section, since it will never be seen. This of course would be much easier on a CNC lathe with live tooling, but hey, you use what you’ve got!
Since the mk2 moteus servo has slightly different dimensions and a different mounting pattern than my original, I needed up update the full rotation leg design to handle it. The basic concept is the same, except for some in-progress work on the foot design which I’ll write up later. The only significant changes were that because of the mk2 design, access to the power and data connectors is much easier.
Finally returning back to other pieces of my quad roadmap, I finished getting an updated power distribution board ready for the quad A0. This board is one I had made many months ago and mostly brought up, but then didn’t quite finish. The r1 was when I first discovered my unfortunate stm32g4 pinout problems that doomed 3 of my in flight boards. The pictures here are of r2, which suffered from yet more pinout problems, resulting in more than my usual number of blue wires. Fortunately, identifying those problems here let me fix them ahead of time for the fdcanusb and moteus r4 boards.
This version has a probably overkill XT90 input connector, 6x XT30 output connectors, a connector for a lighted toggle switch and an FD-CAN port. The CAN port will eventually allow me to implement a soft power off, although I haven’t done that yet.
When hooked up to a moteus dev kit, it does do the proper pre-charging thing:
As mentioned previously, I’m releasing moteus controller development kits to a few lucky beta testers. Building these wasn’t too hard, but was my first foray into low-volume production for someone who wasn’t myself. Here are a few pictures of the build:
A big thanks to all the beta testers! With the next revision of the controller, I’ll continue to have a development kit with roughly the same properties for those wishing to get started in an easy way.
If you have devkit envy, you can get a little fix watching this video showing how to set it up and use it.
To get ready for initial limited production of the fdcanusb I wanted to make some kind of enclosure so that you didn’t have to just grab the raw PCB and risk ESD failures. I also wanted to be able to expose the status LEDs without having to do a window or anything else with multiple materials.
So for now, I just used a translucent PETG print, with light pipes and a thin wall above each of the LEDs. The result isn’t too bad, you can clearly see the status LEDs and it feels plenty rugged for desk work.
One final piece of porting that needed to happen for the moteus controller r4.x series was the bootloader. The r3.x series has a bootloader, which allowed re-flashing the device over the normal data link, but that was largely specific to the RS485 and mjlib/multiplex framing format. Thus, while not particularly challenging, I needed to update it for the FD-CAN interface used on the r4.x board.
For now, on the assumption I will in the not too distant future deprecate the r3.x series, just duplicated the entire bootloader, replacing all the communication bits with FDCAN and stm32g4 appropriate pieces. As before, this bootloader is designed to only operate after the normal firmware has initialized the device, and also is required to be completely standalone. To make code size easier to manage, it makes no calls to any ST HAL library and manipulates everything it needs purely through the register definitions.
Thankfully, the ST HAL sources are BSD licensed, otherwise I’m not sure I could have gotten the FD-CAN and flash peripherals to work just given the reference manual. With it, copying out the necessary constants made for an easy solution.
Because my working environment is otherwise too idyllic and peaceful, I’ve been running the new moteus servo mk2 through its paces. All day long. 8 hours a day.
This is the same test I ran to verify the controller, only now I’ve done it several times longer to get a better feel for if there are any weak links. Somewhat surprisingly, the ball doesn’t drop all that often, only once an hour or two.