I’ve had a confusing mismash of development tools for the moteus servos for a while now.  My original development tool was in python, which worked just fine.  Coroutines allowed me to express complex asynchronous logic succinctly, the program itself was rather simple, and I could easily integrate it with matplotlib for plotting.  However, when looking to run this on the raspberry pi, I needed a newer python version than came with raspbian, which turned out to be a royal pain to get installed in a repeatable manner.  Thus I rewrote a portion of the moteus_tool in C++ and just used my normal cross-compiling toolchain to generate the binaries.  What I didn’t do was port the calibration logic, as the state machine required with standard boost::asio would have bloated the logic size by 5x, and I didn’t really need to calibrate servos from the raspberry pi ever.

A previous simulator I had built for Super Mega Microbot was based on the “DART” robotics toolkit.  It is a C++ library with python bindings that includes kinematics, dynamics, and graphical rendering capabilities under a BSD license.  I wanted to use some of its dynamics capabilities for future gait work on the quad A0, and eventually re-incorporate its simulation capabilities, so integrated a subset of it into mjbots/bazel_deps.

• github: Incorporate a subset of dart and its dependencies

While updating the mjmech code-base to interoperate with the moteus servos, I simultaneously was updating it to use C++17.  C++ rarely removes or deprecates features, but one of those which actually was removed in C++17, after being deprecated in C++11, was auto_ptr.  unique_ptr is strictly superior in all regards, and so there is no real reason not to switch.

However, mjmech depends upon a large amount of third party software.  Amazingly, only one package actually was broken by this removal of auto_ptr, log4cpp.  It actually saw some updates for C++17 compliance back in 2017, but otherwise hasn’t been updated since then.  I went ahead and forked it, and got it compiling with clang in C++17 mode at least:

When I initially created rpi_bazel, I set it up to use a host provided clang.  I decided to update that so that the rpi_bazel rules themselves download a binary version of an arbitrary clang.  This lets you decouple the version of clang from what is available in any given Linux distribution and improves the reproducibility of builds, since you are no longer dependent on whatever PPA you used to grab clang from.