Tag Archives: yoyo

Nyancat cake mold, working PoV [not so yoyo], vending corkscrew test (mod servo for continuous rotation)

nyancake
Uhh I’ve been doing a lot of blogging and neglecting my other work, so here is minimalist style ftw.

nyancake? nyangummi?

My hall’s thanksgiving (putzgiving, alums come back for this) was two Saturdays ago. I tested out the nyancat cake mold:

for ease of “parameter optimization” runs, I used even-simpler-cake-recipe: cake mix and sprite as the only ingredients (apparently a dieting trick. comes out fine, although for molds probably want to let bubbles settle for a bit after pouring and before intensive mixing).
apply release agent, aka cooking spray / pam — otherwise doesn’t come out well. also,  sprite+cakemix mixture should not be too gloopy. add flour if accidentally pour too much sprite.

many fail results. Here, did not let bake long enough. (much longer than box says — I baked a bit lower temp based on silicone mold research, ~325deg C, and for say 1 or 2 hours)
demolded too quickly, also did not cover in saran wrap to retain moisture afterward
nyancake party~! nyan nyan nyan
probably the best of all my nyancakes. you can see that the minimum mold feature size — the sprinkles — were too small for the resolution of the cake mix and actually resulted in holes.
speed cooling jello in freezer. recipe used: the lego gummies from instructables
nyanjello = almost perfect mold replica. you can see the sprinkles are supposed to stand out, as opposed to how the nyancakes turned out. however, more limited / difficult coloring opportunities with jello than with cake (which you can just apply frosting / food coloring to)
Persistence of Vision Yoyo
I also figured out the issue with the MAS.863 makefiles causing my weird “compiler” bug (actually, compiler options / makefile bug):

Class-based makefile includes:
avr-objcopy -j .text -O ihex ./v0.1.45.out ./v0.1.45.c.hex
man avr-objcopy
       -j sectionname
       –only-section=sectionname
  Copy only the named section from the input file to the output file.
  This option may  be  given more than once.  Note that using this
  option inappropriately may make the output file unusable. >__> <__<
So the class makefiles should be fixed to include “-j .data”The internet says
“The makefile above DOES NOT create a proper HEX image and is a bad example. When creating an  image, not only does the text section (which holds the code) need to be included but the data section (which holds any initialized data) also needs to be included.
The remedy for this is correct .hex rule to to copy the data setion as well
Example:
$(OBJCOPY) -j .text -j .data -O ihex $(PROJECT).out $(PROJECT).hex
http://www.micahcarrick.com/avr-tutorial-digital-output.html

bmayton: that actually explains a lot of odd bugs that I’ve been seeing with people

using constant arrays, since the array data is never getting copied into the
program

So the actual model of what was causing my bug was, I believe, without calling another function the compiler goes ahead and uses the array to insert the correct commands into the compiled code. But when I used a subfunction, the compiler loads the subfunction which the microcontroller calls, but the ucontroller does not have the array data to look up what to set DDRB and PORTB to.

Anyway, then I proceeded to hack together terrible!code and get PoV working. I used oloepede’s sample image ‘cos I’m all about the laziest and quickest tests and ‘cos olopede is awesome.

eheh derp ripped off ISP traces / headers
works fine waving it by hand (without camera extended exposure time, hard to see entire “olopede” message — can see maybe three letters at a time. dead reckoning PoV timing — no sensors.) 

Doesn’t do so hot on the drill. Mess with timing? Although I spun it slow and fast (and in-use yoyo spins quite fast). May require sensors (fan pov as seen on dealextreme — product designer has better idea of speed of motor while yoyo has more variable speed. maybe they used hall effect sensors, ‘cos it was resilient to me slowing down the blades.) to get stable image.

See video:
https://picasaweb.google.com/113942194695013581888/PoVYoyoPersistenceOfVision#5681157457783660930

Vending machine
Right, essentially two weeks until final projects due. Aka time to start cramming on vending machine.

What do I have on hand? Arduino uno, extra servos leftover from when I bought out all the old 2.007 servos., zipties, handheld drill, a corkscrew. Found some rectangular metal thing to act as guiderails lying around MITERS scrap pile. Also found a block of wood lying around the floor.

Mod a servo  to be
continuous rotation servo
(essentially turn it into a cheap RC motor that comes with motor speed controller in a convenient package for mounting) —
aka remove mechanical stop on gear 

apply flush cutters to stop on gear

and remove pot, which like all pots doesn’t turn infinitely — make sure to be gentle ‘cos pot is held in by internal screw, why it doesn’t just fall out normally

see blurry screw at bottom. Also, I wasn’t gentle and cracked the PCB. Maybe it is inevitable for these servos (motor is soldered onto pcb so not much flexibility there) to get to pot screw. Surprisingly the servo still works…
stick pot on outside, chew a hole for it in the casing — i abused flush cutters

see How to Hack a Servo by Daniela Faas http://stellar.mit.edu/S/course/2/sp11/2.007/courseMaterial/topics/topic12/other/Servo_Hack_large/Servo_Hack_large.pdf)

springs / coils
Attach to corkscrew (from real vending machine) I bought off of ebay to see what real mass manufactured ones are like so I can make fake ones DIY like http://www.instructables.com/id/Make-your-own-springs-in-seconds/

Drill out servo horns (1/8” bit fits zipties I found) and attach to corkscrew with zipties

it vends a block! haha. terrible setup is terrible.

Video here:
https://picasaweb.google.com/113942194695013581888/VendingMachineOpenHardware#5681154916854562050

Yea, not a very interesting proof-of-concept (a “duh are you an idiot” one), but it was very satisfying to me.

Oh right, I tried to use hot glue to hold the pot in one place, since that affects how the servo reacts to servo.write() (pot adjusts when it goes fwd/reverse) — I just used
myServo.write(50) with a 0.5 sec delay
myServo.write(90) with a 3 sec delay
myServo.write(130) with a 0.5 sec delay
to calibrate the pot so that servo was completely still at 90. And then attempted to hot glue. a bit flaky– not good enough for long-term banging around but good enough for dirty proto.

yes, i stole arduino from hexarideablepod. arduino uno with a small breadboard on top and 3 male header pins to connect arduino (Vcc, Gnd, and SIG — arbitrarily pin 2 in my case) and servo. unplugged in this pic.

Not clear from pics, but to test it I’m holding the servo still with my hand.

PoV Yoyo update: v0.1 and failcode (also, Hello World in microcontrollers)

PoV yoyo update:
v0.1: 6 leds (3 pins), attiny45, phototrans, button, isp header (no battery) — board done.
v0.1 — code is the fails. I’ve been chasing this weird compiler bug for many days now.

So I milled and populated my eagle circuit and it works (well, the LEDs at least, haven’t tested buttons / phototransistor). https://github.com/nouyang/pov-yoyo and http://fab.cba.mit.edu/classes/4.140/people/nancy.ouyang/Week11/Week11.html

eagle schematic
I’m using the ng.lbr, fab.lbr, and the sparkfun libraries. More info here: http://academy.cba.mit.edu/tutorials/eagle/eagle_resources.html and the list of parts in fab.lbr:
http://fab.cba.mit.edu/about/fab/inv.html
board layout
slightly cleaned up, colors inverted, for milling out on the roland modella in the MIT Media Lab shop. I export at 1000 dpi to be safe, and clean it up in the open-source and free GIMP image editor.
powered off of USB for now. 

The yoyo is 3d printed, but it’s designed to be injection molded. I’m working with Laura Shumaker and Dan Fourie, and it’s based off of lshu’s 2.008 group’s yoyo design from last year. I’ll upload the Solidworks files when I get permission. Here’s what the CAD files look like (there are three parts. The PCB should pressfit inside the inner body, which fits inside the outer body, and the retaining ring goes on top, pressfitting into the outer body and making sure the inner body doesn’t come out).

The three parts that I 3d printed
So yea, you can poke the eagle file on github and see that I simply drew a rectangle starting at the origin and then set the x2 and y2 coordinates according to the 2d solidworks measurements. (For more on spatial constraints and pcb layout, see http://www.orangenarwhals.com/?p=163)

inner body determines dimensions of board. Corners filleted due to concern over injection molding mold machinability, but turns out to be unwarranted (I think), next version will have sharp corners.

I ended up approximating in Eagle the dimensions from the CAD file that I would need to fit inside the 

After that I devolved into code misery at the down point of which I was wondering why I couldn’t even copy code correctly. Turns out to be a makefile issue. See: http://www.orangenarwhals.com/?p=162

Anyway, so now I’m at the point where I can turn each LED on individually, I’m still trying to figure out my code bugs.

Oh right, this is after my realization last week that I don’t understand any codes. Not even hello world codes.  0b000? 0x000? 0? char? int? huh?

So, I read up on bit operations stuff -^-^-
I recommend these for explaining the hello world code, which seems straightforward now (turn LED on! turn off!) but seemed completely foreign when I was trying to debug my code / write my own / mash together code from other people.
[1] http://fab.cba.mit.edu/content/tools/microcontrollers/c_for_microcontrollers.html
[2] http://www.arduino.cc/playground/Code/BitMath
[3] http://iamsuhasm.wordpress.com/tutsproj/avr-gcc-tutorial/

My code’s here:
https://github.com/nouyang/pov-yoyo
and I’ll run over some things I hadn’t found clearly explained here.
0x designates hexadecimal, while 0b designates binary. These are fixed flags, similar to a plus or minus sign in front of a number. The actual values that matter come afterward.
So 0b0010 translates to, in decimal, two. And the compiler will assume that there are infinity zeros to the right (well, until ’till the size of the variable or constant at least, eg 0b00000010 for a byte = 8 bits), just as in decimal “2” and “00[…]002” are equivalent.

#define LINE_A 0
#define LINE_B 1
#define LINE_C 2
 

//DDRB direction config for each LED (1 = output) //in or output
const char led_dir[6] = {
  ( 1<<LINE_B | 1<<LINE_A & ~(1<<LINE_C)), //LED 0
  ( 1<<LINE_A | 1<<LINE_B & ~(1<<LINE_C)), //LED 1
  […]
};
 

//PORTB output config for each LED (1 = High, 0 = Low) //hi or lo
const char led_out[6] = {
  ( 1<<LINE_B & ~(1<<LINE_A)), //LED 0
  […]
};

What do these lines mean? Well,
1 << LINE_A means 1 << 0 according to the #defines : This means “put a 1 shifted over 0 bits”, aka 0b1 or 0b00000001
1 << 1 : 0b10, or 0b00000010
The “|” means bitwise OR, aka I add the two numbers together to get
0b00000011 — that is, DDRB pins 1 and 2 are both outputs and everything else is in high impedance mode. To be safe, since I am using 6 LEDs on 3 pins

3 Pin Charlieplexing.png
http://en.wikipedia.org/wiki/Charlieplexing for more info

and therefore cannot have uncertainty about whether the unused pin is in high impedance (input) mode or output mode, I explicitly state with
& ~(1<<LINE_C) that pin 7 (on the attiny45, see datasheet which tells me that pin7 corresponds to index 2 on DDRB — hence #defines LINE_C 2) must be in high impedance mode.
See [1] for an explanation of what & ~(a 1 at the appropriate index)
I’m not certain this is necessary, since in my case I explicitly say “DDRB = 0b011” later in the code rather than saying “DDRB |= 0b011” which would have left high any unspecified pins that were originally high, but I’d rather put it in here than risk wondering if my bugs are because of this.

Thus, an equivalent led_dir array could have said led_dir = {0b001, 0b011, […]}.

C Resources:

My code 

is based off of:

Charlieplexing code:

Most PoV code appears to be in asm:

Crazy compiler bugs, AVR Studio’s avr-gcc commands explained, and makefiles

[Edit: solved, the error was in the fab hello world makefile line
$(OBJCOPY) -j .text -O ihex $(PROJECT).out $(PROJECT).hex
To fix, add -j data or drop the -j option altogether)
See http://www.micahcarrick.com/avr-tutorial-digital-output.html. also, man avr-objcopy.
What was actually happening was in one example the compiler replaces the code with the array data and then loads it into the microcontroller, while for the other example it loads the compiled code into the micro, and in both cases the constant array never makes it into the microcontroller.]

The surface symptoms of crazy compiler bug which appears to eat variables (NOT an optimization issue! — check out this awesome thread for more about that http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=97382 )

Me: I’m getting bugs where the exact symptom in simplest form is

=========
void light_led(char led_num) {
   DDRB = led_dir[2];
   PORTB = led_out[2];
}
void main(void) {
   while (1) {
      light_led(2); //obviously I am ignoring the argument given here
   }
}
=========
works as expected but
=========
void light_led(char led_num) {
   DDRB = led_dir[led_num];
   PORTB = led_out[2];
}
void main(void) {
   while (1) {
      light_led(2);
   }
}

=========
doesn’t. (tested and doesn’t work: char, volatile char, int and now int8_t and uint8_t).

Based on this code: https://github.com/benbrandt22/TinyLife5/blob/master/TinyLife5.c
(full file here: https://github.com/nouyang/pov-yoyo/blob/master/v0.1.45.c)

Yes, I tried int instead if char in case C arrays wanted int indices. And volatile char in case the compiler was like “You, variable! You are a useless waste of memory. OPTIMIZED.” (sfx notes: that should sound like RECTIFIED in Tron).

Okay, so why doesn’t AVR Studio 5 Debugger work?

Turned out AVR Studio debugger is straightforward, but it doesn’t work if you have a

void main (void) {}
function instead of a
int main … (return 0; )
function.

Also, AVR Studio 5 is amazing. I can peer at all the DDRB and PORTB and all the pins — even with an oscilloscope I would need like 8 arms to do this.

Oh right, back from worshiping AVR for making AVR Studio freely available (the Gobsmacking Glory of which is only slightly diminished by my sadness that it’s not open-source / doesn’t run on linux (haven’t tried WINE yet)) and on to compiler issues.

Re: linux avr toolchains, Pranjal Vachaspati, hallmate and 2014, in yet-another-spam-thread-I-started, writes:

If you’re using AVR eclipse (and I strongly recommend you do, as AVR development has way too many steps to comfortably manage manually), make sure you change the build target from “Debug” to “Release” or else it won’t create the appropriate binary. Also if you’re not using AVR eclipse it’s awesome! http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin

In the meantime, I will continue my terrifying toolchain of Desktop > AVR Studio > Compile > attach *.hex file to email > Netbook > download file > run avrdude > Debug in AVR studio > … =/ Maybe AVR Studio works with Wine.

I grabbed the avr-gcc commands from the terminal output at the bottom of AVR Studio 5, edited the filenames, and used it to compile C code on ubuntu. (Note that choosing “Release” uses -Os, full optimization, while choosing “Debug” uses -O0, no optimization. For my code this results in 3 kilobytes flashed versus 150 bytes! — 3kb = almost 90% of available mem on attiny45)

I’m writing some C code for the attiny45 microcontroller for how to make anything,  and I’m debugging a problem where for the exact same C code,  AVR Studio creates a happy .hex file but the class-derived makefile creates a “I’m-going-to-half-work-and-drive-you-crazy-debugging” .hex file (see C code above for the symptoms).

 ~~~AVR Studio commands
avr-gcc -funsigned-char -funsigned-bitfields -Os -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99  -mmcu=attiny45   -MD -MP -MF”v0.1.45.d” -MT”v0.1.45.d” -o”v0.1.45.o” “v0.1.45.c”
avr-gcc -mmcu=attiny45  -Wl,-Map=v0.1.45.map -o v0.1.45.elf  v0.1.45.o
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  “v0.1.45.elf” “v0.1.45.hex”
avr-objdump -h -S “v0.1.45.elf” > “v0.1.45.lss”
avr-objcopy -j .eeprom –set-section-flags=.eeprom=alloc,load –change-section-lma .eeprom=0 –no-change-warnings -O ihex “v0.1.45.elf” “v0.1.45.eep” || exit 0
avrdude -p t45  -c usbtiny -U flash:w:v01.45.hex
~Results  as run on Ubuntu 11.10 in 435 bytes .hex file / 146 bytes flashed. And results in a bunch of magical files.

~~~Class-derived Makefile
avr-gcc -mmcu=attiny45 -Wall -Os -DF_CPU=8000000 -I./ -o ./v0.1.45.out ./v0.1.45.c
avr-objcopy -j .text -O ihex ./v0.1.45.out ./v0.1.45.c.hex;
avr-size –mcu=attiny45 –format=avr ./v0.1.45.out
avrdude -p t45  -c usbtiny -U flash:w:v0.1.45.c.hex

~Results as run on Ubuntu 11.10 in 443 bytes .hex file / 150 bytes flashed. (it takes up more memory and it doesn’t work right! :/)

So, I emailed out to the MAS.863 and one of the TAs promptly spent almost an hour writing an essay in reply. o__o Yay awesome people. Directly copied:

Brian Mayton (bmayton):

Here’s what some of this means.  First, starting with the compiler command (avr-gcc).

> avr-gcc   -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums

The -f options change the behavior of the compiler.  -funsigned-char tells it that the ‘char’ type is by default unsigned (that is, cannot represent negative numbers, but can store numbers twice as large.)  Normally in C ‘char’ is signed, and if you want an unsigned one you have to say ‘unsigned char’.  This flag swaps it around, so that ‘char’ is unsigned by default and you have to say ‘signed char’ if you want a signed one.  Generally, when writing microcontroller code, I very much prefer to be explicit, never assuming what the compiler is going to do.  <stdint.h> is part of the C standard library and defines types like ‘uint8_t’ (an unsigned 8-bit integer, same as ‘unsigned char’) and ‘int8_t’ (a signed 8-bit integer, same as ‘signed char.’)  I prefer these over the char, short, int, long types because I know exactly what I’m getting.

-funsigned-bitfields says that bitfields are also unsigned.  If you don’t know what bitfields are, you’re probably not using them.  (Most code for avr-gcc doesn’t use them.)

-fpack-struct says that all structs should be packed.  (Look up C structs if you’re not sure what these are.)  On some processor architectures, memory is addressed a ‘word’ at a timeβ€”on a 32-bit x86 processor, for example, a word is 32 bits (or four bytes) long.  The instructions for accessing a word of memory tend to be faster when the word being accessed is ‘aligned’ to a word boundary, i.e. its address in memory is a multiple of four bytes.  In a struct, if you were to have, for example, three fields that were each one byte long (uint8_t), and then one field that was four bytes long (uint32_t), and the beginning of the struct is aligned to a word boundary, then the 32-bit variable won’t be, and accessing it will be slower than if it were.  So sometimes the compiler will insert ‘padding’ to make sure that all multi-byte fields in a struct are aligned to word boundaries; in this case, it might insert one byte of padding in between our three single-byte variables and the four-byte variable to push it over onto the word boundary.  Telling the compiler that a struct should be ‘packed’ tells it *not* to insert this padding.  On a microcontroller with limited memory, you might prefer the slower access to unaligned fields to the ‘wasted’ memory that padding creates, or if you’re implementing a network protocol that needs the fields to be at specific locations.

-fshort-enums tells the compiler that enums (again, look this up if you don’t know what they are) should be stored as a ‘short’ rather than an ‘int’.

My guess is that it’s likely one of the above flags that makes your code work, but without seeing your code I couldn’t say for sure.

>   -Os

This sets the optimization level.  -Os means that the compiler should optimize to make things faster, but try to produce the smallest program possible.  -O0 means don’t optimize, -O1 means some optimizations, -O2 enables more optimizations, and -O3 turns on optimizations that might also result in a larger program. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=71862
http://www.societyofrobots.com/member_tutorials/node/207
>   -g2

This tells the compiler to include debugging information in the code it generates; if you use a debugger later, it uses this information to map between which instruction in the compiled program corresponds to which line of the C files.

>   -Wall

This tells the compiler to enable all warnings.  There are some warnings that aren’t enabled by default (such as you defined a variable but didn’t use it, there’s nothing wrong with that, but it might be a mistake.)  This can sometimes help point out programming bugs that compile fine but might not be what you meant to write.

>   -c

This tells the compiler that it’s going to build an object file instead of a complete program.  Object files contain compiled functions, but they’re not yet ‘linked’ together into a complete program.  When you use a C compiler, one way to do it is to just give it all of your C files at once and have it produce a complete program all in one go (this is how Neil’s example Makefiles do it).  In more complex programs, it’s often useful to produce the intermediate object files first, and then link them together into the complete program at the end.  If you have lots of .c files, and only change one, then you only need to rebuild the .o object file corresponding to the .c file that changed.  For a big project with lots of code, that can be faster.

You can read more about what ‘compiling’ and ‘linking’ mean (lots of info online) if you want to get a better understanding of what’s happening.

>   -std=gnu99

This tells the compiler to use the GNU99 standard.  There are a couple of different variants of C.  There’s ‘ANSI C’ or C89 (the ’89’ corresponds to 1989, the year the standard was ratified.)  C99 is a newer revision to the standard that adds some extra features to the language (like being able to declare varaibles at other places than the top of a block.)  GNU99 adds in a handful of GCC-specific extensions.

>   -mmcu=attiny45

This, of course, tells the compiler what processor to produce code for.

>   -MD -MP -MF”v0.1.45.d” -MT”v0.1.45.d”

These are all dependency-tracking options, that tell the compiler to save information about which header files are used by each .c file, which can be used later to determine, if a header changes, which source files need to be rebuilt.  This is useful for large projects, but not terribly useful for small microcontroller stuff.

>   -o”v0.1.45.o”

This specifies the output filename.  Usually the convention for object files is whatever the name of the .c file was, but with .o instead.

>   “v0.1.45.c”

And finally, this is the .c file to compile.  And that’s it for the compilation step.  If you had multiple .c files in the program, this would be repeated for each one.

Now, the linking step:

> avr-gcc -mmcu=attiny45  -Wl,-Map=v0.1.45.map -o v0.1.45.elf  v0.1.45.o

This also uses the avr-gcc command, but since there’s no -c flag, it’s going to build a complete program instead.  The linker will take all of the object files (in this case, only one) and assemble them together into a complete program, figuring out where everything fits in memory.  The object files have ‘notes’ in them that say things like ‘here I want to call function foo()’; it’s the linker’s job to decide where function ‘foo()’ is actually going to be in memory, and replace that ‘note’ with the actual address for the program to jump to.  The -Wl,-Map= flag tells the linker to also produce a file that says where it’s putting things, which can be helpful to reference when debugging sometimes.

The -o flag, like before, specifies the output file; for a complete program, this will be in ‘elf’ format.  (This is a standard format for executable programs, you can read more about it if you want.)  Finally, a list of all of the .o files to include in the program follows (in this case, again, we only have the one.)

Now some objcopy/objdump stuff:

> avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  “v0.1.45.elf” “v0.1.45.hex”

Mostly for historical reasons, a lot of programming tools won’t read an elf file directly.  Customarily, the file format that’s used is Intel HEX (ihex, or simply .hex.)  (Some embedded systems also use Motorola S-record or srec files).  The objcopy command here is basically copying the compiled code from the elf file into a hex file.  It’s told (via the -R flags) to ignore the .eeprom, .fuse, .lock, and .signature sections (so this hex file will basically only contain the program code, or the .text (in executable parlance, ‘text’ often means compiled code) section.)

> avr-objdump -h -S “v0.1.45.elf” > “v0.1.45.lss”

objdump here is generating a file with the disassembly listing of the compiled program.  This is completely unnecessary to generating working code, but sometimes looking at the disassembled program to see what instructions the compiler generated can be a useful debugging tool.

> avr-objcopy -j .eeprom –set-section-flags=.eeprom=alloc,load –change-section-lma .eeprom=0 –no-change-warnings -O ihex “v0.1.45.elf” “v0.1.45.eep” || exit 0

Finally, this is creating another hex file that would contain any ‘.eeprom’ section you defined in your program.  You’re quite likely not using the EEPROM on the chip, and don’t need this.

That ended up being a bit long-winded and I went off on a few tangents, but maybe that helps a little?

Also, perhaps the reason why avr-gcc install with neither manpages nor info files is the length of the avr-gcc manual: http://linux.die.net/man/1/avr-gcc

=====
Then my email to my hall course-6 list sidetracked into a rant about makefiles. The main takeaway was that to learn about makefiles I should read the GNU Make manual.
http://www.gnu.org/software/make/manual/make.html

Here’s the gist of the email thread, if it’s interesting to others:

Marti Bolivar (of leaflabs! http://leaflabs.com/ yay open source hardware startups):

if at any point, you find the experience of writing a nontrivial
makefile akin to swimming upstream in a river of tepid molasses, don’t
despair. that is the expected behavior. make sucks, that’s life :(.

if your class requirements don’t forbid it, you may wish to try scons
(http://www.scons.org/) out.

RJ Ryan (of open-source DJ software mixxx http://www.mixxx.org/ and mobile health Sana Mobile http://sana.mit.edu/) says:

SCons is good for projects where everyone knows Python. If nobody knows Python, it’s a really terrible idea. πŸ™‚ Just look at Mixxx’s SConstructs. I’ve attempted to bring some sanity to them, but they’re mostly crap.

And that’s only like 70% of the SCons files we have. After dealing with this long enough, I coined this addage: Give a person a turing-complete build system and they will find a way to club a baby seal.

In my experience, you have two options if you are stuck with make:

1) Spend years learning by example and eventually understand most of what is going on but still be utterly confused 10% of the time (e.g. dealing with autoconf-generated makefiles).

2) Spend a couple hours reading the GNU make manual straight through. Everything will make a lot more sense.
http://www.gnu.org/software/make/manual/make.html

Reid Kleckner writes:

Build systems are like the ultimate doomed project area.  There are so many systems that reinvent the wheel in slightly different ways and don’t provide a bulletproof solution for everyone.

Every user has completely different requirements and is always migrating from some other system where xyz was easy, and so they just grow and grow features that make them incomprehensible at the end of the day.

Projects in this area that haven’t solved all your problems yet:

  • make
  • autoconf/automake
  • cmake (we use this for DynamoRIO and DrMemory)
  • Boost’s jam
  • jom
  • eclipse
  • visual studio
  • ninja
  • scons
  • rake
  • BSD make
  • Ant
  • Maven and all the *other* Java build systems
  • gyp (we use this for Chrome, go NIH)
  • the new LLVM build system ddunbar proposed

It’s just…  I ** hate build systems.  They all suck.  They’re too slow, don’t run on platform x, can’t crosscompile, mess up the deps so you have to do a clean build…

Maybe we ask too much of them. 

marti picks up on the topic of turing complete baby seal clubbers:

relevant:

http://lambda-the-ultimate.org/node/85

also:

http://cmcrossroads.com/ask-mr-make/6504-learning-gnu-make-functions-with-arithmetic

that second one reminds me of duff’s quote about his device (with respect to whether fall-through was ok), “This code forms some sort of argument in that debate, but I’m not sure whether it’s for or against.”

 then perry huang, some hall alum I have never met I think:

from the creator of make:

“Why the tab in column 1? Yacc was new, Lex was brand new. I hadn’t tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed.  And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn’t want to screw up my embedded base. The rest, sadly, is history.”– Stuart Feldman

So yea. I’m waiting for when microcontrollers get so powerful and cheap that I can run python on them. >__> <__<

How to design pcbs to fit CAD models (not solved well)

How to fit design pcbs to fit CAD models, specifically how to interchange between eagle and solidworks in 2d (copy pasting from my email b/c I’m too lazy to reformat):

Me: if I want to make a board in eagle which fits inside a shape that I have a solidworks model of (I only care about 2d for now). It’s pretty straightforward, so I can do the oldskool from x1 to x2 thing, but what if it were more complicated? Is the only way to do this export an image in solidworks and make a library part of it, or use some import_bmp script and trace over it in eagle, or something crazy? I guess the opposite is easier, show only the board, export image, import into solidworks, and trace it… What if I cared about 3d? Is eagle just have zero support for this?

Charles Guan:
Also, if you want to make a board of a certain shape in Eagle, it’s a terrible pain. I was in fact just messing with this tool yesterday:
http://www.micromagicsystems.com/#/dxf-converter/4523812840
What I did was make a solid model of the plan of the board (sketch > extrude), then laid it out in a DXF drawing as if I were waterjetting it. If you just export a sketch as a DXF you have to exclude things like dimensions. The tool just imports every DXF entity into the .brd file on the Dimension layer.
Example board outline: http://etotheipiplusone.net/pics/moter/nicesensor3.png

If your board has internal slotting and stuff it will import that too.

John David Cranor:
cross platform one: http://fab.cba.mit.edu/classes/MIT/863.09/people/cranor/How_to_Make_%28Almost%29_Anything/David_Cranor/Entries/2009/11/16_Week_9__Output_Devices_files/DXF2SCR.C

In 3d, I have no idea, but check out this post:
http://sketchupdate.blogspot.com/2011/09/visualizing-circuit-boards-with.html
If only Sketchup were parametric…

You can poke the eagle file on github (https://github.com/nouyang/pov-yoyo > eagle-board > .brd) and see that I simply drew a rectangle starting at the origin and then set the x2 and y2 coordinates according to the 2d solidworks measurements. For my prototype, I didn’t even end up using that board outline — I sheared off the excess copperclad and sanded* the pcb where my shearing was file until the pcb fit inside, and then used rolled up masking tape to keep it in ‘cos I sanding failed past pressfit tolerances.

* I was using FR1, not FR4, so sanding was fine.
FR1 versus FR4 copperclad:
The copper-clad we use in MAS.863 is FR1 Phenolic Paper, instead of the standard FR4 Epoxy Glass which is what you’ll probably find on ebay if you search “pcb copperclad”. Tiny particles of glass in the air make your lungs sad and result in increased cancer risk over time, so if you’re milling boards or sanding them a lot you want to go with FR1. There are disadvantages which make FR4 preferred for Real Boards which are fine for DIY boards — fr4 has less heat tolerance, delaminates easier, and cracks more easily — see http://www.electronicspoint.com/paper-phenolic-pcb-t136758.html).
(For more info, see http://en.wikipedia.org/wiki/Printed_circuit_board;
for our fr4 supplier, see http://academy.cba.mit.edu/classes/electronics_production/index.html)

=====
Yes, I’m splitting my giant!update for today into 3 posts.
=====
(p.s. if you don’t know what eagle is, it’s free pcb layout software,  older version layout tutorial:  http://www.sparkfun.com/tutorials/109
schematic tutorial: http://www.sparkfun.com/tutorials/108
more resources (including eagle libraries) here: http://academy.cba.mit.edu/tutorials/eagle/eagle_resources.html,
and the list of parts for fab.lbr: http://fab.cba.mit.edu/about/fab/inv.html)

Thanks to Bayley Wang for being the first to show me how to use Eagle.

PoV Yoyo, charlieplex+pov (attiny45, 6 LEDs/3 pins) research

[edit, 6 dec 2011, see update for semi-working-ness: http://www.orangenarwhals.com/?p=161]

board layout

mmm, fab’d a terribly board together for persistence of vision yoyo so now I can start on code.

charlieplex and basic hello world rgb led, c, attiny44 and 45 respectively

C cheat sheet

eagle brd and sch on github
charlieplexing with arduino libraries
hello world
olopede code (not charlieplexed)
https://raw.github.com/zbanks/muffinc/master/code/upov/main.c
tom’s nanopov code (charlieplexed, in assembly)
ladyada code
gui gode, attin2313, has gui
assembly: avr instruction sets
led documentation
mmm instructables (attiny85, charlieplexing)
my own notes on make commands
==
real time clocks (for hat alarm clock)

more pov yoyo cost research

scale of 50 yoyos. project will be working on over the next month by dan fourie, laura shumaker, and I as a for-fun project spawned out of an idea my for-grades 2.008 team passed over.

functional parameters:
yoyo with integrated persistence-of-vision display

design parameters:
as of right now, for each side:

  • 5 LED display, similar to (josh gordonson and zach banks, fellow mit students) earlier work: 
http://olopede.com/media/img/micropov-hand.JPG
  • Goals: user-friendly and mod-friendly
  • Two buttons, high enough that can be accessed by pressing down on the clear thermoformed plastic cover over the circuitboard (similar to plastic water bottle in feel)
    • on/off power button(decided against the centrifugal switch designed by paulina mustafa, another classsmate, for their iron man arc reactor yoyo, because gives user option to operate pov-display without spinning the yoyo for a more stable display)
    • “change text displayed” button, and you can change the display by holding it up to your monitor ala http://fab.cba.mit.edu/classes/4.140/people/robert.hemsley/week8.html. This method means the user doesn’t need to have special cables to change the displayed text, and we don’t need a complicated / non-intuitive button interface.
    • http://tomscircuits.blogspot.com/2009/04/micro-pov.html
      http://parts.digikey.com/1/parts/389604-8-pin-test-clip-alloy-soic-15-923650-08.html 8pin: $14, 14pin: $17
      • if we order pcbs, can have holes for people to stick FTDI or ISP headers in, so people don’t need to solder little wires straight to the microcontroller if they want to edit or update the firmware on the ucontroller (or make a clamp breadboard) or buy one of the clamp programmers 
      • can have another mode (hold down button longer?) to change the flicker rate, since we’ll be using internal microcontroller clock which is RC and due to manufacturing variability only accurate to +- 10%
      • discarded option: right-angle button which sticks out side of yoyo. more complicated injection molds and I was worried if it’d be structural enough, since solder joints would be taking the strain. Seemed most likely to fail after repeated use.
  • PCB should snap fit in, so people can mill their own pcb’s and swap out the pcb if wanted
  • Rectangular PCB should fit, so it’s easier to panelize and easier for people to make their own board (can etch and shear off one side instead of having to have a mill and mill a circular board, although circular boards look cool .___.)
  • Ideally PCB is single-sided
  • run off a 3v button cell and contain a spare so people can go longer without ordering their own.
    • pcb serves as cell-holder, batteries should snap fit in to further simplify mechanical design
    • TODO not sure how batteries will be electrically connected to the board
  • for changing the battery / updating the firmware, top half of each side will be removable via a notch on the side
  • assembly: teach a microcontroller series and have people assemble two and keep one?

–maybe have a fourth state changing the flicker rate, in case a specific microcontroller’s clock is off (on/off/text programming/flickr rate programming)

cost estimate: 
$4.30 for two attiny85’s off of digikey, + shipping. || $2.96 for each attiny88 ($6).
cheap power-hungry LED, well.

Circuit: Shane’s interior-routed circuitboard

(http://scolton.blogspot.com/2011/10/strobe-attack.html) cost ~$50 + shipping for 12 of them off of myropcb. Ladyada has a cost calculator for multiple suppliers and comments for each supplier: http://www.ladyada.net/library/pcb/costcalc.html
That’s like $12 for each yoyo.

So uh… Maybe instead I will sink $80 into buying my own 1/64” and 1/32” spindles for the modela (each good for ~50 boards).
$2 per yoyo
ebay: $25 for 3x 9” by 12” FR4 board. Est.: our boards max 2” diam, so 1.5” square is 6×8 = 48 boards. So maybe $50 for 96 boards, or about
$1 copperclad per yoyo

Buttons:
75c ea @ 100 off of digikey. http://search.digikey.com/us/en/products/B3SN-3112P/SW262CT-ND/60835 (need 200). or ebay, 100 for $7 incl shipping. $14 / 50 = 30c per yoyo. but late shipping…! may be too late for the semester
$3 per yoyo.


phototransistor: 28c each @ 100.
$1.20 per yoyo.


10k resistor, 50kohm, 5x zero ohm, 4x 500 ohm, 1uF cap.
14c each @ 100, cap http://search.digikey.com/us/en/products/C3216X7R1H105K/445-1423-1-ND/569089
0.017 @ 100, 10k, 50k http://search.digikey.com/us/en/products/RC1206FR-0710KL/311-10.0KFRCT-ND/731430 http://search.digikey.com/us/en/products/RC1206FR-0749K9L/311-49.9KFRCT-ND/731890
0.01292 @ 250, total 400 needed, 500ohm http://search.digikey.com/us/en/products/RC1206FR-07499RL/311-499FRCT-ND/731891
total 500 needed
0.00676 @ 500, total 500 needed, zero ohm
(this is if pov circuit does NOT need any resistors etc. ala , these are all for voxel light-programming)  http://fab.cba.mit.edu/classes/4.140/people/robert.hemsley/week8.html
total = .14*2 + 0.017*6 + 0.013*4 + 0.007*5 = 0.469
About 50c per yoyo. these are all 1206 packaging!

CR927, 4 batteries each, 200 total: $22 http://www.ebay.com/itm/200-CR927-DL927-LM927-ECR927-KCR927-927-Cell-Battery-E2-/180756330972?pt=US_Batteries&hash=item2a15eab9dc#ht_2063wt_1163, 30 mAh, used in blinkies
44c ea. yoyo
(alternative: rechargeable ones, $1.44 ea 55 mAh TINY 6.8mm diam http://octopart.com/ms621fe-fl11e-seiko-8119587, with solder tabs: $1.29 ea 48mAh 12 mm diam http://octopart.com/br1225-1vc-panasonic-155413, $1.71 550mAh 23 mm diam http://octopart.com/cr-2354%2Fgun-panasonic-13183344
octopart search: http://octopart.com/partsearch/#search/requestData&q=lithium+battery&rangedfilters%5Boutput_voltage%5D%5Bmin%5D=1.5&rangedfilters%5Boutput_voltage%5D%5Bmax%5D=4.9945883802956885&rangedfilters%5Bavg_price%5D%5Bmin%5D=0.24250000000000002&rangedfilters%5Bavg_price%5D%5Bmax%5D=1.8412916540799584&start=10)

accelerometers 0.67 ea @ 100, http://search.digikey.com/us/en/products/MMA7660FCT/MMA7660FCT-ND/2186165, as used by

http://rucalgary.hackhut.com/2011/04/26/upov-with-better-firmware-pics-video-and-source/
Indeed mill-able on the modela — http://www.freescale.com/files/sensors/doc/data_sheet/MMA7660FC.pdf 0.5mm gap, 0.3mm pad — DFN package
25 mil pins (15.6 mil gap and 10 mil pad/trace) — for modella, can achieve. aka 0.398 mm gap / 0.254 mm pad

$1.40 per yoyo

unless I figure out how to make accelerometers — see http://www.dimensionengineering.com/accelerometers.htm, and the borked link is J. Doscher, Innovations in Acceleration Sensing Using Surface Micromachining http://www.analog.com/en/mems-sensors/inertial-sensors/adxl202/products/technical-articles/CU_ta_Innovations_in_Acceleration_Sensing/resources/fca.html
— I’ll just pre-program the flickr rate (and make it adjustable via the light-serial-programming protocol?)

total: $15 per yoyo + some digikey shipping costs, so close to $17 each if we count the aluminum molds and injection molding / thermoforming raw mats as free (due to 2.008). and of course free labor XD

=====
Previous research:
LEDs
If we use those super-efficient LEDs, they are 30c each if we buy 400 (50 yoyos * 8 = 400 LEDs).
(http://www.newark.com/jsp/search/productdetail.jsp?SKU=38K3409&CMP=AFC-OP&CMP=AFC-OP via http://octopart.com/partsearch/#search/requestData&q=Kingbright%20KPTD-3216SURC)
x8 = $3 (if we include shipping)
Total = $118 + $10 shipping (so upward bound of $130)
So, about $2.60 per yoyo

3V Batteries — batteries are somewhere around $15 / 100 on ebay w/ free shipping, so $0.30 per yoyo)
 if we want them (I don’t think we do, we should design this into our mold or PCB) holders would be $1.50 each http://octopart.com/partsearch/#search/requestData&q=cr2032

Microcontroller ~$1.50 each http://octopart.com/partsearch/#search/requestData&q=attiny25, maybe $10 for shipping, aka $1.70 per yoyo

Here is how the “spin-activation” would work:
http://cdn.makezine.com/make/2010/06/WP105LEDYo-Yo.pdf

So, at 50 yoyo’s, we’re looking at $6 each which is over our budget. However, I’m confident if we look a bit harder we can get the prices down to $5 each.

=====

Timeline:

Thursday: [everyone] finish the CAD for the molds
Friday: [nancy] check the dims / tolerances with Pat and Dave
Then CAM over the weekend Saturday, say meet for dinner on putz @ 5pm and then CAM (putzgiving is Sunday). Order electrical parts.
Hopefully mill / turn the molds over Mon – Wed before thanksgiving.
Finish electrical design -> gerber and programming over thanksgiving break and order pcbs if ordering them. by 26th
And injection mold / thermoform the week after (done by Friday December 2nd).
Assembly done by Dec 9th.

=====
PoV no accelerometer notes:
I got nanopov example working this weekend — no accelerometer indeed means there’s an optimum speed the display wants to be waved at. wave it too fast and the image gets stretched out, too slow and the whole image isn’t displayed or it’s super-squished.

Oh, Tom went over this in his blog post:

One downside of this design is that there is no synchronisation between movement of the display and the display output. So if e.g. you wave it left-right-left all output is mirror-inverted half the time. Also, there is no stable, repeating image as you would get from a constantly rotating POV.

centrifugal switches (spin activated yoyo electronics)

doing some research for 2.008 instead of freaking out over 6.131 lab

Edit 10/17/2011: Found it! Thanks to Charles.

See explanation of “tilt sensors,” which include both mercury and rolling-ball type ones, here: http://www.ladyada.net/learn/sensors/tilt.html

http://www.adafruit.com/products/173

Cost: $2.00.
(octopart search: http://octopart.com/partsearch/#search/requestData&q=tilt+switch&rangedfilters%5Bavg_price%5D%5Bmin%5D=0.54&rangedfilters%5Bavg_price%5D%5Bmax%5D=2 can maybe get it for $1)
http://smparts.com/-Switches-Rolling-ball-switches-%28AT%29/c0_2_561/index.html — but no prices listed, hah.

Hmm. So I know there was at least one previous design in 2.008 that used these switches. They put two on each side (top and bottom), facing outwards. Then, when the yo-yo spun, both switches would contact (and presumably switch on LEDs). Apparently they had issues with the thermoform shrinking and squeezing the ball switch and preventing it from switching though. All in all, I’m a bit iffy about these rolling ball switches. There’s no way to adjust their sensitivity (although I guess regardless PoV yoyo requires a microcontroller anyway, but the less pin-count the better), so what if it switches on when the the switches are rotated to (left right) and the yo-yo is slightly tilted? We’d be stuck with 100 useless switches.

I like Paulina Mustafa’s design of a flexure switch, she was prototyping this at MITERS (but I can’t find a blog for her). Looks sort of a like a ying-yang design, and the tips are flung outward and make contact with the sides when the yo-yo is spun. She’s using copper-tape, but I think something like conductive glue would be easier to apply.
http://www.instructables.com/id/Conductive-Glue-And-Conductive-Thread-Make-an-LED/step1/Make-Conductive-Glue-Conductive-Paint-and-Conduc/

=====
Earlier Research

via
http://www.helifreak.com/showthread.php?t=33567 “DIY Night Blades”

centrifugal switches:
http://www.atomicmods.com/Categories/Tutorial-1-28-Mini-Z-Rim-Light-Installation.aspx
(spring inside a brass tube)

The batteries are wired in series with the LED and the centrifugal switch. The centrifugal switch is simply a tiny spring inside a brass tube. When you accelerate, the spring swings to the outside and makes contact with the brass tube turning on the lights. It is really quite simple and very reliable. This also makes the batteries last a long time since they are only on while you are driving and you will never forget to turn them off.

types of switches and design of switch contacts (including mercury switch aka “tilt switch”): http://www.allaboutcircuits.com/vol_4/chpt_4/1.html

quora question
http://www.quora.com/Mechanical-Engineering/What-centrifugal-switches-are-suitable-for-use-in-a-yo-yo

still failing to find suppliers o.o

mercury switch:
http://mondo-technology.com/yoyo.html

paperclip style:
http://www.make-digital.com/make/vol22?pg=115#pg117

Ideas: PoV Yoyo, Press-fit food || Classes, Spring 2011

Mmmmm…. classes.
Started out with:
2.008 (Make a yoyo)
6.131 (Power electronics)
6.042 (Math for CS majors)
6.003 (Signals and Systems)
6.004 (Computation Structures)
Some HASS class

Now:
2.008 (Make a LED persistence of vision yoyo)
6.131 (Power electronics)
MAS.863 (How to make almost anything)
21M.611 (Foundations of Theater)
Possibly either 6.003 or 6.004, still.

In other words, I was ecstatic when I heard I got into MAS.863 and that flipped me in favor of not double-majoring in 2 and 6 (unless I decide to take an extra semester or something).

==mas.863==
Our first assignment:

Trying to think of interesting new ideas, I thought of pressfitting food (sparked by my interest in etching poptarts for nyancat poptart). The hunt for a suitable material is on…
Gingerbread recipe: http://homecooking.about.com/od/cookierecipes/r/blcookie111.htm
Other house-building person: http://web.mit.edu/newsoffice/2008/arch-sass-0703.htmlhttp://cba.mit.edu/events/10.08.FAB6/Sass.pdf
Other materials guy: http://web.mit.edu/bin/cgicso?options=general&query=bredt came up with powder solution for 3d printing

(Other people’s projects, which overlapped with some of my other ideas:

General Prettiness:

===2.008===

In the meantime, I’ve also been ignoring the present day and contemplating the near future of 2.008. I think we’re supposed to be making paperweight designs or something, but my partner is a but hard to contact, so I’ve fallen back on daydreaming about LED persistence-of-vision yoyo’s. Doesn’t seem to have been done already, surprisitngly. And now for linkspam research:

PoV
Other products

DIY
Yoyo

2.008 Yoyos
In order of awesomeness / completeness of online documentation:

Youtube videos:
==misc.===
RFID tags idea: oohh, someone in a previous 863 class had a similar idea for not forgetting things. Or rather, exact 
passive, duct tape + magnet wire: http://scanlime.org/2011/05/duct-tape-rfid-tag-1/