In my first foray into 80/20, I built a slightly more robust jumping fixture for the SMMB leg jumping test:
Overall it is much more rigid than the old one, and looks a little nicer. To top it off, I laid down a neoprene sheet for surface protection and friction enhancement, which is a step up from the old cardboard surface both in aesthetics and function.
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.
Enter an inexpensive Chinese thermal imager, which you can find for under $300 from time to time. A non-affiliate Amazon link: https://www.amazon.com/gp/product/B07BDJZ845
It has a resolution 220x160, 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.
This is part N in a series describing how I created the bazel infrastructure to build all the third party packages for mjmech. Previously we have:
We left off with the first, very simple packages configured to build with bazel. In this installment we will tackle those that require at least minimal configuration, i.e. those that have some files which are normally generated as part of the build process.
I continue to make progress on the improved actuators for SMMB. To briefly recap, these are based on a home-built brushless servo consisting of off the shelf gears, bearings, 3d printed assemblies, and a custom control board.
Moving on from closed loop vector (FOC) control, I’ve now built up a second motor, set both of them communicating over the same RS485 bus, and wired up a minimal makeshift jumping fixture. The leg didn’t jump as well as I had expected: I was only able to achieve about 300ms of air time and there are a lot of other minor problems/deficiencies as well. But on the other hand, I don’t appear to have permanently broken anything yet, so improvement will hopefully be mostly continuous!
I’ve reached a minor milestone in developing improved actuators for Super Mega Microbot. Previously I demonstrated basic closed loop control using a VESC. Now I have a custom control board running closed loop vector-based current and position control on a single brushless servo! I’ll hopefully write up pieces in more depth later, but this post can serve as a proof of existence.
First, boards as received from MacroFab:
Mounted onto the planetary gearbox:
When working on the firmware for Super Mega Microbot’s improved actuators, I decided to try using mbed-os from ARM for the STM32 libraries instead of the HAL libraries. I always found that the HAL libraries had a terrible API, and yet they still required that any non-trivial usage of the hardware devolve into register twiddling to be effective. mbed presents a pretty nice C++ API for the features they do support, which is only a little less capable than HAL, but still makes it trivial to drop down to register twiddling when necessary (and includes all of the HAL by reference).
In “Building mjmech dependencies with bazel”, I described my rationale as it were for attempting to build all of the mjmech dependencies within bazel for cross compilation onto the raspberry pi. mjmech has two big dependencies which were going to cause most of the transitive fallout:
And then there are a few other direct dependencies that are “easy”, if nothing else because they have such few transitive dependencies.
The first version of the planetary gearbox as 3d printed from Shapeways required a fair amount of post-machining to get all the pieces to fit together. I wanted to get to a point where I could just order some parts and have a reasonable expectation of them mostly working out of the box. To make that happen, I’d need to get a better understanding of where the tolerances were coming from.
Shapeways provides a fair amount of documentation on the processes and accuracy you can expect generally. Most of this is detailed in “Design rules and detail resolution for SLS 3D printing”, however the results there have some limitations. Primarily, they are only applicable to the specific geometries tested. Shrinkage is qualified as +- 0.15% of the largest dimension, and is likely influenced by the exact printed geometry. Secondarily, in the documented tests, the designers had full control over the part alignment in the print. The standard shapeways platform does not allow you to orient parts, you are at the whim of their technicians where the Z axis will end up.
Previously, I set up bazel to be able to cross compile for the raspberry pi using an extracted sysroot. That sysroot was very minimal, basically just glibc and the kernel headers. The software used for SMMB has many dependencies beyond that though, including some heavyweight ones such as gstreamer and I needed some solution for building against them.
There were two basic options:
The former would certainly be quicker in the short term, at the expense of needing to check in or otherwise version a very large sysroot. It would also be annoying to update, as I would need to keep around a physical raspberry pi and continually reset it to zero in order to generate suitably pristine sysroots.
In the previous post, I described the motivation for switching the mjmech build system to bazel. For that to be useful with Super Mega Microbot, I first had to get a toolchain configured for bazel such that it could produce binaries that would run on the raspberry pi.
All the work in this post is publicly available on github: https://github.com/mjbots/rpi_bazel
First, I needed to pick the compiler I would be using and how to get the target system libraries available for cross compilation. In the past I’ve always done the gcc/binutils/gnu everything cross toolchain dance, however here I thought I would try something a bit more reproducible and see if I could make clang work. Amazingly, a single clang binary supports all possible target types! clang-6, which can be had through a PPA on Ubuntu 16.04 and natively on Ubuntu 18.04 supports it out of the box.
