Slashdot Mirror
The Beckoning Promise of Personal Fabrication
posys noted an interesting talk from Neil Gershenfeld's called "The beckoning promise of personal fabrication". It's a TED talk which I've found greatly enjoyable in the past, and is worth your time, assuming you have 20 minutes to see something really neat.
If you are interested, you can also return to the original TED page.
You're not looking forward far enough. The future of personal fabrication machines lies with nanotechnology. Imagine downloading the schematic for a new video card, feeding in the raw material components, and watching the nanotech gobble it up and crap out a piece of engineering developed with precision at the molecular level.
I agree with you completely. I'm a mechanical engineer and do a lot of prototyping and in my experience stereolithography is a very niche tool. We've got one in my lab and it's used a fair bit, it's pretty good for small plastic parts that must be made in 3D, but that turns out to be a surprisingly small section of useful parts. We've got a 120W laser cutter too, and it rocks. Material is cheap, the machine is extremely fast, and with a good designer almost anything can be made. This last month I made a small roomba style robot for a competition: 3 days in CAD, 2 hours on the laser cutter and 2 hours in the machine shop and I had a great machine, and I could make another in 4 more hours, and another ad nauseum.
A part from any of these rapid prototyping machine is almost always useless by itself. You need hardware, motors, metal shafts, electronics, different materials, and some skill in putting it all together to make much of anything interesting. There might be a revolution, but it's for the people that have been fabricating for years anyway who are finding new and better ways to do the same jobs. I took a manufacturing class with one of the pioneers in applications for stereolithography, it's a useful process with some niche applications, but no revolution. It's no personal computer, life is a little harder when you're pushing around real matter instead of information.
You gotta find first gear in your giant robot car
The interesting question to me is what layer of abstraction did you have your gear change fix at?
Somewhat off topic, but anyway... Gear changing was abstracted to "change to desired gear" at the Galil motor controller, which is a programmable device interpreting a simple little programming language of its very own. The higher level computers would send it a UDP packet with the desired gear number, and every 50ms, read back the status. During gear changing, it would report "busy", and once gear change was complete, the new gear number would be reported.
We had a GUI for debug, showing various buttons and meters. The transmission was represented with "D", "L", R", and "N" buttons. The current gear showed in green. During a gear change the button turned yellow, then green once gear change was complete.
At the next level up, the "speed server", running on a QNX machine, was responsible for throttle, brakes, and transmission. It handled the interlock conditions for gear changing (vehicle speed zero, brakes locked, RPM at idle). The speed server was basically doing a "cruise control" job. It also handled the "rollback" problem.
The level above that, the "move server", took requests like "advance forward 20m at 3 m/sec with turning radius 30m", and issued commands to the speed server and steering system. The move server understood stopping distance, including hills, and had an input from the simple anti-collision radar to stop if a big obstacle was in range. Move requests were replaced with new ones every 100ms by the map system.
At the level above that, the map server/planner, operating at "back seat driver" level, was in charge of deciding where to drive. It didn't have to worry about vehicle dynamics. It just decided when backing up was necessary, and issued a backwards move. This would result in everything winding down to the vehicle stopped/brakes locked/engine idle condition, a gear change, a brake release, and acceleration.
We lost the Grand Challenge, but the vehicle drove itself and never hit anything. We had about +- 2 degrees of compass noise, and that was enough to get the LIDAR-built map out of sync. The vehicle would stop, rescan, rebuild the map, and recover, but that was too slow. We tried to get by without a $40,000 FOG gyro, heading from dual GPS phase, or SLAM, and that wasn't good enough.