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.

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:

• Building mjmech software with bazel
• Configuring bazel to cross compile for the rpi3
• Building mjmech dependencies with bazel
• First bazel-ified packages

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:

• gstreamer - We use gstreamer to interface with the webcam, format RTSP streams for FPV on the control station, and to render the control station and heads up display.  Granted, not all of gstreamer is used, but we do depend on features that require ffmpeg and X11.
• opencv - The use of opencv had been minimal to non-existant previously, as we hadn’t actually done any computer vision on the robot itself.  However, one of the big motivations for switching to the raspberry pi in the first place was to at least to be able to do active target tracking onboard.

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.

Understanding the problem

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.