I’ve muddled along for a long time soldering with a little Weller WES50. I’ve done a lot of work with it, but given how many SMD boards I’m doing with big ground planes and tiny components, I needed something a bit more capable. Enter the Pace ADS200 from tequipment:
Made in the USA, with 120W of power and a wide range of tip selection it has been an incredible upgrade. All those soldering jobs which were painful before are so much easier, and I don’t even have all the tips I wanted for different jobs yet. I also have the MiniTweez, but don’t yet have the tips that will let me show that off. I’ll try to post some soldering videos in the not too distant future.
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:
Step 1: ConfStep 2: ServerStep 3: Launch in New TabStep 4: ConfigureStep 5: Pick AxisStep 6: Change value, select Save, then SytemStep 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 testingChecking 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.
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.
