It basically boils down to a lack of background knowledge. As an electrical engineering student who is doing a masters thesis in a very computer-science-y domain, I sometimes feel disadvantaged. As a problem-solver, my weakness is that I prefer to figure out solutions on my own rather than search for other people’s solutions in journals and textbooks. This is certainly a fun way to go about life, but it’s rather inefficient when it turns out that my solution is some well-known common knowledge in the field, and I just had never heard of it before because I didn’t do any reading at the outset. So I could have saved a lot of time NOW if I had learned it EARLIER. I’m particularly affected by this situation lately; I’m reading my thesis (the topic of which is parallel operating systems) and realizing that I spend two pages elaborating on how I’ve added a layer of protection between user threads and the kernel by only giving threads indirect references to kernel resources. But it turns out Linux (and probably everyone else in the world) has been doing this since before I was born, so I feel like I’ve wasted the reader’s time.
I sure haven’t posted anything in a long time, and this post sure isn’t about electronics or helicopters or anything like that (at least not directly, and not for most people), but I feel compelled to share this essay, if only for the sake of having one more hyperlink backalley leading to it on this web so that, in spite of the inconspicuousness of this blog, the odds that someone might stumble upon it through a series of random clicks is a teensy tiny fraction of a percentage higher than it was before this posting.
I’ve come across this essay before, but it has just resurfaced for me again. I’m amazed by how loudly Paul’s ideas resonate in my heart, and I’m certain this is a piece that future-Mike will find as fascinating and inspiring as present-Mike does, though probably for different reasons given his situation in life. I hope that by posting it here I’ll help at least one other person to discover it. (If nothing else, I know I’ll help future-Mike find it!)
This weekend was the big Marquette Engineering Open House; a time for the new prospects to come check out the facilities and compete with each other for a chunk of scholarship money. I was asked by the one and only Prof. Jacoby if I’d be willing to consume a laboratory for demoing my flashing lights for the students and parents. Of course I agreed to it — Jacoby’s charm is a powerful force.
A new event made for a good opportunity to take on the problems that were plaguing HeliPOV in its current state. So I finally got back to working on the blades last week.
Read the rest of this entry »
I’d just like to point out that I have created a page with links to the HeliPOV source files. The page is possibly linked at the right side of this post, but is definitely linked by these words. Is it redundant to add a post to ones blog simply to inform the readers that a page has been added to ones blog? Probably. Just wanted to get the news out front and center.
This post discusses the current status of the HeliPOV. Much progress has been made, but there are some very puzzling problems that I’m dealing with.
Once I got the blades balanced and the heli in the air, I got to work on the microcontroller firmware. After spending a long evening trying to get the whole thing working at once, I failed. But I did decide that as a reward to myself, I should take the heli for an indoor test flight with the non-working firmware loaded. If this was doing what it was supposed to, the blades would look like they were a pizza sliced up into 8 pieces. Instead, they’re just a disc of color. Still, it was fun to fly it in the math building and disrupt everyones studying for a few minutes.
Thanks to the help and expertise of the veteran fliers at ABC Flying Field in Concord, I was able to precisely balance the weight and the span-wise center of gravity of the blades to within 0.01g and less than a millimeter, and the vibrations are almost completely eliminated! Turns out the small imbalance between the blades in the z-direction had very little to do with the vibrations I was having; the span-wise balance was the key.
It doesn’t fly.
I finished fabricating the second blade at around midnight. After that, it was time to balance them. With some slightly crude instruments, I got the blades to within about 0.1 – 0.2g of each other, and the difference in their length-wise center of gravity was within about 1-2 millimeters. I thought this should be good enough to get the heli decently stable with the blades spinning. A slow spin-up instantly revealed that it was NOT good enough. The thing shook so violently that I thought for sure it would rip itself apart, or at LEAST bend some of its shafts if I tried spinning up to flying speed.
The next step in the project was fabricating the blades. It wasn’t until now that I noticed a problem with my PCB design. Knowing that I would have to somehow determine the angular position and angular velocity of the blades in flight in order to properly time the flashing of the LEDs, I had incorporated a hall effect sensor near the outside edge of the PCB. I had assumed I could mount a permanent magnet somewhere on the body of the helicopter in such a place that it would be detected by the hall sensor once per revolution. The problem with this was that my helicopter’s flybar is located underneath the rotor blades, and the permanent magnet would be struck by the flybar if it were positioned underneath the spot where the PCB swings past.
Now that I had an idea of how the hardware needed to be connected, it was time to design a PCB. For this task I used the free version of Cadsoft Eagle. I hadn’t ever used Eagle before, so it was a bit of a learning curve. But after several hours and a few online tutorials, I found the program to be quite capable without being overly complicated. A word of advice for anyone new to PCB design — it’s a step that should be done in parallel with searching for parts from your favorite retailer.
The best way to start a new project is to just jump into it. So for the heli lights, my first step was to prototype a POV display. I wanted to use an AVR microcontroller because I already had a programmer and some chips that I bought for other projects that I never got around to doing. The extent of my microcontroller knowledge didn’t go far beyond reading pushbuttons and lighting up LEDs, but I figured a POV display was pretty simple anyway, so this should be fairly easy to do. I looked to LadyAda’s SpokePOV for inspiration. She uses some 74HC595 shift registers with built-in latches to switch the LEDs on and off.
The 74HC595 is an 8-bit shift register. By daisy-chaining four of these chips together, I could address 32 LEDs individually and simultaneously using just a handful of output pins from the MCU. Unfortunately I did not have any 74HC595s on hand, but I did find some 74LS164s to use. These are also 8-bit shift registers but they lack the built-in latch of the 595s. To handle latching, I fed the output of the registers to some 74LS273 octal D flip-flops and used the flip-flop outputs to drive the LEDs. Within a couple of hours, I had my prototype built and spelling “LUKE” when I waved it through the air. (“LUKE” because that’s my roommate’s name, and I wanted him to be excited about what I just built.) Since it’s just for proof of concept, and since I was using a small breadboard, the prototype only used 16 LEDs. I knew that I wanted 32 LEDs for my blades, but I figured if I could daisy-chain two registers successfully, then doing the same to four of them should be no problem.