Now that I have a mammal geometry leg moving, I wanted to get a better feel for what the overall performance would be in various gaits. I had already derived position based inverse kinematics for Super Mega Microbot, but had no such derivation for force. Here’s my jupyter notebook with derivations for both position and force (in 2D), along with average power consumption for various forms of straight walking gait with my current draft motor selections.
I got the mammal geometry leg up on the jump stand, then took it down, switched the femur motor to a BE8108, then took it down, and added a 3rd degree of freedom. There is still a lot of work to do to get it performing well, and it is pretty clear it won’t have the same vertical jump of the 4 bar linkage, but I think it still might be an overall superior option.
Before committing to the side-by-side 4-bar linkage leg for SMMB’s new actuators, I wanted to give a try with a more traditional mammal geometry. That was my preference to begin with, but my initial motor evaluation didn’t find any motors which had sufficient torque without a gearbox, and adding a gearbox in a simple way changed the dimensions enough that mammal geometries weren’t feasible. I spent some time looking for new options, and I found at least one which was promising, the XOAR Titan 6008.
While testing SMMBs new actuator under load, I kept getting faults from overvoltage that I had not anticipated. The firmware only samples voltage once per control cycle, and while that plot did look very interesting, it probably wasn’t representative. I wired up the scope to be able to sample the voltage and FET control signals during operation and sure enough, the voltage ripple was way higher than I had predicted based on the original design. Even at only 30A phase current, the voltage ripple on the main power bus was 4.2V. Note that this was with a nominal operating voltage of only 13V! I had been trying to operate at 40A, for which it must have only been worse.
I have been continuing to iterate on the control and mechanical aspects of the improved actuators for SMMB. While working on an alternate board mounting strategy, I ended up with a magnet that was much much further from the absolute encoder than before. This resulted in significant errors in the estimated motor phase at various points in the revolution of the absolute encoder. In the spirit of copying every single thing Ben Katz did in his project, I implemented a piecewise linear encoder calibration technique.
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.
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.
One of my intermediate goals for building new actuators for SMMB is to get them robust enough to jump continuously for some duration of time. Progress is slow, as things break, new parts are ordered, repairs are made, and jumping resumes. The most recent failure is at least interesting enough to me that it is worth writing up.
To recap, I’m building a brushless servo based around a Turnigy Elite 3508 brushless motor and a custom 5x planetary gearbox. The 3508 is intended for quadcopter applications, so to install a spur gear I first extracted the original shaft, then pressed in a new shaft with two flats on it. One flat for the set screw attaching the rotor to the shaft (which had a press fit), and a second for the set screw attaching the spur gear to the output of the shaft.
After OpenCV, the other major dependency the mjmech software has, which is necessary to complete the raspberry pi 3b+ bazel build setup, was gstreamer. Unlike the previous dependencies, this one is a doozy – gstreamer has an enormous transitive dependency set. Additionally, we needed to use its ffmpeg wrappers, which brings in more dependencies.
In this post, I’ll just try to map out the dependencies that we ended up actually needing, so that they can be tackled one by one.
The next level of difficulty in bazel-ifying packages for mjmech was opencv.
First, for the impatient, Apache 2.0 licensed sources are available on github: https://github.com/mjbots/bazel_deps/tree/master/tools/workspace/opencv
OpenCV’s native build system consists of nearly 200 cmake files with over 20,000 total lines of code, plus assorted helper scripts and prototype files which are substituted into. Fortunately, I didn’t need to support the full complexity of the opencv build system. Things I didn’t bother to touch:
After the initial leg jumping with the prototype brushless actuator for SMMB, I spent some time actually tuning the control loops and making the firmware not incredibly convoluted to get started. I also acquired a high speed camera for analysis.
So, here is a brief update of the final jump before I seem to have toasted one of my DRV8323 motor drivers. It jumped for about 400ms of hang time, running at about half of the maximum current the system should be capable of pulling.
