Some Long Needed Updates to the Big Scooter

The Big Scooter (version 2) has existed for a year and a half now, and I've finally gotten around to doing some long needed updates to it.  Most importantly, I originally did not build in a chain tensioning mechanism, because the chain length worked out pretty much perfectly.  Chains stretch, though, so the chain started falling off, especially when plowing through snow.  Since it's snow season again, it seemed prudent to fix this problem.

First quick fix, replacing the hand-truck bearings I never bothered upgrading with more legitimate bearings.  The original bearings had deteriorated so much there was about 10 degrees of slop in the back wheel.

Since the new bearings actually have precisely bored I.D.'s, I had to turn down my front axle a little bit to match:

I added an eccentric sprocket on the drive-side swingarm for tensioning the chain:

The sprocket gets clamped in this block, and rotated to apply the desired tension:

It's mounted to the scooter as high as possible, so there is little possibility of it scraping when driving over obstacles:

Finally, I added some grip tape to the deck.  Sadly, clear grip tape isn't particularly clear.  Next time around I'll probably go with plain black:

Now, I just need to whip up some studded tires or tire chains before the blizzard hits tomorrow.

Trying to Crack the EC Desk Safe

There's an old safe at the EC front desk that hasn't been opened in a while, and no one knows either the combination or what's in it.  A number of students have unsuccessfully tried manually cracking it, but a little label on the safe does say it has been tested to 20 hours of expert manipulation, or something like that, so manually cracking the combo is pretty difficult.  I actually don't know much about safe cracking.  I understand the mechanism behind this kind of lock, and some ways by which it can be exploited, but I have pretty much no experience actually trying to crack safes.  I do have experience building robots, however.

It shouldn't be too hard to build a simple robot to auto-dial safe combinations.  All you need is a servo to rotate the dial and some way of sensing when the correct combination has been entered.  And since robots are infinitely patient, it can just brute-force combinations until it finds the correct one.

How long will that take?  Well, the safe has 100 numbers per dial, and the combination is 3 numbers.  That means 100^3 or 1,000,000 possible combos, right?  Actually no.  First, locks have mechanical tolerance.  When entering a number into the dial, your number-entering precision needs to be something like ± 1 increment from the correct number.  Actual tolerance depends on the exact model of lock, going down to about ± .5.  I don't know exactly what model of lock is on the safe, but it appears to be made by Sargent and Greenleaf, and looking at their catalog of modern locks for reference, I settled on ±1.  So, that cuts the number of possible combinations by a factor of 8, bringing it down to 125,000.  Additionally, according to the manual, one should never set the third number to anything 95-20, because it can stop the lock from working correctly.  This brings the total number down to 92,500.  Much more reasonable.  Supposing it takes 6 seconds to enter a combination (I'll explain why it takes so long later), that's 6.4 days to try everything.  So it should average something like 3.2 days to open.  That is still a pretty long time, but as long as I'm not sitting there entering combinations, who cares?

On to the hardware.  Here's the basics of how it works:
The device will magnet on to the door of the safe.  A coupling with a spline matching that of the dial will mesh with the dial to connect it to a motor.  I'm using a giant stepper motor.  Now I want to be very clear, I hate stepper motors.  They're terrible.  Servos all the way.  However, I didn't have any motors with appropriate low-speed torque and backlash-free gear-down on hand, so I didn't have much choice but to use a stepper motor.  I grabbed the biggest one I could, which I scavenged out of some old lab equipment a while back.  The stepper is powered by a (also scavenged) stepper driver, which is controlled by an STM32 Nucleo F411RE.  I found about these things through Bayley, and they're great.  $10, lots of computing power, and compatible with the mbed compiler, which I am already very familiar with.  This is in turn connected to a netbook which logs attempted combinations and sends me an email every 1000 tries and when it thinks the lock has been opened.

Here's the motor, microcontroller, and stepper driver.  To start out, I used this Easy Power GSD200S, because some x-ray equipment MITERS crufted a couple months ago had a bunch of them.  This driver could only do half-stepping, so everything was really noisy.  When first testing out the machine, there was a noise complaint from someone living two floors above the desk.  I later swapped this stepper driver out for something a bit nicer.

The easiest thing to do with a stepper motor is just command it constant step rate for constant velocity motion.  When starting and changing directions, though, this demands nearly instant velocity change, which doesn't work that well for either the motor or the lock.  To make things smoother, I implemented some acceleration control which adjusts the delay between steps to approximate constant acceleration.

This isn't too difficult to do.  First define some starting velocity (because no one wants divide-by-zero errors): v_sart, in steps per second.  The pulse period, dt, required to move the motor at v_start is just 1/v_start.  Say the motor should accelerate at rate a, in steps/seconds^2.  The first time interval, dt_1, is equal to 1/v_start.  After accelerating at rate a for time dt_1, the motor's velocity should be v_start + a*dt_1.  So the next pulse duration, dt_2, should be 1/(v_start + a*dt_1).  Repeat this process, substituting in the previous step's velocity and period, and you can generate a set of pulse durations that approximate constant acceleration of the motor.  Mirror that set of pulse durations about its end, and you have a constant acceleration, constant deceleration trajectory between two points.  The smaller the steps are, the smaller you can make v_start, and the better the approximation is.

On to some hardware building.

Some metal plates for the structure where milled on the MITERS CNC mill:

T-nuts can be step clamps too

The front metal plate has four large neodymium magnets press-fit into it.

Two aluminum rods are press-fit into the front plate.  A set screw in the front can be tightened into the ring around the lock's dial, to prevent anything from rotating.  The spacing of the motor can be adjusted using the two clamps around the shafts on the motor plate.

A laser-cut delrin spline meshes with the dial:

The dial-spline is coupled to the motor with a flexible shaft coupling to compensate for lack of concentricity and wobble in the dial.

To sense when the correct combination has been entered, there is a one count per revolution encoder on the shaft, made from an optical limit sensor.  After entering the correct combination into one of these locks, you turn the dial clockwise until it locks up (around 95).  At this point the stepper will stall.  The sensor detects when the stall has occurred, so the microcontroller knows the lock is open.

Here it is installed and running for the first time:

(video credit to Danny Ben-David)

There are a couple points to note.

• It's very loud.  This is caused by the half stepping limitation of the stepper driver used, and lack of mechanical isolation between the motor and frame.  I fixed the latter by adding some squishy rubber between the motor and it's aluminum plate, and securing it with Structural Zip Ties rather than steel screws.  Stepping noise was reduced by switching to a fancier stepper driver with 32x microstepping.
• It's not very fast, especially on the first counter-clockwise rotation.  This particular lock gets extremely stiff on the fourth turn around the dial.  I had to slow down the stepper to stop it from skipping steps during that part of the rotation.  This could be solved with a higher voltage power supply.

Hopefully before the next report the safe will be open.  Current progress is around 2%

A Box for a Plane

I finally made it back to Atlanta this December, and while I was there I was given this beautiful little block plane.  It seemed appropriate to build a box for the plane, using the plane.

Here's the plane on top of the block of oak from which I made the box.  It's solid, but made from a few pieces glued together.  I think it's a section from a post on the staircase of our old house.

I started by sawing off a slice of the block to make a lid from.

I squared off all sides roughly with my larger block plane, after I spent a good long while sharpening it.

I finished the sides with the little plane.  No sanding needed.

I began chiseling out a recess for the plane using some small chisels and gouges.

I slowly carved deep enough to fully submerge the plane:

I chiseled a dovetail into the sides of the edge around the box, and beveled the lid to match:

I sawed a thin slice off the bottom of the box to finish the lid:

The two pieces of the lid were glued together and planed square with the rest of the box.  Here it is after a couple coats of tung oil:

The finished cavity of the plane.  I carved it as close to the actual shape of the plane as I reasonably could: