18 posts • joined 11 Aug 2009
This fits within the definition of engineering
Engineering; the discipline of dealing with technical artifacts that don't work. You start with something that is totally nonfunctional (indeed, nonexistent), perform engineering activity on it, and over time produce something that is nonfunctional at progressively higher levels. Just as soon as it all works, it ceases to be the subject of engineering, and the engineer goes on to something else that doesn't work (yet).
Viewed in this context, that overlooked blown fuse is clearly part of the engineering game. Look at it this way; at least you didn't vaporize an entire crew of astronauts because of a problem you'd been explicitly warned about. Plus, you HAVE a fuse, and the worst-case consequences of the error are noncritical. All part of the game.
Beautiful, certainly, but what about flight stability?
I hope this craft has a decent autopilot; with no dihedral on the wings, it's not going to have any inherent attitude stability, meaning that it won't glide stably by itself. What do you have planned in terms of flight testing?
Nearly all free-flight model aircraft are designed to have lots of inherent stability to overcome the absence of an active control system. An active autopilot significantly mitigates this requirement, but tuning the autopilot up is a project all by itself. I hope you folks have a few extra copies for the initial test flights.
So, was there a parachute deployment?
Since you planned on a balloon-burst at a set altitude (and the rig wasn't pulverized on impact with Terra Firma), there must be a parachute arrangement for the balloon payload. Did it function as expected?
I work with a translator, and we have multiple versions of Microsoft Office on hand (some on quarantined PCs so they don't eat one another) specifically so we can deal with documents we receive in Word Version ~!@#$, which frequently aren't even compatible with earlier OR later Word versions. We cannot quite leap away from Microsoft Awful because of compatibility fears. It's not that LibreOffice or OpenOffice.org is incompatible with Microsoft Office; it's that they introduce a few extra incompatibilities. largely because Microsoft's file formats are obscure, poorly implemented, obfuscated trash.
While the various versions of Word interoperate poorly even with one another, we need to reduce file-format pain as much as possible, 'cause the translation clients have NO clue about this issue, and we will get the blame for any format weirdness that crops up. Sticking to the crummy software that created the document will, at least, eliminate another headache we just don't need.
In a more desirable environment, Microsoft and everyone else would be using open file formats, and work life would be easier and more productive. I've never really understood the Microsoft mind set; if they played well with others instead of being monstrously evil, I think they would still be the major player they now are, and still approximately as profitable. They just wouldn't be hated and despised to anything like the degree they now are. (Was it really worth it, Bill?)
More smug-gling ....
One of my mech-e colleagues took one look at this, and we immediately agreed, "Must be fake. They'd never get decent torque with slots that shallow, and it would be trivial to bypass with a flat blade screwdriver."
One, if you're going to use the pull-pin release as pictured, the pin will only respond to pulling in a narrow range of angles (i.e., pulling sideways on the pin does nothing). This may be good, may be bad. If it's bad, an alternate release would be to machine a groove 'round the circumference of the actuating rod, and use a flat, forked piece of metal with a slot that fits into the groove in the rod. The forked bit does the work of the safety pin, holding the rod back against some solid surface through which it passes. Attach the pull cord to other end of forked bit, and pulling in any direction more or less perpendicular to the axis of the rod will release it. In effect, this gains you a wider acceptance angle in one direction.
Another thought: To reliably detect balloon-pop, put a smaller, mostly deflated balloon (call it, say, "Mini-me") inside the main balloon through the neck, with said smaller balloon being connected to a tube running out through the neck of the main balloon. The interior pressure of the main balloon will remain above ambient pressure until it bursts, and up to that point the pressure in the mini-me balloon will do so as well. At main-balloon-pop, mini-me will be exposed to low ambient air pressure, and will inflate (and possibly pop as well, which is OK). The interior pressure of mini-me, and/or its abrupt drop, should be usable for triggering purposes.
Dunno if these are goo ideas, mind, just different ones.
Ah, cold start test.
Much now becomes clear, though it'll frost up in the cold no doubt. ;-)
Rocket motor firing toward glass plate? Ummm...
Have you considered the effect of a jet of rocket exhaust on the proposed glass-plate lid of your vacuum chamber, and the effect on the vacuum therein of all that exhaust gas that's being generated? It occurs to me that you may experience a loss of vacuum from either 1) the glass plate being cracked by the exhaust gas jet, or 2) the evolved gas quantity raising the internal pressure and possibly blowing the lid clean off.
Some possible solutions: a) Increase the chamber volume considerably; this will reduce the effect of the added gas volume on the chamber's internal pressure. It would be instructive to know just how much gas the motor generates throughout its firing, as this may require an improbably big chamber. b) Put the viewing window at 90 degrees to the exhaust jet rather than bang in its path. To quote Larry Niven, "A reaction drive's efficiency as a weapon is in direct proportion to its efficiency as a drive."
Elevons are not such a problem...
We RC modelers operate V-tail configurations routinely. There are simple mechanical and simpler electronic methods for making this work well, so it's not really an issue. Most mid-range RC transmitters do elevon mixing, and an on-board controller could certainly do that as well.
Another advantage of a Very Long Tether
is that the natural frequency of oscillation of a very long pendulum is very low, which acts to your advantage.
Put a small drag chute or streamer on one end of the truss, and it will remain pointed upwind, so the rocket will take off crosswind, rather than straight into the balloon. At that point, it matters not whether the balloon is upwind of the truss or downwind, it'll be over one or the other end of the truss and out of the way of the launch.
I'd be very interested in seeing some flight testing of the plane
I'm a long-time RC flier, and, for the record, NOT interested in pointless carping about the perceived deficiencies of this project. I think what you've achieved is brilliant. First-run tests always have glitches, so being able to build, launch, release the payload, and recover both carrier and bird deserves MUCH praise.
Now to the burning-curiosity part. How well does the Vulture 1 FLY, when, say, hand-launched in dead calm off a slight rise over a field of grass or the like (to avoid damage on landing, natch)? A few such tests could go far toward understanding the bird's behavior when released at altitude.
From the video footage, it looks like the bird did a full roll when released, then seems to have settled down into some sort of conventional flight. One wonders if its weight distribution or control trim caused it to circle; that would account for its landing near the carrier vehicle, I would expect.
Of course, the Vulture 1 is now a priceless artifact (any interest from the Guinness Book folks?), but have you folks any interest in characterizing the bird's flight behavior for posterity?
Tissue covering and high-tech options
Just FYI, the primary US aeromodeling association (Academy of Model Aeronautics, www.modelaircraft.org) has a plentitude of resources and articles on stuff like this, several of which I've read in their magazine, Model Aviation. I'm certain our British partners have similar resources, but more info sources are always nice...
For ultralight covering on wee-tiny-and-feather-light planes, the modern thing is "microfilm," which appears to be a high-tech version of cling-wrap. Dunno what its low-temperature characteristics are (which is likely to be critical for any plastic-based covering), but it is an option.
Heavier-duty self-adhesive shrink-on coverings like MonoKote, Ultracote, and similar are likely to be too vigorous in the shrinking department for this lightweight structure, BUT it's worth checking them out as options, 'cause some are less shrinky than others. For radar reflectivity, aluminized Mylar (Space Blanket stuff) may be worth a thought, though attaching it taut and wrinkle-free would be a nightmare, as it doesn't heat-shrink. Very snazzy look, though.
All that being said, the classic tissue and dope solution may well prove to be the most practical solution.
Let's hope they didn't do the entire Colditz thing...
... and plant spores of dry rot throughout the structure to destroy it in 50 years if all else failed.
Let's not forget OpenEmbedded and Angstrom, shall we?
The OpenEmbedded Linux distro (http://www.openembedded.org), which is Debian-based, IIRC, provides excellent ARM support, and its Angstrom offshoot (http://www.angstrom-distribution.org/) has specific support for TI's OMAP processor (most notably the insanely cool TI-inspired BeagleBoard single-board computer), as well as the über-miniature Gumstix SBCs.
There's a massive amount of software available in these embedded distros, and they're extensively used in embedded applications. One hopes that common sense and support for existing development ecosystems doesn't fall victim to the not-invented-here syndrome. Concerted support from major industry players for a particular set of tools could really help things along.
Another reason APIs can be undocumented...
And one that I, personally, was bitten by when developing for the original 512K Mac, is that Apple, in their finite wisdom, may decide to yank the code to keep others' apps from competing with Apple-written code.
Back in the day, I worked on a project that planned to use the Mac SDK's CoreEdit package (full-function text editing with fonts and styles, basically equivalent to MacWrite) to implement text markup in a networked writing-lab system. Came the day we tried to link those libraries into our test app, the headers and libraries were all missing, though they were still listed in the SDK documentation. Apple bluntly told us they'd yanked the libraries for competitive reasons, and we had to devise crummy workarounds.
With this in mind, it doesn't take much imagination to tconclude that Apple might well hold a few cards up its sleeve in the form of perfectly functional but undocumented APIs.
We've seen this same pantomime in the US
(Disclaimer. I'm an Amateur Radio operator, so I may have a certain inherent bias.)
Gee, now where else have we seen this same farce played out recently? There have been BPL (Broadband over Power Line) trials in the US, encouraged by the FCC, many of which were proven to cause harmful interference to licensed users (primarily Amateur Radio) and violate FCC regs. Enforcement was, to put it politely, lax. It took an organized, well-funded legal and regulatory challenge to beat this back.
The primary argument in favor of BPL is that it's cheaper than running proper kit, i.e., coax or optical fiber, especially in underserved rural areas, and gets the utility companies in on the Internet gravy train. The drawback is that power lines make great radiating antennas and lousy broaband data conduits. Performance has been poorer than advertised, interference problems worse than promised, and the economics haven't turned out well, either.
While it may have useful application in some regions, wide use of BPL is a Bad Idea, and the sooner it is staked in the heart and buried with a head of garlic in it, the better.
Cold temps, frozen release mechanisms, and reducing weright
Here's my $0.02 on barometric release mechanisms. Keep it simple, and think about the COLD. I was about to suggest an electronic solution based on a chip pressure sensor (the electronics weigh little if you use tiny surface-mount chips and avoid heavy packaging for the circuitry), but batteries tend to freeze at -40 C. Still, it may be more workable than a mechanical system. You may need to use heaters (probably left behind on the balloon at release) to keep the electronics functional.
For a mechanical release system, consider the flat, disk-shaped bellows used in an aneroid barometer (but filled with air so it expands at altitude to trip a release lever); simple, can be calibrated to operate at the right pressure/temperature, should be very reliable.
Speaking of very cold temperatures, that's going to be THE major issue at altitude; making the systems (primarily the batteries) function at those cold temps. By the way, the cold will raise hob with most mechanical release mechanisms like the syringe-plunger actuator.
Hypobaric testing is of minor importance compared to low-temperature testing that mimics the temperature profile of the intended ascent.
Here's another thought on electronics, light weight, and thermal issues: Sandwich the electronics between flat sheets of thin foam plastic that form the fuselage/wings; you can get flat batteries that can be insulated this way, too. For structural strength, you cannot go wrong with a strip of carbon-fiber tape as a wing spar. This is frequently used for RC model sailplanes; glue the tape to the top and bottom of a floppy foam wing, it becomes MUCH stiffer.
Another thought on weight: If using off-the-shelf electronics, strip off all the plastic cases from everything to pare down the weight.