Julia Makes Things

Composites

Wed, 06 Dec 2017 00:00:00 -0500

Assignment: Design and fabricate a 3D mold and produce a fiber composite part in it, with resin infusion and compaction.

Having fallen behind on last week’s assignment, and now turning my attention primarily to my final project, this week is going to be simple and project-oriented. So I’m going to make a ramp/obstacle for my robots to climb over. Currently I’m testing the robot’s ability to overcome obstacles by taping together cardboard and sticking it to my desk.

I made this nice little diagram of the parts that go into composite making (in this case, for a closed mold that I can compress with clamps). On top of the bottom layer of the mold, we use multiple layers of plastic cling wrap as a release so the composite won’t stick to the mold. (It’s multiple layers in case some of the epoxy oozes through at least one layer.) Then comes the composite itself. In this case, it’s wet layup, so each fiber piece is coated in wet epoxy and stacked up. Then comes a bleeder layer to let up excess epoxy. Here, that’s plastic wrap with holes punched in it. Then a breather layer to soak up that extra epoxy (polyester quilt batting), and finally another layer of plastic wrap for mold release. Then the top of the mold goes on and you clamp it while it cures.

First up: mill the mold out of foam insulation. I was limited in how tall I could make the ramp by the thickness of the insulation (2”) and the endmill length (about 1.5”). Bonus: I actually remembered how to use VCarve and the ShopBot! I made a very simple CAD model of the ramp in OnShape. I subtracted it from a block to create the top mold and added it to a block to make the bottom mold.

It’s snowing! The milling made so much insulation dust. It looked pretty cool, but it was a pain to clean up. I’m sure that also helped my never-ending cough.

It’s a good thing I didn’t make the ramp any taller than I did, because it was an incredibly tight fit between the surface of the foam and the collet. Though it turns out the foam doesn’t damage the endmill, as I discovered when I tried to do an aircut and accidentally lowered it from my zero by 2” instead of raising it. (This is why we can’t have nice things.)

The molds came out really nice. I made sure the finish cut followed the slope of my ramp for a smooth finish, but I’m pretty sure it won’t matter because the composite process isn’t nearly the level of precision we’ve had in some things. When I tried to fit my mold pieces together, the convex piece was just a little too wide to fit it. I sanded down the sides until it was a slightly loose fit, so that there would be room for cling wrap as my mold release.

For the fiber in my composite, I used what’s essentially fancy burlap, optimized to have the right fiber density and thicknes to work well with the resin. I didn’t have to do anything fancy to cut these pieces because I only have curvature in one direction. I cut strips of the fiber to the width of my ramp, then cut them to slightly longer than the length of the ramp surface. (I figured it was better to err long than short; I can always trim it afterwards.)

Making the bleeder layer was weirdly satisfying. I laid my plastic wrap on the quilt batting and ran over it with this… thing. It looks like a torture device. I don’t know what its original intended purpose is, but it’s great at posking holes in plastic.

I mixed together my epoxy, then poured and squeegeed it over each of my fiber pieces.

I put my plastic wrap in the bottom of my mold and stacked up my wet fibers on top.

Then I clamped it with as many clamps as I could fit on. The clamps started pressing into the foam as I tightened them and sort of bowed the foam, so I wonder if I should have added a board on either side of the foam before clamping to better distribute the force of the clamps and more evenly compress it.

I let my composite cure overnight and de-molded it in the morning. The plastic wrap came off easily from the mold and I’m left with a very sturdy ramp.

There are spots on the edge that don’t have epoxy in them. After Neil telling us that it’s best to have a high fiber to resin ratio, I guess I skimped on the epoxy. The surface is also uneven; it’s definitely thinner (more compressed) where I had the clamps – more evidence that I should have added a layer to even out the clamping force.

I tested out my ramp with the latest version of my robot (v.1.3), and it can climb it. Going up the gentle (30 deg) slope:

Your browser does not support the video tag.

And going up the steep (45 deg) slope:

Your browser does not support the video tag.

But it doesn’t always make it up the steep slope. Good thing the slope on the back of the robot is only 35 deg. (Also, in these ramp climbing tests the motors here are only running at 25%.)

Your browser does not support the video tag.

Networking and Communications

Wed, 29 Nov 2017 00:00:00 -0500

Assignment: Design and build a wired and/or wireless network connecting at least two processors.

The final project deadline is coming up really fast, which means I want to aim this week’s assignment at helping my final project for time management. I’d really like to learn to use the NRF52 at some point, because the potential for low cost, real-time communication between devices (or in my case, robots) seems like it has some really cool potential. But since it appears to have something of a learning curve, is a completely different MCU than I’ve been using, and doesn’t have nice “Hello World” examples like the alternatives, I think I’ll leave that for the post-course future.

For project relevance this week, I’m planning to use optical communication, because that’s the only communication my project robots will have between each other. Specifically, they’ll use infrared light. The Kilobots also communicate using infrared bounced off of a surface, and they’re even programmed by infrared. So I’ve used optical communication before, but I have no idea what the robots are actually doing under the hood.

For board design, I’ll be using two separate boards this week. To send messages, I’ll use my input device board from two weeks ago (with an infrared LED and phototransistor). Messages will be received by the first version of my final project board. This board has two LEDs and 2 phototransistors, and is controlled by an ATMEGA328p (the first time I’m branching out from the ATTiny MCUs). It also has components for powering and controlling 2 motors (using MOSFETs) and 2 LEDs (green and blue) for debugging. My goal is to have the LEDs turned on and off by the messages from the other controller. (If I get the motor control up and running, I can also have the motors controlled by the incoming messages.)

For the communication design, I’m planning on using serial-type messages that will directly encode a few bytes of data in the light flashing, sent as fixed-sized “packets.” For now, I’m just having unidirectional communication between two boards, so I don’t need to worry about message conflicts. (Using more boards in the future, a CSMA/CD protocol could be used to avoid message conflicts.) It would also be good to have some sort of checksum byte for the receiver to verify the contents of the message. However, I’m not sure I’ll have time to get that working this week (with a different class having a looming project deadline next week).

Hardware

The new board I made for this week was aimed primarily at my final project, so I have information about its design on this week’s section of my project page. Here’s what the multi-functional board looked like after many failed attempts at soldering on those incredibly tiny pins on the ATmega328P:

I also did a stupid thing with a resistor. After milling my board, I realized that I’d placed a resistor under the FTDI header. Luckily (since the PCB took 30 minutes to mill and I didn’t want to redo it), the resistor fit in the space between the pins and the plastic support, so I soldered it on and happily went about stuffing the rest of my board. And then I plugged in my board. That power LED looked way too dim. I went back to check my board design and realized my stupid mistake: I’d misread the the Hello World board design and put a 10k resistor in series with the VCC from the FTDI header. And it was the resistor located under the FTDI header. Crap. With solder wick, extra rosin, a solder vacuum, and a heat gun, I managed to angle the FTDI header pins up enough to desolder the resistor and solder in a tiny wire in its place. (I wasn’t in the Science Center at this point, otherwise a 0 Ohm resistor would have been a better choice.) I nearly pulled the traces off the board that connected the FTDI header, but luckily when I ran a beep test with the multi-meter after my “repair,” everything was still properly connected.

Then I did another stupid thing. While trying to multitask and program my board at a curling tournament, I accidentally yanked on the FTDI header and ripped it up. I tore up all but the far left (RTS) trace. Whoops. When I got back, this meant a lot of soldering tiny wires on to reconnect the components. I decided to leave the VCC header disconnected, since I’m not powering my board through FTDI. Unfortunately, I had traces to other things running through the FTDI header, so I did have to rewire the other things.

There were a few other issues with this board, but they didn’t affect this week’s stuff, so I’ll talk about that on my project page.

I also made a new version of my phototransistor board that is easier to fit and attach to my robot chassis.

Software

To make sure I could program the 328p board at all, I started by compiling and uploading the 328p blink code from the embedded programming week (C code, Makefile). I changed the LED pin to one of my debug LEDs, compiled, and programmed with my ISP header. It worked!

… with one issue. I tried to use program-usbtiny-fuses before programming and got this message:

avrdude: safemode: efuse changed! Was 7, and is now ff
Would you like this fuse to be changed back? [y/n]

If I say “no,” it fails. If I say “yes,” it hangs and does nothing. Google and the datasheet have failed me trying to figure out the problem here, but somehow the board still works. My guess is that this means it’s running on the internal clock instead of using the resonator. But I really don’t understand the fuses here.

I turned to the section issues on Gitlab and Richard Liu provided an alternative (and took the time to explain how he got it from Engbedded fuse calculator):

program-usbtiny-fuses: $(PROJECT).hex
    avrdude -p atmega328p -P usb -c usbtiny -U lfuse:w:0xd6:m

Next up, I have to figure out how to send messages with light. I’ll start with some combination of the code for sending serial messages over FTDI (to understanding encoding and decoding messages) and the synchronous light detection code (for turning the light on and off at the right rate, as well as detecting those on/off states). I’m essentially trying to do “serial over infrared,” which makes encoding and decoding messages straightforward.

I made some progress on the code for this before I was once again struck down by the chronic cough and mystery illness that’s been plaguing me all semester. Since this comes into play for my final project, I’ll get back to this over the next couple weeks.

Getting Back to This…

I went back and made some simple version of IR communication for the remote control in my project. Instead of repeating myself here, you can look at the Remote Control section of my project page

TL;DR: The remote control sends a single byte (plus start and stop bits) through its IR LED when you press the buttons. The robot receives these in its main loop. Using an interrupt at the same rate as the remote control, it checks for the values of the bits, but I didn’t figure out a good way to get the right framing for the bits to identify the correct byte value. So I’m controlling my robots with a binary thresholded IR signal.

Interface and Application Programming

Wed, 22 Nov 2017 00:00:00 -0500

Assignment: Write an application that interfaces with an input and/or output device that you made, comparing as many tool options as possible.

I know how to program (that feels weird to say after feeling like an impostor in a computer science PhD program), so this week I decided to make my life more challenging than it had to be.

Before the code, a small hardware aside. Last week I had an issue with a resistor being to large. This week, I didn’t want to venture out in the cold to get a different SMD resistor from the physics lab. So I took the hacky route and just soldered on a $56~\Omega$ breadboard resistor, making sure I didn’t short out anything else on the board. It’s not elegant, but it made it a lot easier to play my Flappy Bird game. (I’m still terrible at it, but now I can’t blame the LED power.)

Racket

The first thing I decided to do was invoke masochistic nostalgia and attempt to create an interface in my first programming language: Racket. I haven’t touched functional programming since I graduated from undergrad and stopped TAing Northeastern’s intro CS class.

Luckily, Racket has a library that makes it easy to interface with serial ports: libserialport. In addition to install DrRacket (the IDE for Racket), I installed the libserialport module for Racket (raco pkg install libserialport in my terminal) and the Linux library (sudo apt install libserialport-dev).

From there, it was surprisingly easy to connect to the serial port and read bytes from it out to the console. I pulled out some code back from when I took this class as a sophomore in undergrad to remember how to do some basic functionality. I’ve got to say, I was really good at documentation back then (probably because we were heavily graded on it and I was a goody two-shoes). I also looked at Neil’s Python hello world interface code from last week to understand how to interpret the incoming information from the serial port. As a sanity check, I read out 32 bytes from the port:

#"\1\2\3\4\326\3\1\2\3\4\327\3\1\2\3\4\326\3\1\2\3\4\327\3\1\2\3\4\326\3\1\2"

Awesome. Then I need to convert these into integers. My approach to this turned out to be kind of hacky, since there isn’t a nice built-in function to convert a byte/char to an integer, like the ord() function like in Python. So I made my own.

;; byte->integer : Byte -> Integer
;; Convert a byte to an integer
(define (byte->integer b)
  (first (bytes->list b)))

But I’m not gonna lie, it took me a lot of trial and error to get there.

The next problem is reading only the current data. At first, I was just always reading the next bytes in the input buffer. But since I’m not calling my read function at 9600 baud, it falls stupidly, uselessy behind really quickly. I needed a way to flush the input buffer in the serial port when I start checking for a value so I’m looking at fresh data to get a reading. I scoured the documentation and failed many ways before eventually resorting to StackOverflow. Lo and behold, StackOverflow delivered in the time it took for me to eat my lunch. I hadn’t missed something fundamental; it is actually kind of a pain to do this. The approach is to create a really large local buffer and read values from the input port into this buffer until the input pipe is empty.

(define BUFFER-SIZE 20000)

;; drain-port: InputPort -> InputPort
;; given a port, allocate a buffer of size 'BUFFER SIZE' and
;; repeatedly read available bytes or specials until 0
;; bytes are available.
(define (drain-port port)
  (define buf (make-bytes BUFFER-SIZE))
  (let loop ()
    (define try-read (read-bytes-avail!* buf port))
    (cond [(or (eof-object? try-read)
               (and (number? try-read) (= try-read 0)))
           port]
          [else
           (loop)])))

Those were the two really challenging pieces of the puzzle. From there, creating the interface with the universe and draw packages was relatively straightforward; I just had to look back at my undergrad problem sets to remember how. I kept it simple here. Like Neil’s Python code, I displayed a bar showing the 10-bit value of the sensor. Then I added a button to save the current value and displayed these saved values.

Your browser does not support the video tag.

Does this serve any purpose whatsoever? Nope! But I’m pretty proud of myself for remembering how to do basic functional programming and getting this working without a Hello World example.

You can download my code here.

Python

I shamelessly stole an idea from my roommate here and decided to make a version of Flappy Bird controlled by light.

I started this at about 9:30 PM on Sunday night (always the best time to start anything, when you have to be up at a reasonable hour on Monday morning) and finished by 1:00 AM. I’m actually pretty proud of that programming speed run. I know Python well, but I haven’t really used Pygame much before, which is what I used to make my game. There was a lot of Googling beginner tutorials here. Luckily, Pygame makes it really easy to get a simple game up and running with the use of Sprites. I used sprites to represent my birdy and all of my obstacles, and with groups of Sprites, Pygame can easily automate moving, drawing, collision detection, and removing off-screen obstacles.

The controls are simpler: brighter light is a higher position for the birdy, and low intensity light is a low birdy position. There wasn’t anything particularly challenging about this, since my adventure in Racket helped me understand the Python serial code. The rest was trying out Pygame things until it worked. The program does seem to run pretty slow (you can see the screen tearing in the video below, and that it starts out really fast but then slows down), but I don’t know why. Can I just go ahead and blame the serial port reading since that’s the part I didn’t write?

Since Neil also wanted user interaction on the computer, I made it possible to click a button to restart the game when your birdy inevitably hits a wall and dies.

Your browser does not support the video tag.

Download the code

Input Devices

Wed, 15 Nov 2017 00:00:00 -0500

Assignment: Measure something: add a sensor to a microcontroller board that you have designed and read it

This week we’re back to things I can use for my final project, and that I now have time to do.

I have a couple of specific goals for this week:

Use a phototransistor to measure infrared light:
- Whether or not there’s an IR light shining
- How fast the light is moving (I don’t care about the direction of movement, but I may still need a second sensor depending on how well the phototransistor works for this)
- Can I detect flashes of IR at different frequencies (e.g., 10 times/second, not varying the frequency of the light)
Put a bootloader on my board to try using it with the Arduino IDE and libraries

I started with my Hello World board design from Week 7, and started adding things. I put in a power LED like I did two weeks ago, for a sanity check. Then I added in an infrared LED an a 4-pin header to connect to a mini board that I can put my sensor on. This lets me have both the LED and sensor controlled by a single MCU board for debugging and pretty closely matches what I plan to have on the robot for my project: the PCB will be mounted on the bottom of the robot, but the IR sensor will have to be threaded through to the top surface of the robot.

Make the Board

Just when I thought I’d gotten the board milling down smoothly, this week it took three attempts to mill my board.

The first time around, I cut my traces and they looked terrible. A bunch didn’t even cut through the copper layer, and where it did the edges of the cuts were really rough. My guess was that the endmill was dull. Turned out I was right; I swapped out the endmill and the traces on the second board came out fine.

The second time around, things went haywire when I cut the outline. When I’d exported the image from Eagle, there were some weird extra white lines. But I was too lazy to edit the image to get rid of them. It’ll just create extra cuts, I said. It’ll be fine, I said. I lied. When it went to cut out he sensor mini-board, it had already milled a larger rectangle around both boards. So there wasn’t enough tape holding down the board and the mill pulled up the board. Oops.

But third time was the charm! I relented and cleaned up the extra lines for the board outline in Paint (we’re keeping it high tech here).

When it came time to stuff my board, I realized that in my effort to make a super compact board (which I’m getting better at, by the way), I hadn’t left much overhang to support the FTDI header. Solution? Stuff a bunch of hot glue under it! (Side note: that mega-joint between the capacitor and the FTDI ground pin did in fact start out as two separate solders.)

When picking the parts for my board, I also discovered that we were out of 20 MHz resonators. I told Rob so wee could order more, and for this board I just left off the resonator altogether and hoped my clock was close enough to work for serial communication. (Spoiler alert: it was.)

I’m weirdly proud of this tiny board for my phototransistor. It just has a single sensor on it, but somehow it manages to look cute. I connected it to a probably-too-long cable and a 4-pin header. The diagonals of the 4-pin header are both connected together and to one of the connection on the mini-board, so that there are only two orientations for this to be connected to the board. (That increases my chances of getting it right from 25% to 50%!) I also heat-shrunk the connection between the wires and the board give it some structural integrity.

Program the Board

I started with Neil’s Hello World Program for light sensing (C code, Makefile, Python interface). I then modified it to use the right pin for my FTDI header and added a section to turn on my infrared LED.

The challenge came in adapting the code to work with the ATtiny 44(which I’m using) instead of the ATtiny45 (which the example code uses). For this, I dug into the analog to digital sections of datasheets for both boards. I had to figure out what I needed to do to the ADMUX register to make it work the the 45 and my pin. Once I figured out what each of the bits in the register meant, it was pretty straightforward to set them.

I have my modified code here: C code, Makefile

Testing the board

I didn’t actually know which end of my phototransistor was the collector and which was the emitter. There were tiny marks on the ends of the IC, and I checked them against the datasheet for the part, but then I realized it didn’t really matter. Because there are only two orientations that I can connect my 4-pin header, if it didn’t work I can just rotate it 90 deg and try again.

The moment of truth: plugging it in and starting up the Python serial receiver on my computer. At first, I thought I’d seriously screwed something up: I was getting a reading of 1023, but when I squeezed the miniboard, it went down to 800-something. Had I somehow magically created a force sensor instead of a light sensor? Nope! My confusion came from the fact that the value goes down when the light gets brighter, since more of the voltage goes through the phototransistor when that occurs. As for the force-sensing part, my guess is that when I squeezed it, some of the current was going through my fingers to connect the pins on either side of the sensor; it had nothing to do with my sensor at all.

First I looked at how it sensed my desk lamp. It was almost too good; apparently that light puts out a lot of infrared. It made me a little worried about how much bright background lights might end affecting the readings on my robot. But as long as no one shines a flashlight on it I’m probably fine, since when my sensor isn’t right under my desk lamp it still reads 1023 (no IR light).

Your browser does not support the video tag.

Then I tested it with the infrared LED I had installed on my board. The phototransistor did detect it, but it had to be really close to pick up a change.

Your browser does not support the video tag.

I realized that the problem was likely that I was using too large of a resistor, so the current through my LED was really low, and therefore the light was too dim. So how bright could I get the LED and not blow it up? According to the datasheet for the LED, it has a maximum forward current of $I = 65~\text{mA}$ , which on its IV curve matches to about $1.6~\text{V}$ . If I want $1.6~\text{V}$ going through my LED and I have $5\text{ V}$ of power, I need the remaining $V = 3.4~\text{V}$ to be absorbed by my resistor. Recalling $V=IR$ , this means I need a resistor of about $R=50~\Omega$ . The easiest was to approximate this was to put in parallel a $56~\Omega$ breadboard resistor that was laying around the lab. (In parallel with a large resistor, the resistance is pretty close to that of the small resistor because the current will take the “easier” path.) It was tricky to hold this resistor in place while moving the sensor board, so unfortunately I don’t have a video of this improvement because I don’t have a third hand. Suffice it to say, it worked; I has able to get mid-range digital readings (500-850) out of the sensor when it was 5-10 cm away from the LED. This is great, since that’s about the distance between my robots when they’re stacked on top of each other. I was also able to see a clear spike when I moved the light horizontally across the sensor, which means that robots should be able to easily detect the movement of robots on top of them.

I just said easily, so I think I jinxed it; my concern here is that the horizontal range for sensing is pretty limited, meaning they wouldn’t know that there’s a robot on top of them. The solution would be to add more sensors or more LEDs, but I’ll hold off on doing that until I have a better sense of the robot design and what modifications to make on that front.

About That Arduino Stuff…

I once again didn’t get around to making my board work with Arduino code. But I at least made progress this time. Rob directed me to this High-Low Tech page that walked me through setting up an ATTiny 44/45 to work with the Arduino IDE and program it with the FabISP. Over Thanksgiving break, I’m hoping to get this working as an alternative to hanging out with family. It looks like I need to load the programs with the FabISP each time; it doesn’t actually put on a bootloader. Can I get a bootloader if I switch to the ATMega328p? Trying out that microcontroller is another thing on my TODO list.

Machine Design

Wed, 08 Nov 2017 00:00:00 -0500

Assignment: Plan and make a machine

You can check out the class page here.

The Goal

This week was a group project: start with Jake’s design and build our own multi-axis machine. Our Harvard section decided to make a machine that will draw glow-in-the-dark art using a flashlight. At our sign-ups and planning Wednesday evening, I ended up on the programming portion of the project (gotta make use of my CS PhD skills).

The Reality

For me, this was a terrible week to have a group project. It’s due by our 9:00 AM class on Wednesday. My conference manuscript is due at 7:00 AM on Wednesday. Great timing.

So I did not contribute nearly as much as I should have (or wanted to) this week. I started by helping to get us organized at the beginning of the week, then resurfaced again the day before things were due to pitch in where I could.

That turned out to be by building the class page for the week. Thankfully, people were good at taking pictures along the way, but as of Tuesday afternoon, no one had put anything together for the class page yet. (We were definitely behind the other sections on that front.)

The simplest thing to do was create a single CSS file and an HTML file that people could start editing to add their content. This wasn’t the time to try to throw in Jekyll or some other preprocessor to build multiple shiny pages using only Markdown; this is quick and dirty.

Everyone threw their pictures into a Google Drive folder, all uncompressed. Luckily, I’d already created a handy script to batch compress and resize images and a matching script for videos.

From there, I kept a regular eye on the files as people filled things in, to make sure everything was covered, and that the HTML was still formatted reasonably.

Did I get a lot out of this week? Nope, because I didn’t do anywhere near as much as I should have for the group. However, I’m pretty sure that my advisor happier that I’m getting this manuscript submitted.

Output Devices

Wed, 01 Nov 2017 00:00:00 -0400

Assignment: Add an output device to a microcontroller board you’ve designed and program it to do something.

Design

I’m building a robot, so I really need to make that robot move. That means this week I’m going to make a board to control some regular old DC motors. If all goes as planned, I hope to make a board that will control two motors, like I plan to have on my robot. This week I’d also like to try making a 1.5-sided PCB – in other words, using the other side of my PCB as a ground plane. I need to figure out how to do that in Eagle, then learn how to connect the vias when I build the board.

I’m starting with the motor hello world board from the class website. I’ll re-build it in Eagle, add outputs for a second motor, and maybe buttons to control the motor. (This time maybe I’ll even hardware debounce them and save myself a struggle in code.)

Once I started designing in Eagle, it turns out that adding a second h-bridge makes the layout and routing a lot trickier. I ended up using two 0 Ohm resistors to jump some other traces to get the reference voltage to my second h-bridge. Yuval pointed out something useful to me, though, that let me avoid the 1.5-sided approach. The design in Neil’s routes the power and ground generally in a ring around the outside, and then components inside can draw from that. That turned out to be useful in laying out my board. Also useful: this time I did my schematic by labeling nets instead of drawing a million lines. This turned out to be crazy helpful, because then when I started a trace on the board, Eagle highlighted all the possible pads and traces for it to properly connect to. It also meant it was a lot easier to keep track of my pins on the 6-pin header and the ATtiny.

Milling & Stuffing

This week I had my first experience with not leaving enough space between my traces. (I should really figure out how to set up design rules in Eagle.) I realized this when I checked the preview in Mods, but it looked like only one or two tight spots, so I decided to go ahead and mill it anyway, then cut those with an exacto knife afterwards.

When it came time to mill the outline, I discovered that the Mods preview didn’t show cutting the bottom edge of the board. It turns out this was because I drew the dimensions of my board in Eagle too close to the workspace boundary. I’d already milled the traces at this point, so I didn’t really want to go back to redo things in Eagle. With a PNG at 1000 pixels per inch and an endmill diameter of 0.03125” (1/32”), I guessed I needed at least 32 black pixels at the bottom of my image for Mods to mill the bottom edge. So I just pulled up Gimp and added an extra 20 pixels to the bottom of my image. I figured I had enough leeway on the bottom to not cause any problems, and I was right.

But it turned out I actually had seven shorts that I needed to cut with an exacto knife. In the process of fixing my board, I also accidentally cut through one of my other traces. Crap. Solder had too much surface tension to just create a jumper with that. I tried soldering a small wire, but that was too big, especially in these tight quarters. I ended up pulling a single thin copper wire out of a wire, and trying a dozen times under a microscope before finally getting it to attach on both ends and not accidentally connect to the neighboring trace. It was a huge time sink, but eventually it worked, and I verified with a multimeter that it only connected where was supposed to.

Adding the rest of my parts, I discovered that I’d used the wrong piece for a power jack. But 1 2x2 jumper fit on that spot, so I just used that instead. Besides those delays, stuffing the board went pretty quickly; I’m getting faster at this.

Debugging

First step: powering the board. I’m glad I added that power LED, since with the 4-pin header for power it’s easy to attach it the wrong way (which, despite my best efforts, I did on many occasions. It doesn’t seem to have killed my board yet.) I started by connecting it to a lab power supply, and it worked, drawing 0.01 A with no motors connected.

I was on a roll with this whole power thing, so I took the remains of a cannibalized USB power cord from my lab and connected it to a header cable to power my board.

I found some spare Pololu motors in a drawer full of screws my lab, so I’m going to use those this week. I soldered on some wire and tested them both with a power supply . They are 6 V motors, and draw 60 or 100 mA. (They’re apparently slightly different motors.)

For programming, I started out with Neil’s hello world program for DC motors (C code, Makefile). Since I didn’t change the board much, all I had to do was double check that my output pins to the H-bridge were correct, then compile, and load. That all went flawlessly.

Then I actually connected the motor.

Nothing happened.

I rechecked my connections with a multimeter, and Rob helped me use the oscilloscope to check that the PWM signal from my board into the H-bridge was working as expected. But there was no power to my motor out of the H-bridge. I tried changing the program to use the pins for the other H-bridge. No dice.

Rob said that the H-bridges are sensitive, and I may have burnt mine out when I plugged in the power backwards. So I desoldered and replaced one of my H-bridges. Still no dice.

Then Rob realized the real problem: these H-bridges require the input voltage for the battery to be ~3 V higher than the reference voltage; both of mine were 5 V. So much for using my cool USB power cord, since USB supplies 5 V. I switched back to the power supply and was able to get the motors to run! I was a little worried about the motors, which seem to run at 6 V. (I tried turning up the voltage, but the motors got pretty hot, which seemed like a good sign that they are not intended to run at 12 V.) I was able to get it working once I got the input power up to ~7.4 V, but not much below that. For now, then, I’m chained to the power supply, but it does mean that I should be able to get this to run on a 7.4 V battery for my project.

Your browser does not support the video tag.

Molding and Casting

Wed, 25 Oct 2017 00:00:00 -0400

Assignment: Design a 3D mold around the stock and tooling that you’ll be using, machine it, and use it to cast parts

Design

I decided to make a scaled-down model of my robot for this week’s casting. That way, I can make a bunch of them and have a way to demonstrate how I want them to move. (Making a bunch also makes it a prime candidate for molding instead of 3D printing.) Another option I considered was molding treads for my actual project robot. I decided against this because I think it might end up being far too time-consuming to make my own tracks. I’d also need to design and make the track guides, make sure they mesh together well and don’t slip, and figure out the very precise spacing between the track guides. Considering that my robot has a lot of complex and moving parts, my time is probably better spent on the rest of the robot.

But I digress: a model! I made a copy of my OnShape document for my model and stripped out all the unnecessary parts like screw holes and struts. I then added a parametric scale factor to all the major dimensions (i.e., excluding things like thickness of the top plate). This means I can make an approximately-to-scale model of my robot and adjust it based on the size of the machinable wax block. After playing around a little, I made it at 30% scale. I didn’t make the thicknesses of treads and the thin top layer to scale, because they would end up being too thin, especially for casting with Drystone. I then created an approximation of the tracks and track guides and filled a bunch of support material underneath the chassis to make all the pieces connected and well-supported for a brittle material. I’m still a little concerned that the thin parts of this are too thin for Drystone. If that ends up being true, I might find a different material to use for making a bunch of models.

After making my model, I have to turn it into a mold. This is where things get tricky, since it has to be machinable. First, I’m not sure where to split the mold into multiple pieces. Second, all the parts have to be reachable in machining (i.e., no parts to be cut out underneath). And lastly, there’s some mental manuevering to make a positive mold to create a negative mold.

Joe Negri suggested turning this into a two-part model, since that part with the ramp is especially tricky. I separated it into a cover part (purple) and wheels (teal). To work through the mental gymnastics of creating the positive mold, I worked backwards from these final parts. First, I created the negative mold (the part that will be cast out of Oomoo). I did this by creating a rectangular prism and boolean subtracting the cover piece from it. I added extra prisms to create sides and a lip that will register the top and bottom parts over each other. I also have to add sprue holes. To prevent air bubbles from forming, these have to be at the highest points in the part, which leaves the lip of the cover. From my mold parts, I can then create the positive mold parts that I will mill out of wax. After creating the negative mold, this was pretty easy: just create a block the size of the mold and boolean subtract the negative mold.

Mold Making

We’re milling our mold-making molds out of machinable wax on the desktop ShopBot. I started with the wheel part, because it seemed easier.

The first pain was setting up the cuts in VCarve. First, I made the width and depth of the material the size of the negative mold piece (what I want to make out of Ooomoo) so it would cut out everything necessary. The problem came when I imported my part, which I’d made in metric. VCarve uses imperial units. Translating between the two turned out to be a pain because STL files are unitless. (I now really appreciate the PNGs keep track of this.) I set up my rough cut and finish cut, but the finish cut in this particular case ends up being worse than the rough cut because there are no curved surfaces along the z-axis. The rough cut will cut around the curved parts in x and y, but the finish cut doesn’t. So it might make sense to just skip the finish cut altogether, except for one problem: the rough cut only cuts at fixed depths (in this case, I had it set to 1/8”). That means the finish cut was necessary to cut features that had horizontal parts in between these 1/8” passes. There’s probably a way to change the way VCarve does this, but for my first go at 3D machining (and on a relatively unimportant part), it was good enough.

I zeroed my axes on the ShopBot, re-zeroed the z-axis up 2”, and did an air cut. It looked good, so I lowered Z down to -2”… and the endmill promptly went half an inch into the wax. Good thing we were only working with wax, or that could have done serious damage to the endmill or machine. I’m still not sure why this happened. Since I stopped the aircut with the endmill down 1/2”, I wondered if somehow the ShopBot mentally reset this as zero. Rob suggested that the machine just doesn’t handle negative numbers well. Either way, the damage to the wax block was minimal enough that I could still cut my mold.

I milled out both parts, but realized I’d made a mistake when cutting the mold for the bottom half of the wheel mold: I didn’t leave any space between the surface of the wax and the top of my mold positive. That means no space to fill with Oomoo on top to create the negative mold. Luckily, my part is small and Oomoo is pretty high viscosity, so I could just pile it on top.

The Oomoo silicone from making the negative molds was pretty easy to work with. Just mix a 1:1 ratio of the parts and stir thoroughly. Before pouring into my wax, I degassed with a vacuum chamber. This is an incredibly satisfying process, watching the contents foam up and then collapse. You don’t realize how much air is trapped in there until doing this. When I poured my Oomoo, I had exactly the right amount. I’ve got mad estimation skills. I came back the next morning to retrieve my molds, which turned out nicely bubble-free. The challenge was getting the silicone out of the wax. The smaller part (where I piled extra silicone on top) was a lot easier to get out, since it wasn’t as deep and I could use that overflow as a lip to grab onto. The deeper part was trickier, because I had nothing to grab onto and had to wiggle it out incredibly tediously over a few minutes.

And behold: I have a mold!

Casting

First up: making a model out of Drystone. I actually used this earlier this week for Project Night and was impressed by the level of detail I could get. (More about that lower on this page.) My first mistake this time was getting the ratios mixed up. Instead of doing 100 parts powder to 20 parts water, I did the reverse. At least I realized that it was way too runny before trying to cast with it, and I just started over. Having multiple holes on the top of my parts was definitely a good idea, since it helps prevent air bubbles from getting trapped near the top.

My first attempt at drystone casting was on objective failure. Out of laziness, I decided to ignore the instruction to only add water to the powder, and did the opposite. I’m not sure if this is what messed things up or if I failed at getting the ratios right. When I came back the next day after casting, the bottom part of the cast was fine, but the top was still wet and mushy: too much water. Also, I had masking-taped the parts of the mold together. This mostly resulting in squishing the sides together so that the tread parts were concave instead of straight.

On my second attempt, I actually followed the instructions, and the resulting mix was much thicker. I also skipped taping the mold together. There was some flashing and roughness on the resulting piece, but it did cure properly. The 25% stepover finish cut on the upper part of the mold looks really obvious here.

I removed the casting posts with a utility knife and smoothed everything out with a small file. The casting joint is still noticeable, and it would have been better to put this at an edge of the piece, but I didn’t think the endmill was long enough for this. I was skeptical when I first took the piece out of the mold, but after doing some cleanup, I’m really pleased with how it looks.

At some point, I’d still like to make a mold for the second part of the robot and put the pieces together. We’ll see if that actually happens.

Bonus Molding and Casting

At Harvard’s Project Night last week, we also did molding and casting. Unfortunately, I couldn’t cheat and use that for my assignment this week because we didn’t mill our molds. I decided to make myself extra thumbs, just in time for Halloween. The idea was to duplicate a thumb and attach it to the un-thumbed side of the other hand.

With the help of Chastity Li, I used Smooth-On Body Double to cover both of my thumbs and the sides of my hands. After it cured, we attempted to add plaster bandages to the silicone parts for reinforcement, but they didn’t stick at all.

I wanted to cast the thumbs in silicone, but I needed to leave an indent on top shaped like the side of my hand. So I needed a replica of this part of my hand. I used the Body Double silicone mold to make this double out of Drystone. There floppy molds didn’t have any stability on their own, so I built up supports with clay to hold it in place (and close off the ends) for my Drystone casting. I was impressed with how much detail I got on the hand doubles from this process.

With my hand doubles made, I built up similarly ad hoc supports for my thumb molds. I mixed Exoflex 00-50 with Silc Pig pigments (mostly flesh color, with a little blood and brown). It’s crazy how little pigment it takes to color the silicone. I sprayed mold release into my thumb molds, poured in the Ecoflex, and added my hand doubles on top. It turns out I should have made just a little more Ecoflex, since it didn’t quite go up as high in the mold as I wanted. That means less overlap with my hands for attaching.

When I took the cured thumbs out of their molds, it turned out that I didn’t get the mold release quite all the way down into the mold, so it was tricky to get them out at the ends. I ended up with some of the mold stuck under the fingernail of the right thumb. But behold: thumbs!

But how do I attach them. Someone suggested spirit gum, but Google told me this doesn’t stick to silicone. Smooth-On makes Skin Tite for this purpose, but it costs $20-30, plus I have a Halloween party in two days. My roommate suggested being a mad scientist with a lab accident: in other words, use lab gloves. It would have been better to use something that showed off my thumb casts, but this will do:

Bonus: Google Photos made an animation of me using my new thumbs!

Your browser does not support the video tag.

Embedded Programming

Wed, 18 Oct 2017 00:00:00 -0400

Assignment: Read a microcontroller data sheet and program your board to do something.

This week it’s time to program that Hello World board from a few weeks ago. I have three LEDs and a button on my board, so my goal is to make LEDs cycle through when you press the button. I’ve done C programming on a microcontroller before for the Kilobots and on an Arduino, but both involve an extra layer of abstraction. (Like Arduino, the kilobots also have a library.) So my challenge this week will be programming without this library overhead.

It turns out that I already had an FTDI header laying around, since we use it to debug the Kilobots. That means I don’t have to leave the comfort of my office for this week’s assignment!

To start writing my code, I looked at examples from the class website: hello.ftdi.44.echo.c and hello.arduino.328P.blink.c.

Blink!

Your browser does not support the video tag.

First up, I tested translating the Arduino blink code to run on the ATtiny-based Hello World board. In the C code itself, all I had to do was change what pin I was pointing at for my LEDs, and set the clear/output/set for all three LEDs. I was also able to shamelessly steal (er, reuse) the Makefile from the original hello world code and simply change the project name:

I tested this with all three LEDs on my board (PA7, PA3, and PA2.) The first two worked, but the last one didn’t. Troubleshooting, I found a 1.8 V drop over the functional LEDs, but 3.3 V on the non-functional LED, which means the full current was passing through. The most likely cause was that I’d put the LED in backwards. I de-soldered and re-soldered it in the lab, hooked it back up to the FTDI cable, and it works! (Side note: it’s really hard to solder tiny components when albuterol makes your hands really jittery.)

Button Interrupts

Next up: responding to the button. The best way to handle this is probably as an interrupt when the button is pressed. I started with the example interrupt code and went to work on it. It took a while to read through the datasheet and find what I needed to set to enable the second interrupt (like creating ISR(PCINT1_vect) and setting PCMSK1). I set a state in my interrupt function that would rotate through 0, 1, 2, or 3 LEDs being on.

It took a lot of trial and error to figure out that it was working, especially given the problem I next ran into: my board seems to be haunted. More specifically, the interrupts seem to happen randomly. When I press the button, the interrupt often isn’t triggered. But if I touch the board somewhere else or shake it by the cord, the interrupt is triggered. (I started logging to the console via FTDI to track the interrupts.) Sometimes, a huge string of interrupts is spontaneously triggered and the LEDs start strobing. In the event that there was something weird going on with the FTDI header, I tried directly connecting my board to a 3.3 V power supply, touching the ground with one hand, and then poking around the board with my other hand. It didn’t help.

Your browser does not support the video tag.

I’m currently at a loss as to what’s going on with the interrupts, especially since the FTDI serial inputs are still working just fine. Is something short-circuiting on my board? Do I have a loose connection somewhere? At this point, at least it’s only Monday. Hopefully I can get some help tomorrow sorting this out.

One day later…

This morning a TA linked to this tutorial on buttons that I’d previously missed. (Oops.) Aside from the fact that they’re not doing it with interrupts, my problem became immediately clear: I never set the pull up resistor to be on! So I was getting meaningless readings like I had no resistor at all. I adding a line before the loop in my main function setting the button pin to high, and now my button actually works!

Sort of.

Now when I press the button it triggers as multiple button presses. This is a problem I previously encountered when I connected a button to a Raspberry Pi Zero. The solution there was to set a “bouncetime,” where additional interrupts within, say 300 ms would be ignored. Apparently this is more generally called “debouncing.” And it seems to be a lot trickier in this minimal C environment than it was when adding a keyword to a function with Python GPIO. At this point, I could undo all this, follow the tutorial, and get rid of interrupts. But I’ve come so far! And I’m apparently a programming masochist, and this might actually be a useful thing to know how to do. (On second thought, the non-interrupt tutorial still likely wouldn’t help me, because it wouldn’t help with my counter being triggered multiple times.)

According to my Googling, one way to fix this is to add a capacitor to the button to smooth out the changes. But I really don’t feel like figuring out to squeeze in a capacitor to my existing board right now. I ended up finding a useful tutorial that I was able to adapt to the ATtiny44. I added a timer interrupt that occurs every 10 ticks. If the button state changed, I set a flag that will result in changing the LED in the main loop.

One last problem I encountered was failing to understand the difference between PORTB (used for writing to pins) and PINB (used for reading from pins. I got really frustrated that my button presses weren’t being detected when I tried to run get(button_port, button_pin) instead of get(button_pins, button_pin). I also settled

Your browser does not support the video tag.

Now look at the minimal result of all that work! I finally cleaned up my own code, which I have here:

Make Something Big

Wed, 11 Oct 2017 00:00:00 -0400

Assignment: Make something big (out of wood, using computer-controlled machining).

The Concept

This week I’m going practical and making a shelf for my home bathroom. The bathroom is… cozy, and shared by five people. Currently, we have a shoe rack to store all our bathroom things, which also blocks off the towel rack. If we get something to function as bathroom storage, this means we can reclaim the shoe rack to store five people’s boots and shoes (which is particularly useful as winter slush, salt, and sand approaches). But it also turns out that it’s hard to get something that fits in this small awkward space. So I’ll make something!

I’m also interested in woodworking, so I wanted to try out making some form of traditional joinery with a CNC machine. The simplest candidate here for a beginner is a box joint. Conveniently, the shelves I am interested in making are rather boxy. Per Rob’s recommendation, it’s best to start simple on the ShopBot in general. I also ended up getting really sick for most of this week, which really cut into my time on this. Luckily, I had started designing this week’s assignment in CAD before I got sick.

I got really interested in some of the more complicated joinery shown here, but there was no way I was attempting that on this time scale, or on oriented strand board (OSB).

The Reality

All that above was written before I actually made anything. I have a different story to tell now. I’d been looking forward to this week’s assignmen since the beginning of the semester, since there are a lot of really cool large scale things I could make.

I signed up for a time slot on the ShopBot from 3-5 on Tuesday, which I already didn’t like since it’s so close to the deadline, and from nearly the time I started, everything went miserably. I don’t think I have ever so much regretted finishing my homework.

Before my time slot, I exported my test part (a simple pair of box joints) from OnShape as a DXF file. Then VCarve couldn’t import the DXF with the right scaling, for some reason. So I opened the file in Inkscape, saved it to a PDF, then imported that into VCarve. The scaling was right, but I had a new problem: the DXF files don’t connect any line segments. So back in Inkscape, I selected all the coinciding points and merged them. For a test part, it wasn’t bad, but I knew just how many parts there were to my whole shelf unit. I started here using the “official” values: an endmill diameter of 1/8” and a stock thickness of 7/16”. Depending on how my test part came out, I figured I could make adjustments to my stock thickness from there for my real cut. In VCarve, I added a few tabs and set a cut depth of 0.44” – just thicker than the material.

Since the Harvard ShopBot only cuts 4x4’ sheets, I used calipers to try to find two sheets of OSB with approximately the same thickness. We screwed one to the ShopBot sacrificial layer around the edges, zeroed it, and cut two copies of my test piece. The cutting worked great! My parts came out clean and fit together snugly and perfectly. Maybe this would all go perfectly like the miraculous laser cutting. I was really hoping that it would go fast, because at this point I was already coughing nearly non-stop from the sawdust.

Since my assumptions about stock thickness seemed to be holding up, I went back to my CAD model, exported the faces, and went through the tedious process of merging nodes in Inkscape on my laptpo. There were hundreds of them. Given more time and significantly less mental haziness, it might have been worth creating a little Python script to merge coincident points in an SVG file. But that was not going to happen today. I saved my files, pulled out my flash drive, plugged it into the computer with VCarve… and discover that none of the merged parts saved because I didn’t eject my flash drive properly. Another 15 minutes to redo all of it!

With all my parts in VCarve, the next challenge was arranging them. Specifically, I was cutting it really close on the clearance to the screws based on the size of my shelf unit. I hadn’t given this a lot of thought before. There was a lot of very careful adjustment and checking the max and min positions in the shopbot file. Daniel didn’t have us doing air cuts because there were a lot of people who still had to cut. This turned into a problem on my first sheet of cutting, when somehow I accidentally re-zeroed the X and Y positions when we set zero for Z. The ShopBot ended up going perilously close to a screw on the far right of the sheet, then running itself off the back before I hit stop.

After re-zeroing and starting over, the first sheet cut pretty well. There were a few spots were it didn’t cut through, though. This was due to my ill-conceived idea to save the sacrificial layer by not cutting too deep. I was able to get through these remaining spots in short order with a drywall saw. It left some ugly fringes on the backside in part thanks to the horrible nature of OSB, but nothing that couldn’t be cleaned up with a bit of sandpaper.

The second sheet was where things went terribly wrong. By this point, it was past my 5:00 slot, I was less than half done, and I’d been inhaling and coughing up sawdust for over two hours. This time, we set zero for the Z axis further into the board where, as I discovered at the end, the board bowed up slightly. This is where that cut depth of 0.44” really came back to bite me: Nothing cut through all the way. Well, a few spots in the middle did, but this was not a discovery I made until after pulling the material off the machine. At this point, it’s too late to fix on the ShopBot. As it turns out, it’s also too thick to cut through with the drywall saw in any reasonable period of time. So it was back to human-controlled machines: a jigsaw. Luckily, my dad let me play with power tools as a kid and my favorite was always the jigsaw. I set about re-cutting all the parts with the jigsaw, trying to follow the inside of the ShopBot kerf as closely as possible. All those box joints turn out to be a huge pain with a jigsaw, since it can’t cut sharp angles and all cuts have to be started from an edge or existing cut through the wood. It was miserable.

So much for the perfect, clean test joints – this thing was a mess. Between the warping of the wood, slight differences in wood thickness, and the imprecision of my jigsaw cutting, things did not fit together really nicely. After my experience with my laser cutter spice rack, I was worried about fits being too tight. I only needed a little work with a rubber mallet to fit the whole thing together, but it’s not pretty (besides the fact that it’s made out of OSB). There are gaps due to warping and the tightness of the joints is inconsistent. Without the back panel, there’s no way this would stand up. With some wood glue and brad nails, it could probably be made reasonably stable, but I’m not sure it’s worth it. Bonus: The way I designed the radiator cover part on the bottom back, there’s nothing to hold it in place and it just falls out.

Finally done with my shelves after nearly five hours, I decided it was a great idea to haul it back from the Science Center basement to Pierce Hall, where I was an hour and a half late to Project Night. This was a terrible idea, and after finally getting there, it took at least five minutes before I could stop coughing enough to talk. It’s now sitting in next to my desk in the lab being an eyesore for the rest of the office, particularly put to shame sitting next to Kirsten Petersen’s CNC wood chair. Maybe spending a year passing that every day gave me unrealistic expectations about what I’d actually produce this week.

Summary: this is not going in the bathroom.

I might go back and try to make an improved version in the future, but honestly, that’s pretty unlikely when I could work on building robots instead of breathing in sawdust.

Electronics Design

Wed, 04 Oct 2017 00:00:00 -0400

Assignment: Redraw the echo hello-world board, add a button and LED, make it, and test it.

Design

This week we take a step up from just milling and stuffing an existing PCB design to designing our own PCB. Well, design in this case is pretty straightforward, just having to add a few components.

I started with the example board layout, which shows the starting components and one layout of wiring them together. I used Eagle for this assignment, since we got a nice walkthrough in session, and it runs for free on Linux. (I got it up and running in my Chromebook really easily!) I imported the FAB parts library. I’m really glad that we have this compact inventory, because otherwise I would have no idea what to make of the intimidatingly large assortment of components out there. I added all the components to my schematic, but the clock ended up being tricky because it was categorized as “resonator.” I wired up the parts directly. On this first go, I actually drew in all the wires with the net tool because I wanted to make sure I understood how it all fit together. But I can definitely see how horrifyingly messy this would get with scale and why the naming and labeling to connect wires would end up being really useful.

One of the initially most frustrating things about Eagle was moving parts. I could move around my little parts like LEDs and capacitors, but I frustratingly couldn’t get the larger parts to move – in either the schematic and the board. I’d right click and wouldn’t get a pop-up menu, or I’d try to drag them while in the “move” tool. It turns out that in Eagle, every part has a little + in the center, and you can only really interact with it (right clicking and dragging/moving) on this little plus sign. Things got much easier once the TAs helped me figure this out.

In addition to my mandatory button, I added 3 LEDs to my design, each connected to a 1 kΩ current-limiting resistor. I could have used the RGB LED in the FAB library, but that’s not nearly as much fun as getting to solder on more tiny LEDs for practice. Plus, this way I don’t have to decide yet what colors I want to use and I get to use up all the spare pins on my ATtiny 44.

After finishing up my schematic, I moved on to laying out the board. I mostly stuck following the example board when it came to route traces, since I don’t have a good intuition yet for how to lay things out. Initially my LEDs were all over the place, but I figured out a way to nicely line them all up along the bottom. I wasn’t certain what thickness to use for the traces, but based on the characterization part from Week 3, I decided to start with a thickness of 0.012 inches. I did make the mistake of not setting the trace thickness before starting to draw them all in. Luckily, I could change them after. From the toolbar, I selected Change (the wrench) > width, and selected 0.012. (Frustratingly, there are no units listed.) I could then click on all the traces I wanted to change, and any I added after that would use this new width. In adding the LEDs, though, I ended up placing some traces that look pretty janky.

While adding the traces, I primarily used a grid size of 0.005”, which allowed me enough fine-grained control but let me still draw nice vertical and horizontal lines. However, I did intermittently switch the grid size to 0.01625” (1/64”) and turn grid display on so I could check that I’d left enough space between traces for the endmill size. Toward the end, though, I figured out a cleaner approach: set the grid size to 0.00390625” (1/64/4”), then set the multiple to 4 and turn on display. This way I could keep checking the spacing but snap to a grid 4x smaller than the endmill, which gives a lot more flexibility.

I also added some text to the layout, just to try it out. Adding “Hello World V. 1” might actually be useful, in case I have to redo the board and don’t want to get them mixed up. But adding my name? That’s pretty much just narcissism. I’m not totally sure how well these will cut out, since the spacing between letter parts looks pretty tight. Hopefully it will at least be intelligible.

I also needed to create an outline of the board. I used the rectangle tool and drew an outline in the “Dimension” layer.

Finally, I had to turn it into PNGs for the mill. I turned off all layers but “Top” (for the traces), then went to File > Export > Image. I checked the monochrome box, set the resolution to 1000 dpi, and saved. For the outline, I turned on only the “Dimension” layer and exported it in the same way to another image file. At this point, I should theoretically be all set to mill the board.

Production

I milled my board using the same process and mill as in electronics production week. After getting Rob’s help to fix a mysterious issue where Mods wouldn’t connect to the mill, everything went flawlessly. I used more double sided tape than last time to keep things flat. I also set the depth for cutting the outline to 1.7 mm to help save the sacrificial layer.

Before actually milling, I double checked the preview of the endmill path. To my relief, I had left plenty of space between the traces. As expected, the small lettering of “Hello World” didn’t get fully cut out, but that’s fine – at least my name looks nice. My trace thickness also seemed good – not too thin to delaminate, but not so thick that I couldn’t route things well.

Soldering the board also went quicker than electronics production week, as I’m getting the hang of it. I’m pretty sure I didn’t solder the microcontroller on backwards this time, for example (though it was hard to tell which was the correct orientation). The resonator/clock was also kind of weird to attach, since the pads go primarily under the component.

Programming and Testing

The class website was really unclear on how to actually program and communicate with the board, but with the help of Rob and our TA Brian Plancher, we finally figured out all of the pieces. I thought I’d share it here so others wouldn’t have to go through that confusion. These directions are based on using a Linux machine with all the necessary software installed that’s described last week. I used the Chromebox running Gallium in the Harvard SC102 shop (next to the Formlabs printer).

Connections

Connect your programmer (from last week) to the computer by USB.
Connect your Hello World board to an FTDI cable, plug the FTDI cable into USB on the computer. (The board is powered through the FTDI header, so you need to do this to program it, even though you’re not talking to the board by FTDI yet.) Before you plug your board into the FTDI cable: check the orientation of the FTDI pins. Pins 1 and 3 are VCC and GND, so you can use a voltmeter (multi-meter) to check that you see 5 V between these pins. (Your FTDI cable needs to be connected to USB power, and you have to plug in some header pins into the FTDI end to touch to the multi-meter.)
Connect the Hello World board to your programmer with the 6-pin header cable. (Make sure you’re matching pins - e.g., ground connected to ground.) The red LED on your programmer should light up.

Programming your Hello World board

You’ll need to download the C program and the Makefile to program your board. You can look at the makefile to see the different command options it can run.

Open a terminal and navigate to the directory where you downloaded the program files. (Use the cd command in Mac/Linux.)
Check that your programmer and Hello World board are connected and detected with lsusb. The programmer should show up as something like Multiple Vendors USBTiny and the FTDI cable as Future Technology Devices International ....
Compile the program: make -f hello.ftdi.44.echo.c.make. -f tells make which file to use as the makefile. This will create a .hex file that can be sent to your board.
Send the file to your Hello World board: make -f hello.ftdi.44.echo.c.make program-usbtiny
Set the clock on your Hello World board: make -f hello.ftdi.44.echo.c.make program-usbtiny-fuses

At this point, your board should be fully programmed, so go ahead and disconnect the programmer from your board and from the computer.

Communicating with your Hello World board

Download the Python terminal for communicating with your board through the FTDI header.
Check what port your Hello World board is connected to. Look at the output of ls /dev. This shows the devices connected to your computer. There should be one listed as something like ttyUSB0 (or some other number at the end). That’s your board.
From the directory where you downloaded the terminal, run sudo python term.py /dev/ttyUSB0 115200 (or wherever you determined your board is connected). The 115200 is the baudrate of the device, which was set with the program-usbtiny-fuses command we ran earlier.
A terminal window should pop up. Type a single character, and you should see a response from your board like this: you typed "a". If you want to reset the list of characters, unplug your board from the FTDI header. (If you unplug the cable from the computer, the /dev/ttyUSB* location might change.)

Troubleshooting

There are a lot of places that this can fail along the way. If it does, here are some things (a non-comprehensive list) to check:

Verify that your devices are connected/detected by the computer with lsusb.
Check that you have the right permissions to run what you’re trying to run. (For example, don’t forget to run the serial terminal as root with sudo.)
Use a voltmeter to check that you’re getting power where it needs to go on your board.
Use the “beep test” on the multi-meter to check that things that should be connected are, and that you haven’t accidentally created any shorts. (Check your soldering if either of these occurs.)