Next step is to put a QR code on there that links to the data sheets.

From Misc Projects

A link to the very rough code is here, you will probably have to modify it to suit your situation: chip_ptouch.tar.gz

UPDATE

I have updated the tarball above to include printer control code generator to print the pngs in raw mode, more chips, and a README with sample usage.

I was able to find these A3144 hall effect sensors for 19 cents each. That’s right, cheaper than switches, cheaper than opto endstops, and superior to both. And there appears to be tons of suppliers for the things, so they are not going away anytime soon. They just have three pins, GND, Vcc, and signal. The signal is normally open collector, get a magnet close and it drains to ground. Now, when trying to figure out how to interface this with the standard RAMPS hardware, I came up with the below circuit.

From Hall Effect

That’s right. The three pins are _exactly_ the same pins, in the same order, that RAMPS expects its endstops to have. The only setup you need is a 3 pin jumper cable you can stick the sensor in. Simple servo cables from pololu or any RC store work perfectly and there is no need to solder anything. When looking at the larger flat side of the sensor, the left leg is the signal so should be oriented towards the outside of the RAMPS board when plugged in.

Here is it next to the large switch and printed holder it is replacing.

From Hall Effect

Just wrap it in electrical tape to insulate its wires.

From Hall Effect

Then attach it to your shaft with one face pointing towards your carriage. You can then affix the magnet to your carriage however you want, I just let the magnet stick to the motor body itself for the Z axis, but glue, tape, or a bracket would also work. Just whatever you do, make sure both the magnet and sensor are very secure to get repeatability in your measurements. Also, the sensor only detects the magnetic field in one direction, so make sure the proper (north or south) pole is facing the sensor! Just test it before permanently glueing anything.

From Hall Effect

From Hall Effect

Now, the Hall effect triggers by sinking the signal to ground, so be sure to enable the pull up resistors for your endstops and set the “INVERT_ENDSTOP” flag in your firmware.

Since I was playing around with these hall effect sensors, I decided to create a little handheld magnetic field sensor that would allow me to test for the presence and polarity of magnet fields and came up with this handy device.

From Hall Effect

While playing around testing various magnets, I re-discovered something interesting, those throw away flexible refrigerator magnets are not actually just a plain magnet, but a repeating pattern of north and south poles that can be read with the sensor.

for 19 cents, this seems like a pretty useful little device. And there should be no reason to use mechanical or optical endstops anymore, these are way cheaper, more reliable and simpler.

The goal this year was to write a leaky image redaction program. Given an input image in PPM format and a rectangle, it would spit out the image with the rectangle blacked out, perhaps hiding sensitive information. The tricky part was that you had to leak the redacted information. There are more details in the problem specification.

So, before I go on, here is my complete entry. See if you can figure out how the information is leaked before reading further if you like.

/*
 * This is a simple redactor, it accepts a plain text ppm file, a set of
 * coordinates defining a rectangle, and produces a ppm file with said
 * rectangle blacked out.
 *
 * Usage: redact in.ppm x y width height > out.ppm
 */
 
int
main(int argc, char *argv[])
    {
        if(argc != 6) {
            fprintf(stderr, "usage: redact in.ppm x y width height > out.ppm\n");
            exit(1);
        }
 
    // process command line arguments
    int rx = atoi(argv[2]), ry = atoi(argv[3]), rwidth = atoi(argv[4]), rheight = atoi(argv[5]);
 
    FILE *ppm = fopen(argv[1],"r");
    if(!ppm) {
        perror(argv[1]); exit(1);
    }
 
    //read the ppm header
    unsigned width,height,maxdepth;
    fscanf(ppm,"P3\n%u %u\n%u\n", &width, &height, &maxdepth);
    printf("P3\n%u %u\n%u\n", width, height, maxdepth);
 
    //current locations
    int x = 0, y = 0, ws = 0;
 
    //fixed buffer size to avoid overflow
    char buf[BUFSIZE], *c;
 
    while(fgets(buf,BUFSIZE,ppm)) {
        for(c = buf;*c;c++) {
            if(isdigit(*c)) {
                if(!ws) {   // new number, increment location.
                    ws = 1; x++;
                    if(x >= width * 3) {
                        y++; x = 0;
                    }
                }
                if(x > rx * 3 && x <= (rx + rwidth) * 3 && y > ry && y < ry + rheight)
                    putchar('0');
                else
                    putchar(*c);
            }  else {
               ws = 0;
               putchar(*c);
            }
        }
    }
    return 0;
}

The trick involves the format of the P3 style PPM file. The format is a plain text format, it has some basic header info, then a list of whitespace separated numbers, such as 234 2 0 83 255 255 2 43 255 where the numbers represent the magnitude of the red, green, and blue component for each pixel in order. The redactor simply replaced values within the target rectangle with zero. However, due to the way I process the file, character by character, I leak how many digits each value had to begin with. i.e., the above would be redacted to 000 0 0 00 000 000 0 00 000. This is completely invisible when viewing the PPM file, all the values count as zero as far as the format is concerned, but by looking at the original file, you can recover some information about what was in the blanked out area. It is particular effective on black on white text, the most common thing needing to be redacted, where each value is 0 0 0 or 255 255 255, allowing perfect reconstruction of the original.

One of my favorite parts of my entry that isn’t mentioned on the prize page is that it has great plausible deniability as the leak was introduced by properly working around a commonly known and particularly insidious C bug, the improper use of gets and (more subtly) fgets. I can imagine a code review going somewhat like the following:

Spook: “So why did you process the file character by character, rather than doing the more obvious scanf(“%i %i %i”,&r,&g,&b) to read in the values?”

Me: “Well, in order to do that I’d have to read in entire lines of the file. Now there is the gets function in C which does that, but has a well known buffer overflow bug if the line length exceeds your buffer size, so I naturally used the safe fgets variant of the function. Of course, with fgets, you can just assume your buffer size is greater than the maximum line length, but that introduces a subtle bug if it isn’t, you may end up splitting a number across two buffers, so scanf will read something like 234 as the two numbers 23 and 4 if it is split after the second character, hence the need to consider each character independently.”

Spook: “Ah, of course. good job at spotting that.”

Me: *snicker*

It is also a great example of the principle that you can’t protect against intending to write the wrong thing. The code will stand up to any buffer overflow check, code style check, or lint program. The code is correct and proper C code; the bug was not introduced in the code, but much earlier, in my head when I conceived the algorithm. No matter how smart your tools are, if you ultimately intend to write the wrong thing or solve the wrong problem, they can’t protect against that.

This issue was somewhat compounded in the design of the cupcake CNCs electronics in that the first testable configuration involved many different components, an ardunio motherboard, a stepper driver, host software running on a PC,  and the various interconnects. Coming up with a way to test the stepper driver boards independently of the rest of the system was quite useful. I whipped up the following simple circuit to test the stepper boards. None of the component values are very important, C1 is a debouncing capacitor for the pushbutton, R1 is a pull down resistor, and R2 is to protect the LED.P1 is a power header that accepts a floppy connector power supply cord from the same PC supply that powers the stepper driver.

Many modern languages such as Haskell have a concept of a type alias. It is called a newtype in Haskell and I will borrow that terminology here. A newtype is a type that is fully equivalent at run-time and in generated code to an existing type, but nevertheless is distinct to the type system at compile time. They are quite useful in enforcing abstraction of APIs and catching a wide variety of bugs without incurring any run-time penalty. In fact, depending on the compiler, they may actually help optimization. Imagine you represent open files as an index into a table, much as the unix API does, naturally you would represent it by an int. You may have something like this, declaring fd_t as a handy synonym to show when you are working with file descriptors.

typedef int fd_t;
/* write an int out to a file */
void put_int(fd_t fd, int c);

Now, what happens if someone forgets the order of the arguments to put_int? since fd_t is a synonym for int, the compiler has no idea you did anything wrong and happily writes garbage to a random file. Not what we wanted at all. If fd_t were a newtype rather than a typedef synonym then the program would be rejected, because fd_t and int would be distinct types.

This brings us to the following bit of code you can place in a header file newtype.h. Using compound literals, it allows the declaration of newtypes that can be used almost anywhere you can use built in types.

#ifndef NEWTYPE_H
#define NEWTYPE_H
/* this can be used for type safety, to avoid accidental casting of values from one type to another and
 * allowing alias analysis by the compiler to distinguish otherwise identical types
 *
 * NEWTYPE(new_type,old_type); declares new_type to be an alias for the already exsiting old_type
 * TO_NT(new_type,val)  converts a value to its newtype representation
 * FROM_NT(new_val)  opens up a newtyped value to get at its internal representation
 */
 
#define NEWTYPE(nty,oty) typedef struct { oty v; } nty
#define FROM_NT(ntv)       ((ntv).v)
#define TO_NT(nty,val)     ((nty){ .v = (val) })
 
#endif

Now we can modify the above example, instead of

typedef int fd_t;

we use

NEWTYPE(fd_t,int);

Another example would be the traditional lseek routine that comes with C. it is generally declared as something like

#define SEEK_SET 0
#define SEEK_CUR 1
#define SEEK_END 2
long lseek(int fd,long offset, int whence);

Now, whence is supposed to be one of the SEEK_* defined terms, and fd is supposed to be an open file descriptor, and offset is supposed to be an offset into the file. however, to the compiler on many architectures all the argument types are indistinguishable. this means that if you mix up any of them, the compiler will happliy go along. in addition, you can pass bogus values in for ‘whence’ like 5 or 6, and nothing will complain. using newtypes, you might declare the API like so.

NEWTYPE(fd_t,int);
NEWTYPE(whence_t,int);
#define SEEK_SET TO_NT(whence_t,0)
#define SEEK_CUR TO_NT(whence_t,1)
#define SEEK_END TO_NT(whence_t,2)
long lseek(fd_t fd,long offset, whence_t whence);

Now, not only are you protected from mixing up any of the arguments, you are also protected from bogus values being passed into the whence argument meaning you can elide the run-time check for valid values since the compiler will check it for you.

Although this is just the simplest use of compound literals, it is already proving to be quite useful. When combined with other C99 features such as variable length arrarys you can do clever things like non-conservative garbage collection in a clean way, or just make your code that much easier to read by not having to declare temporary structures everywhere.

A fingerprint cannot be compromised. A biometric identifier is not like a password. it is not meant to be secret. Think of your fingerprint as… well… like a public key cryptographic fingerprint really. Your public key fingerprint isn’t secret. in fact, you generally want to distribute it as far and wide as possible. What makes it useful is that there is a corresponding private key that only you have that can be matched to said public key. A physical fingerprint is similar, everyone knows your fingerprint but there is only one warm human body that is associated with it. Present the warm human body (your own) that matches the fingerprint on file and you gain access. So we have the analogy that a public key fingerprint is to a private key as a physical fingerprint is to a warm human body with said fingerprint.

This of course means that biometrics are only good for ‘online’ verification, meaning there is a trusted path between your body and whomever you are identifying with. this can be anything from a physically secure ATM, a security guard that applys the test, or whatever is appropriate for the application. The security of biometrics comes not from the secrecy of the fingerprint, but the security of the path from the human being biometrically tested to the verifyer. Hence, you cannot ‘compromise a fingerprint’. You can however compromise a specific biometric system. If you find you can lift and transfer fingerprints easily with a gummy bear for a specific reader, you have broken that particular reader, but you don’t need to burn off your fingerprints and get new ones (like you change passwords when one has been compromised). you simply stop trusting anything that uses said broken reader.

PS. does anyone else enjoy the irony of using an abstract mathematical concept to explain a straightforward real world transaction?

Here is the final result:

The basic idea is the bottom servo (bottom is to the left) can bend the straw left and right, and the other servo can rotate the straw in place. the bend in the straw acts as a universal joint so the object held can be rotated somewhat arbitrarily in 3 dimensions.

A simple linkage connects the top servo to the straw. I attempted a couple different things, starting with a pully system, then a gear system. neither worked out too well. The linkage turned out to be quite simple and robust.

Here it is with the attached fan I attempted to use as a vaccum pump. It did not turn out too well, the fan was scavanged from an old CPU and was never meant to be used like this, so I will need an actual vaccum pump at some point.

Everything was controlled for testing with a Wii nunchuck and an arduino microcontroller with custom code. Here is a video of it in action:

So, some stuff I learned

• ShapeLock is wonderful stuff. I was able to form and reform the head a few times, even fairly large changes like making room for a gear involved reheating a part of the project and shaping it by hand. And I can just melt it down again and reuse it for my next prototype.
• The linkage is the way to go. I struggled a long time with gears and pullys. I imagine that if I were precision machining things and could get gears/pullys in the exact right size, things would have been different. But when it comes to the fuzzy world of hand-squished shapelock, the more forgiving linkage worked out great.
• I am gonna stock up on these tiny and cheap servos. They have a very interesting and useful bug. if you try to overextend them, they go into continuously rotating mode with no modification! So you can have the same servo work as a continously rotating one at some points, but also have precise precisioning at others.
• The Wii nunchuck is a great little thing. it took a few dozen lines of arduino code to interface with it and I got a joystick, 3 buttons, and a 3 axis accelerometer.