When I first acquired my Pocket NC v2-50, I was planning on using it for rapid prototyping of small aluminum parts. I figured with 5 axes, I could do many things with a single setup just clamping from the bottom. However, I was initially thwarted in that plan and had to resort to more creative workholding solutions due to two problems.
First was the vice that came with the Pocket NC. It is serviceable, but provides very little clamping force if you want to hold something that is tall and skinny. For now, while it isn’t ideal, I’m making good progress with the wcubed vise.
Second was the range of Z travel. As shipped by Pocket NC, in order to reach the center of rotation, tools have to stick out something like 35mm. If you want to go beyond, that adds even more. This was a problem, as there aren’t that many tools that can achieve a reasonable material removal rate while sticking out that far, if they can do so at all. This, I’ve finally resolved with this Pocket NC “Q-Tip”:
With that modification, I got an extra ~15mm of travel, which means that I can reach the center of rotation with only 18mm of stickout which is completely reasonable for this class of tools.
Now I can finally “window” machine parts out of a few maximally sized generic blocks of stock with only a single setup. I’ve got 3.5″x3.5″ stock in a variety of thicknesses, which lets me do just about anything, if slowly, without having to worry about workholding.
To date, all of the development tools for the moteus brushless controller have been available exclusively for Linux based operating systems. I’ve been doing some behind the scenes work, and have gotten to the point where moteus_tool now runs natively on windows and can communicate with moteus controllers using a fdcanusb.
Check out the Windows installer for the latest release:
To make this work, I started from the excellent grailbio/bazel-toolchain, which provides LLVM toolchains for Linux based systems based on the official LLVM pre-compiled binaries. I forked that into mjbots/bazel-toolchain and added Windows support. It isn’t perfect, because the LLVM project only distributes Windows binaries in installer form, and it isn’t possible to extract binaries from them without specialized tooling. So, this version relies on a manually re-packed compressed archive of all the executables.
I also added support for building the libc++ standard library, and using that instead of the MSVC standard library. This let me get c++20 coroutines working with clang on Windows.
All put together, the porting was pretty painless after having a toolchain in place. Just a few #if’s here and there, and I had to write a custom Windows specific console stream, as stdio and stderr do not support asynchronous completion ports on Windows.
Meet the newest revision of the moteus controller!
Yes, it does look mostly the same as the r4.3 that has been getting a lot of use lately. This revision exists mostly to improve manufacturability, but I snuck in a minor design improvement while at it. Now, the maximum voltage input is rated up to 44V from the 34V of the r4.3! (Note though, that the pi3hat and power_dist still are limited to 34V). Otherwise the new controller is fully electrically, mechanically, and software compatible with the r4.3.
In two previous posts (part 1, part 2) I discussed some changes I made to the gait sequencing on the quad A1. Things are working relatively well now, sufficient that I was able to take this compilation video in one sitting without any gait or mechanical failures! I actually took a lot of the outdoor shots from this video in the same session, so things are definitely getting more robust.
This summer I had to send my Pocket NC in for some service, when it came back, I immediately noticed that the X axis homing was very far off, something like 0.01 inches, as I was boring a hole in one side of a part, spinning it around the B axis, then boring a countersink in the other side. The two were very clearly not concentric. I suspect the homing mechanism shifted in transport or something, because the error was very consistent.
Pocket NC’s support was great as usual and I quickly received a screencast showing the location of the homing setting:
To calibrate the X axis, I just used the hole that was bored all the way through, and manually used the MDI to spin the B axes around and jog the end mill through the center of the hole. Then I used my calipers to measure the offset between the widest part of the mill and each side of the hole. Two iterations of that had the X error back to under 0.001″.
Fast forward a few months and I am running a part where the Y axis zero position matters. Sure enough, it is off too. Not as much, maybe only 0.004″ or so, but enough to make the part not work out. I tried a different technique this time, engraving an X axis line with a chamfer mill in two parts. One part with the B axis at 0, and the other half with it at 180. Any Y offset will manifest as a “jog” in the line.
I’m not sure if this was any more or less accurate than the boring method, but it was faster and seems to have also gotten me back down to under 0.001 inch of error in the Y axis.
The first clip shows it walking over some tree roots. In this particular instance, it just uses a high stepping gait, which allows the feet to get on top of the root. The gait sequencing doesn’t handle walking over the taller part of the root very well yet… the robot can get “high centered” on two legs, with the other two flailing in the air.
In the second clip the robot runs across some loose gravel and leaves. Here each foot fall skids around a fair amount and kicks up loose debris, but otherwise wasn’t too challenging.
For the third clip, the quad A1 walks through some grass and over some pavers, which are around 1-3″ raised above the baseline grass level. Here raised steps allow the robot to move at nearly the same speed over the pavers as it can move over the grassy terrain.
In the final clip, it walks over some loose bricks. With each footfall, the gait sequencing is looking for when contact is made with the ground. That allows the robot to stop pushing once contact is made. The current formulation does attempt to get the legs back to their “average” Z position at the end of each cycle, which is sufficient for this type of terrain, although a longer-term outlook would allow it to tackle even tougher terrain.
Previously, rules_mbed used the “crosstool_top” bazel mechanism for toolchain configuration. This allowed a single package to contribute a set of C++ toolchains which would be selected based on CPU and compiler. One of the downsides from the rules_mbed perspective, is that it made it difficult to make a build that included both mbed targets and host targets (or anything else non-mbed). rules_mbed worked around this by including a functioning clang host toolchain within it.
With the new toolchain resolution support, at the command line you specify to bazel what “platform” you want to be the final target. The updated rules_mbed specifies a “platform” for each of the STM32 processors that are supported. So for instance you could use:
It then uses that platform to find a toolchain with a compatible operating system and CPU, which for rules_mbed is the arm-gcc compiler for the correct chip.
Because of this, the command lines necessary to compile the moteus firmware and host side tools have changed. Rather than expose the raw bazel options, it now just uses a bazel config to abstract away whatever mechanisms are required. So, the two necessary new command lines are:
tools/bazel test --config=target //:target # build firmware tools/bazel test --config=host //:host # build host tools
Soon, we’ll use this capability to add some useful new features to the moteus tools, such as support for non-linux operating systems.
Now that the quad A1 has been running faster, it has started “running” through its ad-hoc cable management too. After replacing a harness for the nth time, I decided to actually design something rather than just keep re-building over and over again.
My current best effort uses semi-flexible nylon split conduit, captured in 3d printed forms at each joint. Inside that conduit is basically the same harness I had before, with the cables selected to be more robust to repetitive motion. The nylon conduit is only semi-flexible, so it enforces a relatively large minimum bending radius on the wires within, while still sticking to the black quad A1 color motif.
To verify this would be at least a minimal step up, I ran some endurance testing with around 100,000 cycles of the leg moving. With no degradation of the cables in that window, I’m calling this good enough for this iteration of improvement.