Russell's Blog

New. Improved. Stays crunchy in milk.

Makers do not make weapons

Posted by Russell on December 17, 2012 at 6:58 p.m.
Last Tuesday, I started writing an article about Thing 11770 on Thingiverse, a MakerBot Industries for sharing 3D printable objects. Thing 11770 is a reinforced 3D printable lower receiver for an AR-15 assault rifle. This is the part of the gun that feeds bullets from the magazine into upper receiver, which handles the cycling of the spent round and the insertion of the new round. With the right combination of upper and lower receiver, fresh rounds are cycled into the weapon using a portion of the kinetic energy from firing the previous round. When the trigger is pulled, this process happens continuously, firing one bullet after another. That is what it means to be an "automatic" weapon. Thing 11770 is particularly interesting because, legally speaking, the lower receiver is the gun itself. It is the engine that makes the gun a gun, rather than a movie prop. And you can 3D print it. And it works.

At very the moment I was hemming and hawing over how to articulate my feelings about this development, someone used an AR-15 to murder twenty seven people, including twenty children, ages six and seven at Sandy Hook Elementary School. Now I know exactly how I feel.

I love 3D printing. I love the maker movement. I love the idea of people building home-brew versions of all sorts of devices, and inventing entirely new classes of devices. 3D printing has played, and will continue to play, an important role in that.

When I was fourteen, like many boys at that age, I thought missiles and fighter planes and tanks were pretty awesome. I read a lot of Tom Clancy books, and I indulged in my interest by dragging my family to the Wright Patterson Air Force Base Museum, the Smithsonian Air & Space Museum, the California Science Center’s Air & Space Museum, and the Intrepid Air, Sea & Space Museum. At Wright Patterson, I visited the F-117 Nighthawk as many times as I could. The author of Thing 11770 calls himself "Have Blue," the codename for the Nighthawk demonstrator aircraft.

When I was sixteen, I went to boarding school, where I learned vector calculus and farming. I learned how to grub potatoes out of the freezing ground in the driving rain, how to make maple syrup, how to lay in beets and squash and onions for the winter. I stood on a windy mountain top and learned how to find the orbital ephemera of a comet. I learned how to milk cows, how to care for cows when they are sick, and how to make the most delicious yogurt and mozzarella cheese you could possibly imagine. I learned how to repair a tractor engine with a mallet and a wrench. One freezing night, I found myself covered in blood and shit and urine and fear as I helped bring a new life gasping and staggering into the world.

Farming also means slaughtering and butchering. One morning, I walked into the barn. I was handed a weapon. I was asked to take a life.

I found that I could not.

Not ever.

The instant my shoulders took up the weight of the strange, snub nosed machine, it felt like the weight of the metal hung from my heart, stretching and distorting it. I wanted the weight of it to tear me apart, but I knew it was a weight I could carry, if I wanted to. I quietly handed the gun back to the farm manager, and walked out into the thawing snow, and spent the rest of the black pre-dawn puking into the mud behind the water tower.

Many people have wondered why I do not eat meat. This is why. For the rest of my life, I will feel the weight of that terrible little machine.

There are reasons to make, to have and to use guns. To defend your country, yes. To humanely put down an animal before butchering it, perhaps. For vainglory? For entertainment? No.

Tools are sacred things. We are a tool-using species; our tools are projections of our hopes and aspirations. When we are filled with joy, we pick up our tools and hammer the air into music. We need to understand and to be understood, and so we shape our voices into language. We send our tools delicately probing into the bodies of our loved ones, seeking out cancers and blood clots and infections. We invest huge amounts of effort building and maintaining tools that allow us to speak to one another across great distances. We hurl our tools across the void to other planets to satisfy our craving for knowledge. When we grieve, we take up our tools and carve the names of those we have lost into the living rock of our planet. Our tools are our souls. They are our defining characteristic. Love may be what makes us alive, but our tools are what make us human.

A gun is a tool. It is a simple tool. Any man or woman or child can use one. A gun is not much more complicated than a can opener, and not nearly as sophisticated as cordless screwdriver. Like all tools, a gun reveals something fundamental about its maker, its wielder and its abuser. This is true for all weapons.

As a strong supporter of the maker movement, of free and open source software, of open science, I want people to have as much freedom as possible to make and remake and experiment. I also believe very, very strongly in the responsibly we have to one another. I believe that we each have a responsibility not make things that hurt and kill and destroy.

I am not yet prepared to call for a law to prohibit Have Blue from posting functional 3D printable assault rifle parts on the internet. The law is a blunt instrument, and would cause a great deal of collateral damage. However, I am prepared to say that Have Blue is a fucking asshole. I am prepared to call Justin Halford, who created the original CNC model, a fucking asshole. I am prepared to say that anyone who considers themselves a "gun enthusiast" and is older than about sixteen needs to grow the fuck up. The maker community should not tolerate this behavior. Meditate on the meaning of the word antisocial for a moment. What could be more antisocial than gleefully proliferating machines whose principal function is murder?

The maker community should not tolerate these designs, or the ideas and opinions of their designers until they show evidence of behaving like adults. It's clear that the CNC Gunsmithing community has a lot of talented, clever people. It's clear from reading his blog that Have Blue is neither ignorant nor stupid.

So, I'm calling you folks out. There are twenty children dead in Connecticut. Their bodies were ripped apart by the very machines you are "democratizing." As far as I know, nobody has used your designs to kill anyone. If you continue down this path, some future version of Thing 11770 will be used to murder little children. It's just a matter of time, and probably a lot less time than you think. However, there is still time to take a stand. Do the right thing. Take down the designs. Apologize for what you've done. Find a new project. Use your talents for something good. This will not stop people from murdering children with 3D printed guns, but perhaps you can buy us some time before that day comes. You know that this is true.

If making home-brew assault rifles is really what you want to do, there is perhaps one venue where this might actually make sense. Freight your CNC machine to Istanbul, and smuggle it into Homs or Aleppo. Help the Free Syrian Army get rid of Bashar Assad. Oh wait, what’s that? You don't want to get shot? Fancy that.

It takes courage to admit you are wrong. Show us some courage.

Update : It appears that MakerBot has decided to remove Thing 11770 from Thingiverse. If you follow the link to the item, the files have been removed and a message says, "This Thing is currently under moderation for violating the Thingiverse Terms of Service. Files and images for this Thing are currently unavailable." I'm glad it's no longer up, but I am disappointed in how this was handled. I'm disappointed that MakerBot left it up for so long, but I'm also disappointed that Have Blue didn't just take it down himself.

Why doesn't your lab have a 3D printer yet?

Posted by Russell on November 20, 2012 at 6:30 a.m.
Electrophoresis setups are like Tupperware. You can never find the right lid when you need it, and someone always seems to be borrowing the doohicky you need.

Here in the Eisen Lab, it turns out we've been using Marc Facciotti's electrophoresis stuff for years. He keeps his stuff organized, and, well... that's not been our strong suit lately. John, our lab manager, has been gently but inexorably herding us towards a semblance of respectability in our lab behavior. As part of this, he decided that it was time for us to get our electrophoresis stuff straightened out. So, he ordered a bunch nice of gel combs from one of our suppliers. They cost $51 each (see the "12 tooth double-sided comb", catalog number 669-B2-12, for the exact one pictured below). We bought six of them with different sizes and spacing, for a total exceeding $300.

While I appreciate that companies need to make money, this is a ridiculous price for a lousy little scrap of plastic. $300 for a couple of gel combs is cartel pricing, not market pricing. Fortunately, we happen to have a very nice 3D printer. It is very good at making little scraps of plastic. So, I busted out the calipers and tossed together some models of gel combs in OpenSCAD. A few minutes of printing later, and the $51 gel combs are heading back to the store.

Here's the code for the six well 1.5mm by 9mm comb :

f=0.01;
difference(){
  difference(){
    union(){
      cube( [ 80, 27, 3 ] );
      translate( [ 5.25, 14.3, f ] ) cube( [ 68, 9.3, 7.25 ] );
    }
    for ( i = [ 0:5 ] ) {
      translate( [ 17.1+i*11.0, -f, -f ] ) cube( [ 1.75, 12, 5 ] );
    }
  }
  union(){
    translate( [ -f,   -f, -f ] ) cube( [ 7,  12, 7] );
    translate( [ 73+f, -f, -f ] ) cube( [ 7,  12, 7] );
    translate( [ 0,    -f, 1.6] ) cube( [ 80, 12, 8] );
  }
}
Pretty easy to grasp, even if you've never seen SCAD before.

So, how much did this cost?

I ordered this plastic from ProtoParadigm at $42 for a kilogram. That's about four pennies a gram. Each of these gel combs cost about 21 cents to print. That's 1/243rd the price.

The 3D printer cost €1,194.00 ($1524.62), which is less than the laptop I use for most of my work. The savings on just these gel combs has recuperated 18% of the cost of the printer.

It's also important that I was able to make some minor improvements to the design. The printed combs fit into the gel mold a bit better than the "official" ones. I also made separate combs for the 1.0mm and 1.5mm versions, and the labels are easier to read. If I wanted, tiny tweaks to my SCAD file would let me make all sorts of fun combinations of thicknesses and widths that aren't available from the manufacturer. So, these gel combs are not only 1/243rd the price, but they are also better.

If you read the media hype about 3D printing, you will undoubtedly encounter a lot of fantastical-sounding speculation about how consumers will someday be able to print living goldfish, or computers, or bicycles. Maybe so. Maybe not. However, right now, you can print basic lab supplies and save a pile of money.

Buy your lab manager a little FDM printer and hook them up with some basic CAD training. Yes, the printer will probably mostly get used to make bottle openers and Tardis cookie cutters. So what? Your paper-printer, if you will excuse the retronym, mostly gets used for non-essential stuff too. I'd wager that for every important document printed in your lab, a hundred sheets have gone to Far Side cartoons and humorous notices taped up in the bathroom. It's a negligible expense compared to the benefits of having a machine that spits out documents when you really need them, and the social value of those the Far Side cartoons probably sums to a net positive anyway.

Conclusion : If you have a lab, and you don't have a 3D printer, you are wasting your money. Seriously.

In the time it took write this post, I printed $150 worth of gel combs, and it cost less than a cup of coffee.

Updates : Here is the tweet I originally posted about this article, before the URL for it vanishes into Twitter's memory hole. Here's an encouraging post from the Genome Web blog, and a nice article by Tim Dean at Australian Life Scientist. My article here seems to have spawned a thread on BioStar. Also, it made Ed Yong's Missing Links for November 24 over at Discover, and Megan Treacy did a really spiffy article over at Treehugger.

Many people have asked, and so I decided to see how well these kinds of 3D printed parts do in the autoclave. I tried it out with a couple of bad prints, and they seemed to hold up just fine after one or two cycles. Very thin parts did warp a bit, though, so I recommend printing parts you plan to autoclave nice and solid. Here is a before and after of a single-wall part (less than half a millimeter thick). I was expecting a puddle.

Update 2 : Check out Lauren Wolf's awesome article in Chemical & Engineering News, featuring the infamous gel combs, among other things!

Trouble with SoftSerial on the Arduino Leonardo

Posted by Russell on May 25, 2012 at 12:05 p.m.
While I was wandering around at Maker Faire last weekend, I heard someone say, "Woah, is this the Leonardo?" And lo, there was a handful of Arduino Leonardo boards lined up on a shelf for sale. I instantly grabbed one, and bundled it home to play with it.

The Leonardo is Arduino's latest board, announced last September. It uses the Atmega32u4 chip, which has onboard USB. This has two important implications; first, the Leonardo costs less than the Uno, and second it will be able to operate in any USB mode. That means people can make Human Interface Devices (HID), like mice and keyboards and printers, with Arduino, and present themselves to the host using the standard USB interfaces for those devices. That means you can build things that don't need to talk via serial, and use the host's built-in drivers for mice and printers and whatnot. This is a big step forward for Open Hardware.

Anyway, I'm developing an little remote environmental data logger to use for part of my dissertation project, and I thought I'd see if I could use the Leonardo board in my design. I'm using the Arduino board to talk to an Atlas Scientific pH stamp, which communicates by serial. It works fine on the Uno with SoftwareSerial (formerly known as NewSoftSerial until it was beamed up into the Arduino Core mothership).

Unfortunately, it didn't go so well on the Leo. The board can send commands to the pH stamp, but doesn't receive anything. I swapped in an FTDI for the pH stamp, and confirmed that the Leonardo is indeed sending data, but it didn't seem to be able to receive any characters I sent back. I tried moving the rx line to each the digital pins, and had no luck. Here is my test program :

#include <SoftwareSerial.h>

#define rxPin 2
#define txPin 3

SoftwareSerial mySerial( rxPin, txPin );

byte i;
byte startup = 0;

void setup() {

  mySerial.begin( 38400  );
  Serial.begin(   9600   );
}

void loop() {
  
  if( startup == 0 ) {             // begin startup
    for( i = 1; i <= 2; i++ ) {
      delay( 1000 );
      mySerial.print( "l0\r" );    // turn the LED off
      delay( 1000 );
      mySerial.print( "l1\r" );    // turn the LED on
    }
    startup = 1;                   // don't re-enter
  }                                // end startup

  Serial.println( "taking reading..." );
  mySerial.print( "r\r" );
  delay(1000);
  
  Serial.println( mySerial.available() );
  
}
On the Uno, I see the number increasing as the read buffer fills up :
taking reading...
0
taking reading...
0
taking reading...
7
taking reading...
16
taking reading...
16
On the Leo, it seems that nothing ever gets added to the read buffer, no matter how any characters I send over from the FTDI or which pins I used for the rx line :
taking reading...
0
taking reading...
0
taking reading...
0
taking reading...
0
taking reading...
0
taking reading...
I really wanted to see if I was crazy here, but I'm one of the first people among the General Public to get their hands on a Leonardo board. So, I started talking with Ken Jordan on #arduino on Freenode (he goes by Xark) who has a similar board, the Atmega32u4 Breakout+. It's based on the same chip as the Leonardo, but it has different pinouts and a different bootloader. He flashed the Leonardo bootloder onto his board, and worked out the following pin mapping :
Arduino 1.0.1     Adafruit         ATMEL
digitalWrite pin  atmega32u4+ pin  AVR pin function(s)
----------------  ---------------  ------------------
D0                D2               PD2 (#INT2/RXD1)
D1                D3               PD3 (#INT3/TXD1)
D2                D1               PD1 (#INT1/SDA)
D3#               D0               PD0 (#INT0/OC0B)
D4/A6             D4               PD4 (ICP1/ADC8)
D5#               C6               PC6 (OC3A/#OC4A)
D6#/A7            D7               PD7 (T0/OC4D/ADC10)
D7                E6 (LED)         PE6 (INT6/AIN0)
D8/A8             B4               PB4 (PCINT4/ADC11)
D9#/A9            B5               PB5 (OC1A/PCINT5/#OC4B/ADC12)
D10#/A10          B6               PB6 (OC1B/PCINT6/OC4B/ADC13)
D11#              B7               PB7 (OC0A/OC1C/PCINT7/#RTS)
D12/A11           D6               PD6 (T1/#OC4D/ADC9)
D13#  (LED)       C7               PC7 (ICP3/CLK0/OC4A)
D14   (MISO)      B3               PB3 (PDO/MISO/PCINT3)
D15   (SCK)       B1               PB1 (SCLK/PCINT1)
D16   (MOSI)      B2               PB2 (PDI/MOSI/PCINT2)
D17   (RXLED)     B0               PB0 (SS/PCINT0)
D18/A0            F7               PF7 (ADC7/TDI)
D19/A1            F6               PF6 (ADC6/TDO)
D20/A2            F5               PF5 (ADC5/TMS)
D21/A3            F4               PF4 (ADC4/TCK)
D22/A4            F1               PF1 (ADC1)
D23/A5            F0               PF0 (ADC0)
-     (TXLED)     D5               PD5 (XCK1/#CTS)
-     (HWB)       -  (HWB)         PE2 (#HWB)
This was derived from the ATmega 32U4-Arduino Pin Mapping and ATMEL's datasheet for the ATmega32U4 chip. Once that was worked out, he flashed my test program onto his board, and also found that SoftwareSerial could transmit fine, but couldn't receive anything.

Ken rummaged around a little more, and had this to say :

The SoftSerial seems to use PCINT0-3 so there seems to me a minor problem in Leo-land in that only PCINT0 appears to be supported (and it is on "funky" output for RXLED). Hopefully I am just misunderstanding something (but it imay be the interrupt remap table is incorrect for Leo).
Then he disappeared for a little while, and came back with :
I have confirmed my suspicion. When I disassemble SoftSerial.cpp.o I can see that only __vector_9 is compiled (i.e., one of 4 #ifdefs for PCINT0-3) and the interrupt vector 10 is PCINT0 (0 is reset vector so offset by one makes sense). So, unless you hook serial to RXLED pin of CPU I don't believe it will work with the current libs.

Also I believe the Leo page is just wrong when it says pins 2 & 3 support pin change interrupts (I think this was copied from Uno but it is incorrect, the only (exposed) pins are D8 D9 D10 and D11 that support PCINT according to the ATMEL datasheet (and these are PCINT 4-7 not the ones in the interrupt mapping table AFAICT).

I believe this is where I can stop worrying that I'd be wasting the time of the core Arduino developers, and say quod erat demonstrandum; it a bug in SoftwareSerial. Hopefully they can update the Arduino IDE before the boards hits wider distribution.

Update : So, it turns out that this is a known limitation of the Leonardo. David Mellis looked into it, and left this comment :

You're right that the Leonardo only has one pin change interrupt, meaning that the software serial receive doesn't work on every pin. You should, however, be able to use pins 8 to 11 (inclusive) as receive pins for software serial. Additionally, the SPI pins (MISO, SCK, MOSI) available on the ICSP header and addressable from the Arduino software as pins 14, 15, and 16 should work.
He is, of course, correct. I'm not sure why my testing didn't work on pins 8-11, but they do indeed work fine. Unfortunately, this means that the Leonardo is not compatible with a number of cool shields. The Arduino SoftSerial Library Reference documentation has been updated with a more detailed list of limitations.

Central serous retinopathy

Posted by Russell on January 08, 2010 at 11:06 a.m.
The eye doctor in Davis confirmed that my magical eye bubble is central serous retinopathy. Here's a much better picture (now also on Wikimedia Commons).

That volcano-shaped thing is supposed to be a little pit (that's what "fovea" means).

I'm a bit pissed off that the Zeiss optical coherence tomography machine that the doctor used to take this image evidently keeps the data locked up in a proprietary format, and can only exchange data with other Zeiss products. The doctor says he can't even save a screenshot. The only way I could get this picture was by snapping a photo of the display with my phone.

I'm impressed with the technology, and I'm happy to pay for it. It's much better than the machine used to take the image in my first post about this, and allowed for a quick and unambiguous diagnosis. I just don't want to pay more for it than it actually costs. Ziess is taking a page out of Microsoft's playbook here by leveraging proprietary data formats and locked-down data sharing to coerce doctors into buying their equipment instead of someone else's. Except, the stakes are higher for medical products.

Update -- On February 9, 2011, I had Photodynamic therapy at the UC Davis Medical Center, under the care of Professor Susanna Park and her clinical staff. The surgery itself seems to have been completely successful -- the "bubble" is gone. However, because I had it for so long (more than a year), there was some damage to the retina, probably due to oxygen deprivation. This is taking longer to heal.

The result is that he distortion, blurriness and discoloration are gone, but dimness is taking much longer to go away.

I'm not a medical doctor, of course, but I suspect that waiting makes the recovery take longer. My hypothesis is that the longer the retina is under pressure and loosing part of its blood supply to leakage, the longer it will take to recover.

Usually, CSR will go away by itself, but if it doesn't, don't be complacent about it. Listen to your doctor about how long to wait, and then stop waiting.

Rooted phone

Posted by Russell on September 12, 2009 at 4:05 a.m.
I finally got fed up with the pathetic official Android release from T-Mobile, and rooted my G1 and installed the CyanogenMod firmware. Cyanogen feels about twice as responsive as Cupcake! It's like a whole new device.

Also, the tethering app is awesome. It turns your G1 into a WiFi base station and routes traffic from WiFi to 3G. Since I'm still waiting for broadband at my new apartment, it's a lifesaver.

I suppose tethering (and rooting the phone) technically violates T-Mobile's TOS, but I'm convinced that T-Mobile will allow both sooner or later. It's just too awsome, and it would help them sell more contracts.

It's kind of difficult to abuse tethering anyway; it sucks down the battery very quickly, and the latency is significant. It's the sort of thing you'd only use in a pinch. Those happen to be the situations where a little benevolence or selfishness from a big company can shape a customer's opinion forever. T-Mobile seems to be more sensitive to that kind of thing than the other networks. I know they've got their reasons for banning tethering apps, but I think they could be convinced to change their minds. (You can download various petitions from the Android Marketplace.)

Openness is where Google and T-Mobile could really go after the unwholesome, anticompetitive and un-American AT&T/iPhone alliance. The open nature of Android is a step in the right direction, but T-Mobile needs to get its legal department on the Open Access bandwagon if it wants to press the advantage.

After all, if some random people on the internet can roll better firmware for the G1 than their in-house developers, isn't it a strategic business advantage to let them?

Rawstudio

Posted by Russell on May 16, 2007 at 6:05 a.m.
I've been puzzling over how to go about manipulating the NEF RAW images my camera produces. Obviously, it is better in principle to shoot in RAW than in JPEG, but the tools for editing RAW files under Linux do not seem to be very far along. For example, The Gimp doesn't natively support them. But that isn't to say there are no tools. Rawstudio provides pretty solid toolbox of basic manipulations. I can finally fix up the colors in some of my favorite shots.

Now, if only I had some good way of doing demosaicing, I'd be all set.