Press "Enter" to skip to content

Category: Science and Technology

A Lesson in Rigidity

After getting some metal stock this week, I was anxiously waiting for the weekend so I could start machining some prototypes for the AUV’s universal ring bulkheads.

Now, I need to throw out a disclaimer — I’m not an expert machinist by any stretch of the imagination. In fact, quite the opposite and I’m learning as I go, which is what this post is all about.

Having read through different things on feeds and speeds, I set up some programs with what I thought were somewhat aggressive cuts (for the Sherline) that I hoped the machine could handle — 1mm depth with a 3/8″ end mill into 6061 aluminum, with a feed of about 260 mm/minute. I’d read complaints about the rigidity of the 2000 series mill, but figured I’d try anyways.

The intent was to mill out the center of a 6″ diameter piece of Aluminum, so I could use the 3.1″ Sherline chuck to clamp from the inside onto the lathe for all the turning operations I’d need to do. I was hoping to salvage the inside chunk, since the stock wasn’t cheap. I planned on accomplishing this by milling in half way from one side, then flipping the part and milling in from the other side.

Now, the Sherline motor handled the first cuts like a champ. The 2000 series vertical column? Not so much. Unfortunately, as the machine went through the cuts, it put enough stress on the vertical column causing it to pivot along the vertical axis and throwing it off center. You can see the steps caused by this in the picture below, due to the column gradually pivoting at each cut, throwing off the alignment more and more. Luckily this was a roughing cut, so the the stock wasn’t lost.

Stepped profile caused by the wandering alignment of the mill's vertical column
Stepped profile caused by the wandering alignment of the mill’s vertical column

Eventually, I tightened the column well enough that it finished the last cuts without too much added deflection. Figuring I could tighten up the mill just a little bit more before flipping the part and trying the other side, I put the wrench on again, applied some torque and snapped the bolt clean off, leaving me with a Z-axis no longer attached to my mill, and the mill out of commission!

Not to be deterred, I figured I would try and see how well the the part fit in the lathe’s chuck using the pocket that was milled in one side. Not too bad, I must say:

6" diameter part on a 3,1" diameter chuck
6″ diameter part on a 3,1″ diameter chuck

I then screwed the chuck inot the lathe. I had to use two riser blocks to get clearance on the large part, causing some inappropriate cutter geometry. I needed that much offset to get the part below 6″ diameter, after which the intent is to only use a single riser block, and some special tool holders I’m planning to make in order to hold tools perpendicular to the part.

Turning large diameter parts
Turning large diameter parts

Turning the large diameter part was easier than I’d thought I used 0.2mm depth of cut and a 60 mm/min feed rate, which the machine handled well. The part stayed solidly affixed to the chuck, even when I accidentally crashed the tool into the part.

Now that I’ve gotten the stock cut such that I can mount it on the lathe, and turn it freely on the lathe, hopefully soon I’ll be able to start working it to the final shape. Unfortunately, I ran out of time to machine today and had to start cleaning up at this point.

Next steps, I’ll have to fix the mill. From what I’ve read online, the rigid column Sherlines fare much, much better than the fancy articulating column mills, and luckily the part to do the conversion is fairly inexpensive. Although perhaps the Sherline isn’t the right tool for machining large parts en-masse, for the quantities of parts I need and considering it’s what I already had available, it looks like it’ll fit my needs just fine.


Setting up a CNC Mill and Lathe Part 2

I didn’t write a post for it, but I did the CNC conversion on the Mill and Lathe about a month back, and for the most part, it went well. This weekend, I finally had enough spare time to get back to working on getting it actually up and running. I’ve somewhat trammed the machine and gotten rid of most of the backlash, but will need to do a bit more work on that before working on real parts — The big “fun” thing I did was get some g-code running on the mill, and do some practice engravings with a sharpie and some paper. Things are working pretty well, and there’s definitely something cathartic about the sound of the steppers working through circular profiles. (Even if the knobs on the handwheels are rattling somewhat. I’ll need to tape those down)

eCam Engraving Test
eCam Engraving Test

For a CAM program, I’ve been looking for something that can handle non-trivial profiles on the lathe, so that I can use it to machine the profiles of the AUV’s Kort nozzle and nose-cone. Affordable lathe CAM programs are hard to find, but one that has piqued my curiosity is eCam — I’m playing around with the trial version right now, and it seems to be working well for my uses so I think I’ll shell out and purchase a copy once I’ve confirmed it can output effectively to LinuxCNC for some specific uses cases I have. It’s definitely in the lower price range for CAM software, at least for hobby usage.

Some minor modifications to eCam’s post-processor were needed for the basic engraving routine:

  • Update the “Head New Program” section by removing the line “O{PRG_NUM}({PRG_NAME})” and splitting the line “G0G28G91Z0” into three unique lines, one for each G code command. (LinuxCNC doesn’t support multiple G-code commands with a coordinate in a single line. Multiple G-code commands without coordinates appear to be fine)
  • Disable incremental moves.
CNC Testing, "Engraving" With a Sharpie.
CNC Testing, “Engraving” With a Sharpie.

Loading up the code was pretty painless, and the milling machine is working well so far! The lathe tests are showing I need to do a bit more work on the postprocessor to get it to play nicely with LinuxCNC, but it doesn’t look like it will be too onerous.

I’ll try to get some materials soon, after which if all goes well I can start working on some of the AUV’s structural components.

Leave a Comment

Setting up a CNC Mill and Lathe Part 1

One of the key factors to getting my AUV project underway was converting my mill and lathe to CNC, something I’ve been meaning to do for a while. After much research, I settled on the Gecko 540 and some decent steppers and put in a parts order.

With those parts en-route, I talked getting LinuxCNC running on a machine from 2006 — An AMD 64 X2 3800+ based computer, with a Radeon X850 video card. Initially trying the latest and greatest LinuxCNC, I got atrocious latency results. I ended up trying out old releases, starting with 8.04 (Hardy Heron was a flash from the past!) up to 12.04 and settled on 10.04 as the best compromise in terms of latency performance vs new distro. After a lot of painstaking work, I finally got good latency results:

Final Latency Test Results
Final Latency Test Results

It ended up being a bit of a paint to tweak everything just right to minimize latency spikes and in the end, I think I’ve actually made my BIOS inaccessible with a USB Keyboard, so next time I want to get into it I’ll need to scrounge up an old PS2 keyboard… To get this relic of a computer running reliably, I ended up having to:

  • Install of the 10.04 ISO and then update the LinuxCNC install to 2.6
  • Turn off _everything_ in the BIOS, or at least set it to manual (e.g. overclocking, power savings)
  • Modify Grub to pass “acpi=disable isolcpu=1” plus the additional options in the next link
  • Applying the IRQ tweaks listed here (This dropped the regular latency by an order of magnitude!)
  • Still using the stock open-source Radeon driver — Vesa improved the “resting” latency by a factor of 2, but when running glxgears it popped back to the same range.

The frustrating part is that I still experience large spikes when opening Firefox or other applications while 2x glxgears are running, I suspect due to some HDD access issue. Either way, I’m not planning on using this machine for anything else while machining, so hopefully I won’t run into problems with that. Without opening large programs and running 2x glxgears, I’m getting a latency of about 5000ns — Not too bad!




Leave a Comment

Musing on Star Trackers

Several years back, I was intrigued by the concept of the “PicoSat” form factor, which is smaller than a CubeSats that instead of costing the same as a house to launch, only cost approximately the price of a car to launch. A few had launched as sub-payloads on a Dnepr, including the $50 Satellite (Eagle-2) which operated for a surprisingly long time.

Gears in my head immediately began churning for a thought exercise on how small you could make things to fit on a PicoSat — Maxon EC10 flat based reaction wheels, miniaturised ablative plasma thrusters, tiny mirror-based zoom lenses, and as the title suggest, star trackers.

Remote sensing satellites need extremely good pointing accuracy in order to take images of what they need to on the ground. While other small scientific missions can typically make do with basic orientation based on sun detection, earth/horizon detection or even passively through gravity gradients, using magnets and hysteresis rods, to be able to take a decent resolution image of anything on the earth, you need better pointing accuracy. that’s where star trackers come in.

Since the stars are relatively stationary in the sky, as with the old days of sail, they can be used for navigation and specifically for highly precise orientation of satellites. The positions of stars in the sky are very well known, including their small relative motion.

As a thought exercise, and as a way to learn some more Python, I wrote a small star tracker program that assumed an input from a 640×480 imager with a small lens in front. I didn’t do any work into determining the actual SNR of the stars as my focus was primarily on the algorithm. Detecting faint stars in orbit is a challenge in and of itself which I won’t address in too much detail in this post. This was all done years ago, so I’m writing mostly off of memory and comments I left scattered around my Python code…

I downloaded the publicly available Hipparcos star catalogue as a basis for my star tracker, which contains the position at the epoch of measurement, as well as their relative motion so I could adjust their positions to the current date.  This catalogue was processed to make a unique catalogue for the star tracker, which included not only position but also relational data comparing each star to neighbouring stars.

For test images, I simply used Stellarium with a representative rectilinear lens configuration. I output the screenshot, loaded it into python and ran the algorithm.

Before I go any further, I want to point to the references at the bottom, as they were used to guide the process of development of this code, notably reference 1 is a great resource and worth a read if you’re interested in learning more about star trackers! A lot of the methods outlined in that document are what I used to develop this code.

The methodology I used was as follows. The code was written to eventually be translated to C for a small microcontroller, so I avoided use of libraries in the core algorithm which wouldn’t have simple, high-performance comparable libraries in the embedded C world.

  1. Detect centers of stars using a weighted average blobing algorithm
  2. Step through stars in order from brightest to least bright, and calculate a “triad” for each:
    1. Find two next brightest stars within a specified distance
    2. Based on the two vectors made up by the two stars centered on the origin star, create a unique relational triad for comparison
  3. After all triads are computed, compare to the catalogue to find the closest match and identify stars and their positions
    1. Perform this iteratively, as multiple hits per star are gained, and there are false alarms
    2. Sort detected stars based on how close the calculated triad was to the matched catalogue value
  4. Starting with the closest match, perform vector space rotation to determine exact match. Refine calculated orientation by running through subsequent matches.
Sample Results, Centred on HIP59928
Sample Results, Centered on HIP59928

Results of the full algorithm. Stars found by blobbing are circled in green, with a red dot in their centre and with a yellow index number assigned. Red lines indicate all the triads considered in the match, and the detected star Hipparcos catalogue numbers are shown in white/blue. Only stars in the center yellow rectangle were used as the basis for triads, as anything outside of that risked having the next adjacent bright star out of frame, leading to erroneous results. Pretty accurate overall!

Algorithm Outputs Centred on HIP3821
Algorithm Outputs Centred on HIP3821

Now, this algorithm isn’t sufficient for a real star tracker, as several problems would still need to be addressed:

  • Planets
  • Noise in image due to low SNR
  • Real star-trackers are often de-focused to create larger blurry stars to aide with centroiding. This would require adjustments.
  • How to deal with bright objects (e.g. sun). Usually accomplished with shrouds
  • Rotational accuracy is usually not great with star trackers, requiring two pointing in different directions to get peak accuracy
  • etc….


  1. Raveesh Kandylil – Attitude Determination Software for a Star Sensor
  2. Wiley J. Larson and James R. Wertz, Space Mission Analysis and Design (There’s a newer version: Space Mission Engineering: The new SMAD)
Leave a Comment