All posts by Josh Pieper

Thread milling on the Pocket NC v2-50

2019-11-13robotscnc, pocketnc, threadmillJosh Pieper

UPDATE 2019-11-27: The feeds and speeds have been tweaked based on further experimentation.

To date I’ve managed to not do any threading on the parts I’ve made on my Pocket NC v2-50. However, I’m about to do a number that require both M3 and M2.5 threads, so I figured it was time to figure out how to do it.

Online tutorials are kinda all over the place in both how you handle things in the model, and how you program the CAM. Some assume you model threads as a hole of the major diameter, some as a hole of the minor diameter, although none that I could find used the new Fusion 360 “threaded” hole type, which is what I wanted to use. That said, using the “threaded” hole type appears to be treated basically as a minor diameter hole with a minor caveat. You would expect that since Fusion knows the minor and major diameter, the “pitch diameter offset” would be relative to a zero tolerance thread, but in fact it appears to be relative to the minor diameter as if you had modeled a minor diameter hole. Oh well, I just experimented with increasing pitch diameters until I had threads that fit relatively tight for the two that I cared about, which fortunately can be both made using identical tools, although the M2.5 hole is only on the edge.

	M3	M2.5
Hole
Tool	Datron 2mm single 5mm flute 0068620G	“”
Stickout	14mm	“”
Feedrate	400 mm/min	“”
RPM	42000	“”
Ramp Angle	2 deg	“”
Stock to leave	-0.02mm	“”
Top height	+1.0mm	“”
Bottom height	-0.5mm	“”

Chamfer
Tool	Shars 1/8″ 90 chamfer 416-3509	“”
Stickout	18mm	“”
RPM	8500	“”
Chamfer width	0.05mm	“”
Chamfer tip offset	0.5mm	“”

Thread
Tool	Lakeshore Carbide 3-SPTRMLB	“”
Stickout	16mm	“”
Feedrate	300 mm/min	“”
RPM	10000	“”
Pitch	0.5mm	0.45mm
Pitch diameter offset	0.568mm	0.480mm
Stepovers	6	4
Stepover	0.05mm	“”
Repeat Passes	YES	“”
Lead To Center	YES	“”
Top height	+1.0mm	“”

Interestingly, Fusion’s simulation reports that the M2.5 holes have a collision when inserting the threadmill, not on the first couple of insertions, but on the 4th and subsequent ones. This does appear to occur in real life too, as you can hear slight interference when the tool is inserted. I don’t fully understand this, as I would expect Fusion’s CAM to just stick the tool down the middle the same way each time.

Results

Here’s a video machining a few M3 and a few M2.5 threads in the same operation, then testing them out.

Ramping up for moteus servo mk2

2019-11-11robotsbuild, moteus, servo, servomk2Josh Pieper

Some time ago I put in orders for all the long lead time items on a second version of the moteus servo. This is primarily aimed at improving the manufacturability and reliability, along with some minor performance improvements. I’ve now got at least samples of all the long lead time parts in house!

A sample batch of custom rotors and stators

Coming up soon I’ll post a more detailed design update on the servo.

Successful pronking!

2019-11-07robotsdynamics, jump, pronk, quada0Josh Pieper

While not perfect, now that I have flux braking in place, I have now succesfully pronked around for a while without faulting! There are a number of outstanding problems that still need to be addressed:

Sometimes the landing phase is erroneously cut short
There is occasionally a grinding like noise that sounds like some controller is unstable
I think the lateral movement is not working correctly
The gait needs to be smarter about moving the legs past the center point when in mid-flight, and changing the gait period to achieve different speeds
And probably a bunch of other problems I haven’t even identified yet

That said, it is still fun to watch it romp around!

quad A0 chassis v2 – final assembly

2019-11-06robots3dprint, build, chassis, quada0Josh Pieper

In the last post in this series, I conducted a fit test on the new chassis. After my ignominious belly-flop, I now had a more urgent need to complete the switch.

The chassis cracked in the corner, completely separating. Doing anything more with this chassis was likely to result in many more things breaking very quickly.

Build process

So, here are the photos as I put everything together.

Next up is continuing to try and get pronking working!

Flux braking with the moteus controller

2019-11-04robotsmoteus, quada0Josh Pieper

When I was trying my first pronking, I kept having over-voltage issues when the servos were trying to dump power back onto the DC bus, no matter how high I set the voltage limit. During that test, I was running with a nearly full battery, so my working theory is that the battery protection circuit was disconnecting the battery either because of too high a charging current, or too high a system voltage. When the battery was disconnected, and the servos were still putting power onto the bus, that resulted in the voltage spiking arbitrarily high, followed by a total loss of power when they all faulted and then nothing was powering the bus at all.

Clearly I needed somewhere to dump the power during those transient events. One option would be to build a brake chopper, sticking a power resistor somewhere and using that to burn off the extra. But, why bother with that when I already have 12 big power resistors attached to the robot! Errr… motors that is.

Anyways, my solution for now is to create a “virtual resistor” in the moteus firmware i.e. “flux braking” that just dumps current into the D-axis of each motor proportional to the magnitude of the DC bus voltage above some configurable threshold. That results in each servo working independently to keep the overall system voltage from getting too high in a hopefully stable manner.

I ran the programmable power supply through a voltage sweep while commanding zero velocity on all 12 joints to verify this was working as expected. It did get pretty audibly noisy at the higher voltages, probably because of some feedback with the voltage sensing so I added a little filtering after which the noise was manageable.

Belly Flop!

2019-11-01robotscrunch, dynamics, jump, pronk, quada0Josh Pieper

Now that I can do controlled jumps, and have a UI which allows me to use the joystick, I finally started actually working towards pronking gaits. Too bad for you, this post doesn’t have any details, merely a video snapshot of my learning and debugging process…

HTML + websocket joystick control

2019-10-30robotsasio, beast, diagnostics, html, joystick, quada0, websocketJosh Pieper

Now that I had a controlled jump with the quad A0, I wanted to chain those jumps together into a pronking gait. The first part of that was creating a mechanism by which I could actually command varying motion commands. For the previous full rate experiments, all I had built was a CLI that allowed you to type commands. That sufficed for initiating a single jump, but not really for moving around in space with a dynamic gait. Something with a joystick would be necessary.

For Super Mega Microbot, we had a Mech Warfare dedicated client application which, for various reasons is something I want to get away from and its control protocol isn’t even that suited to the things that the quad A0 is capable of anyways. For the quad A0 I want to eventually have 2 command and control systems: a high bandwidth one that uses wifi, and a low bandwidth robust one that uses a spread spectrum RC style transmitter. For now, I figured I would start by making a first minimum viable product of the high bandwidth diagnostics tool, since it would be more useful initially.

Architecture

The intended system roughly looks like this:

quad A0 diagnostics architecture.png

The client in this case is a regular web browser. It connects to the embedded web server which is running in the robot control process and fetches some static assets, including HTML, CSS, and Javascript. Then, the diagnostics client is a single page javascript application which makes a separate websocket connection to the embedded web server for real-time control and status data.

Implementation

Initially, I spent a half day making a standalone proof of concept server and client. The server was based on boost::beast / boost::asio and the client was vanilla JS using the gamepad API. All it did was render the state of the joystick into a text string at 10Hz, stick that into an HTML element and send it over the websocket connection. Anything it received over the websocket connection it stuffed into a different HTML element. The server just sent an incrementing number over. Once this was working mostly well enough, I felt confident enough to move on and integrate it into the actual robot control application.

For that, I implemented a more generic “WebServer” class which just serves the static files and accepts websocket connections at configurable endpoints. Then a separate “WebControl” class uses WebServer to report the quadruped status and send commands. For now, I just exposed the raw C++ status and command structures over the websocket interface as JSON, so the control class doesn’t have a whole lot of work to do.

On the client side, I spent zero effort on presentation, and just dumped raw JSON into HTML elements for now. There is minimally enough logic to command the robot through the states that are implemented now based on joystick commands. The result is just about the ugliest web application you can imagine, but it gives me a place to start from both to make it more functional, look nicer, and more importantly lets me once again use the joystick to command variable gaits.

shop.mjbots.com

2019-10-29robotsbearings, gearbox, gears, mjbots, moteus, shopJosh Pieper

In my quest to create a more dynamic quadruped, I’ve started accumulating a lot of parts from bulk buys that could be reasonably useful to other hobbyists and experimenters. To maybe make life easier for everyone, I’ve started up what may be the worlds ugliest online shop where you can buy some of these components. For now, I have some bearings and custom gears that are useful when building servos for dynamic robots.

Check it out! https://shop.mjbots.com

Unfortunately US shipping only for now, email me or DM on discord to arrange something internationally.

Some samples of what I have online now:

M0.5 100 Tooth Steel Ring Gear

55mm +0/-0.02 mm outer diameter and 5mm width, only $17 each.

M0.5 20 Tooth Sun Gear

5mm tooth width, 4mm ID bore, 8mm OD hub, only $6

6708-2RS ABEC-1 Bearing 40x50x6mm

50mm OD, 40mm ID, 6mm width, only $8

quad A0 chassis v2 – construction

2019-10-28robots3dprint, chassis, quada0Josh Pieper

After CADing up the second revision of the chassis, I set to work with the 3d printer and printed up all the pieces.

There were a few minor post-modifications I had to make, which were all much faster than printing the pieces again. All the holes for M3 bolts were slightly undersized, so I drilled them out. The battery holder had a channel to let the power wires out, which inexplicably terminated before reaching the edge of the holder. I also had to install all the heat set inserts.

All put together, with a snazzy new sticker

I did attempt something new, which was to post-process the printing by smoothing out a corner by sanding. An experiment it was. I spent about 2 hours on it, of which 45 minutes was on the coarsest paper I had, about 80 grit. I eventually gave up on that coarsest grit and started moving on, so there are still a few blemishes in the final result.

Needless to say, until I get really bored, I probably won’t spend the full day required to do the other 3 corners of the chassis using this method.

There are a few other minor changes I’ll make before installing legs, which will be the next step!

quad A0 chassis v2 – design

2019-10-25robots3dprint, chassis, quada0, smmbJosh Pieper

As described in my roadmap, the chassis for the quad A0 was on the verge of failing, or causing the shoulder motors themselves to fail, after only a few hours of walking around. Also, it was nigh impossible to assemble, disassemble, or change anything about it. Thus, the chassis v2!

More than one piece

The old chassis was a single monolithic print that took about 35 hours of print time. Because of its monolithic nature, there were lots of interference problems during assembly. For instance, the shoulder motors could only have 4 of the 6 possible bolts installed, and 2 more of the bolts extended beyond the chassis entirely. I decided to break it up into multiple pieces, which uses a lot more inserts and bolts, but should allow for a feasible order of assembly and manageable repair.

Now there are separate front and back plates, to which the shoulders can be attached in isolation. Then the top plate can attach to that, followed by the side plates, the battery holder, and eventually the bottom plates.

Enclosing the electronics

V1 had the primary computer sitting on top of the chassis. That was a legacy from the first Mech Warfare configuration, where the primary computer sat in the turret. I’ve decided that for Mech Warfare, I’ll just put a second independent computer in the turret, which frees the robot computer to be placed inside the chassis where it is much less likely to get mangled.

The power distribution board is now mounted to the other side opposite the computer, instead of on the now top-plate.

Power switch and strap

I’ve left room for a recessed top mounted power switch on the top plate. This should remove the need to unplug and re-plug the battery any time that power needs to be cycled. That hole is marked in red below.

Also, while I’m at it, I left holes in the top through which a carrying strap can be threaded (marked in blue above). The old chassis had some M3 inserts that I screwed eye bolts in and then threaded some cord through. That didn’t work terribly well and was unsightly.

Battery

As mentioned in the roadmap, I was going to try and replace the battery with something with a smaller form factor. I looked through a number of batteries, and got a Milwaukee M18 as the best of the options, but ultimately decided that the Ryobi style was the best compromise for now despite the wasted space. All the lower profile ones required insertion sliding in from the side, which would have required that the chassis be much longer than it was already.

Thus, I still have the 3D printed Ryobi battery holder, only now it attaches to the top plate with just some bolts instead of a complicated dovetail arrangement I had previously.

Stiffeners

Since this is being printed in multiple pieces, I wanted a separate piece to increase the longitudinal stiffness. That is now just two plates which bolt to the front and back plate, and to the battery holder.

Next steps

Next up is printing and assembling this chassis!

A Modicum of Fun

Robots, pictures, and stuff…