Category Archives: robots

Pocket NC windowed machining

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.

That’s what it started with

And some video showing the cutting:

Native moteus tools for Windows

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.

mjbots November 2020 Update

Here’s the approximately annual giant video update:

If you’re interested in any of the topics in more detail, I’ve collected links to individual posts for each of the referenced items below.

Thanks for all your support in the last year!

Moteus

Announcement of moteus r4.3: Production moteus controllers are here!

Automated programming and test setup: Programming and testing moteus controllers

Dynamometer: Measuring torque ripple, Initial dynamometer assembly

Continuous rotation: Unlimited rotations for moteus

The virtual wall control mode: New “stay within” control mode for moteus

Handling magnetic saturation: Dealing with stator magnetic saturation

moteus r4.5

qdd100

Discussion of the overall design, and details on individual sub-components:

And the pre-production mk2 servos: Pre-production mk2 servos

Accessories

fdcanusb: Introduction and bringing it up

power_dist: The failed r2, the closer to working r3, and the final r3.1

pi3hat: Initial announcement, bringing it up, and measuring its performance

Demonstrations

Ground truth torque testing: Ground truth torque testing for the qdd100

Skyentific’s telepresence clone: qdd100 telepresence demo

kp and kd tuning: Spring and damping constants

quad A1 – Hardware

Lower leg updates:

Chassis: The first introduction, and some minor tweaks

Cable conduit changes: New leg cable management

quad A1 – Software

Cartesian coordinate control: Cartesian leg PD controller

Pronking: Successful pronking!

tplot2 and its sub-pieces:

Simulation: Resurrected quadruped simulator

nrf24l01 transceiver and its sub-components

Smooth leg motion: Improved swing trajectory

Balancing

All four feet off the ground: Higher speed gait formulation, and Stable gait sequencing

Improved stand up sequence: quad A1 stand-up sequence part N

Speed records:

moteus r4.5

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.

It is now the default in the mjbots store, only $5 more than the old version at $84.

And, by popular demand, it still has a devkit!

Another quad A1 speed record – 2.5 m/s

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.

Recalibrating the Pocket NC’s X/Y home position

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:

Step 1: Conf
Step 2: Server
Step 3: Launch in New Tab
Step 4: Configure
Step 5: Pick Axis
Step 6: Change value, select Save, then Sytem
Step 7: Restart LinuxCNC and Rockhopper

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.

Several iterations of testing
Checking it out under the microscope

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.

Walking in semi-rugged terrain

While testing the improved gait sequencing for the quad A1 I got some footage of it traversing a few different types of outdoor semi-rugged terrain.

Tree roots

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.

Gravel

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.

Raised pavers

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.

Loose bricks

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.

New compilation commands for moteus

To stay on top of bazel development, and to prepare for some future improvements, I’ve gone ahead and upgraded the moteus firmware build system, rules_mbed to use the new bazel “platforms” toolchain resolution mechanism.

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:

bazel build --platforms=@rules_mbed//:stm32g4 //:target

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.

New leg cable management

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.