Blogs

All Posts (14054)

Sort by

Recent MAV work with AttoPilot

Posted by Dean on March 31, 2009 at 10:58pm

Check out my thread on RCGroups for a recent 8 ounce flying weight plank MAV: http://www.rcgroups.com/forums/showpost.php?p=11923347&postcount=2445Specs:Flying mass: 225 grams (8.0 ounces)Motor: GWS model GWBLM001A for 2s LipoProp: GWS 6050Battery: Common Sense RC 700mA 2sESC: Castle Creations 15 ampServos: 2 HS-55Rx: Berg Stamp 4 with header pins removedControls: Elevon and throttleSpan: 18"Chord: 8"Airfoil: Eppler 186 (very reflexed)Center where motor is: Eppler 186 but 180% thick on top, 140% bottomRx/Autopilot and Battery bays: E186 140% top thick top and bottom.This is a plank flying wing. To get the C.G. forward enough, all gear has to be almost against the wing LE. This means the motor cannot be in the back, however I still wanted this to be a pusher. The solution: motor in the nose with a 3mm carbon rod shaft and ball bearings, 6" long.AttoPilot: This is without case and no header pins. The servos and all sensors are directly soldered to the PCB. The SD card socket is attached to the Atto with right angle headers. The pitot is a 1/8" OD brass tube sticking out only 6mm from the LE. The R/C Rx (Berg Stamp4) is around 2 grams without headers, and this is situated directly on top of AttoPilot. Autopilot + Rx + GPS + thermopile sensors + power sensor is 48 grams (1.69 ounces).The voltage/current sensor is also custom in that it has only 1 shunt resistor. This doubles the resolution (11 mA) and reduces the current range to 45 amps.There is no payload, camera, or modem on this now... however in a 8 ounce MAV package I think it significant to have these standard AttoPilot features:1) practically unlimited onboard data logging of 70 parameters at 5Hz2) Airspeed control (not simply hold)3) Power sensing and mAh abort triggers4) barometric altitude5) FULL SIZE gps (greater sensitivity and lock solidity than the really small GPS)6) all the other stuff (50 Hz attitude, exponential gains, line hold navigation, no pre-flight calibration of anything).I'll be using this to hone the automated landing code that is underway, and perhaps rework the autonomous take off to better suit planes with pusher prop (detection of hand toss then small delay before motor comes on).
Read more…
3D Robotics

Preparing ArduPilot for version 2.1 (with Z sensor)

Posted by Chris Anderson on March 31, 2009 at 10:30pm

Here's how to connect the FMA XY and Z sensors. [Note: the sensors come from FMA with a thin film (usually red) over the thermopile lenses. You have to remove the film before using them.] The basic connections are as shown in this picture:

Cut one of the cables that comes with the FMA XY sensor in half and pull the four wires apart for about two inches. Strip their ends by about a quarter of an inch. Do the same for the Z sensor (you can cut off the fourth wire, the one furthest from the red one, off at the sensor level since it isn't used on that sensor). Twist the red wires and the one next to it from each sensor together, since they'll be sharing a connector. Now it's time to slip on heat shrink tubing. If you have some red tubing, put it on the two twisted-together second wires in from the sides of the cables with the red strip, to mark the positive power cable (yes, that's confusing. V+ isn't the wire with the red strip--it's the wire next to it!). Black tubing goes on the two twisted-together red cables (which are Ground, which is confusingly the red one). Slip tubing on the other three wires, two from the XY and one from the Z senors. At this point the instructions depend on whether you're powering the board from the Rx/ESC, as most people are, or if you're powering the board via the BATT pins. The following is for the standard boards using Rx/ESC power. Notes for BATT power are below in [brackets]. Solder each wire or pair of wires on a five-pin male machine pin header like the below (use the picture above to get the order right, and solder the two ground and V+ wires together at each of those two pins). If you haven't already done so, also solder a five pin female machine pin header in the five holes made by ArduPilot's Batt -,+ and Analog 0,1,2 holes. By combining all the sensor wires in one strip, we can ensure that we'll have the best, strongest connection:

How did we get that otherwise unused Batt + pin on ArduPilot to actually be +5v? By soldering a wire on the bottom from the VCC pin in the FTDI row!

[If you are powering the board from the BATT pins, you'll need to attach the sensors differently. Solder a three-hole female header in the Analog 0,1 and 2 holes, and a two-hole header in the VCC and GND holes in the FTDI row. Solder the three sensor data lines to a three-pin male header in the same order as above, and combine the V+ and GND power lines from the two sensors to a two-pin male header. Connect the matching male and female headers.] Note that for the 2.1 version of the software, the sensor should be placed diagonally on the aircraft so the cable plug is facing backwards (towards the tail) and the FMA logo is at the front, as shown in the picture at the top. If you want the cable facing forwards, you can change that in the code. (look for "#define REVERSE_X_SENSOR 1 //1 = cable behind, 0 = cable front" in the first tab) Here's a diagram that shows how everything hooks up:

Here's a very simple program that will test all your sensor (XY and Z). Just load it on ArduPilot (make sure the board is powered and the GPS is not connected). With the FTDI cable connected, click on the serial monitor icon in Arduino and make sure the speed is set for 9600. The program will prompt you to tilt the sensor in certain directions and then strike any key and hit return when you're ready to take the X and Y sensor readings. Remember that sensor readings inside and near heat sources (like your hand) are nothing like the real thing outside. But it's still a good way to confirm that your sensor is working right.
Read more…

Dreaming of wings

Posted by Brian Hudson on March 31, 2009 at 10:24pm
My name is Brian Hudson. I've been wandering around DIY for a week or two now, and I've decided to start this blog to start interacting with the community, get feedback, and to track progress and thoughts on a project my neighbor and I are starting.My background is in Computer Engineering and Computer Science and I've worked in the software industry for several years now. My neighbor has a degree in Aeronautical Engineering, and we’ve been talking for awhile about a UAV project.In middle school and high school, I built a lot of models, eventually building my first R/C, the Sig Riser 100. This wasn’t an easy plane to start flying with around our large property, so I worked on a couple other models over time. My first flight at a true R/C field was a .40 trainer, although I wasn’t with a real instructor, and my first attempt at a landing ended with a nose dive of epic proportions :PBudget and time kept me from pursuing flight much further once I started college, but I always had a desire to get back to both model building and to get experience with R/C flying. I’ve always enjoyed watching aerobatic maneuvers, but never knew whether or not this would be something I could aspire to.As part of my Computer Engineering / CS degree, I had a design project requirement. A lot of other friends I had did things varying from simple lawn sprinkler controls to more complex client server software systems or mesh networked robots. I was fortunate enough to have a working relationship with a research lab where I was given a project to build a microcontroller based input / output multiplexing interface between an R/C car and an on-board 2 node Beowulf configuration of single board computers. The lab’s main area of research was computer vision and its applications toward studying human vision and neurology. Hence, the car had lots of sensors including web-cams, and the goal of my project was to make the use of this robot to test out algorithms and theories less painful – as you can imagine, grad students working on vision research were able to concoct plenty of algorithms and control schemes that flung this robot all over the place and crashed the onboard computers plenty of times. My project had several interesting features:- Ability to dynamically switch R/C control of the car between the on-board computing cluster and the received signal from the R/C transmitter. This also included the ability to pass “training” data to the computer, so that the computer could attempt navigation based on its video input, and could “learn” from corrections passed in by an observer.- GPS data input. This was another data point that could be read into the system and used for navigation and historical mapping etc.- On-board LCD menu and button interface. Basically, I had a small and simple library that allowed configuration of 5 on-board switches and which displayed a menu on a 4x20 LCD screen. This allowed for simple booting out in the field, with enough flexibility to run several different scenarios and simulations and store data to the onboard disks without having to drag along a keyboard and monitor. Now-days, the ubiquity of wireless networking probably makes this a little outdated, but it was handy back then - A serial protocol which allowed the controlling PC to configure the various peripherals like the buttons and LCD, read and write servo data, read GPS data and restart and recalibrate the various components in case the on board computer crashed in the field.I had a blast building this system, and it was really gratifying to start with a couple PIC microcontrollers in a tube, a few components, some flashing software and an idea and come out with a PCB design and some cool firmware to make this robot more fun to work with. I learned a ton through the whole process, and that’s part of the motivation for this project, to learn more about aviation, and get my hands dirty plugging some parts together.I think at this point autonomous flight is a pretty high goal, as I haven’t really (successfully) flown a plane myself and neither has my neighbor. But I’m certain we’ll have fun going through this process – probably have times of faster development and times of slower development, but overall we should have some fun.Ok – so let’s start with some operating parameters:1) Cost. We’re trying to stick within a fairly modest budget. I don’t think we have an explicit dollar amount limit, but at least from my end, I’m going to be working within my normal family monthly budget, which means I’ll probably be buying a few things each month to bring the project farther along (starting with the dev board and maybe the accelerometers or gyro, later adding GPS module, probably a couple of XBee’s for bi-di telemetry).2) Space. This one might sound a bit weird, but I live in a Condo, and my darling wife and baby don’t want me taking over a whole room with this hobby, so I won’t have space like when I was younger and building full kit R/C planes. We’ll need to start with some sort of ARF.3) Tools. Similar to space, I don’t really want to get in over my head as an electronics hobbyist here – I’m not afraid of soldering (although with a baby, I’m terrified of lead solder  ), but I don’t want to have to set up a whole mini-electronics lab to get this project going. This is a big motivator for my microcontroller platform selection. Currently, I’m trying to decide between an Arduino Duemilanove or the ArduPilot. Duemilanove seems a little more flexible with the shield options and on board USB connector for programming, debugging etc. Yet, I like the fact that the ArduPilot has a dedicated on-board fail-safe microcontroller for R/C control muxing. I’ll have to look back at my college project to see how I handled input muxing there, because I’m pretty certain I had a channel on my radio that dealt with this – so I could probably re-use some of that design.4) No Glo. I’ve dealt with glo engines in the past with my models, and this was just simply too much hassle. I hope that the reduced selection of models and high initial cost of batteries, chargers etc doesn’t prove prohibitive to our budget, but I’m feeling pretty firm about this, and it seems like the rest of this community feels similarly.I’m not sure if there are any other major constraints here. I’m super excited about this, but also trying to keep from burning out by setting expectations initially too high or by getting frustrated by the fact that my time investment here will be subsequent to my day job and family life.So to conclude, I hope that hanging out on these boards will help me gain knowledge from the work of others, and to start with, I’ve got a couple of questions for others with experience here!1) Power supply – I’m looking to use an ESC with a BEC, but if I choose to use the Duemilanove, its power input requirements/recommendations have 6V as the minimum input supply. I believe the R/C standard is 5V. Now, I know that USB is 5V and the Duemilanove is designed to run from USB. Is there something I’m missing here? This is the first potential deal-breaker or the Duemilanove, and I’m really liking its potential here, so I’d love to find a “don’t worry about it” type of answer, even if it meant I might need to do some sort of power isolation for my servos (although that might generate more “help-me!” questions.2) Components – I’m looking for a simple starter set of components including wiring, a breadboard, some common LEDs, caps, resistors etc. Back in school, all of this came as part of the prototyping lab. Wow, I didn’t know how spoiled I was. I’m able to find many of these things piecemeal, and some of these things on sites like SparkFun, but especially regarding the components, it would be nice to find a simple kit, even if there’s some markup over ordering components from digi-key or something. Does anyone have a recommendation here?I’m looking forward to posting again with my next level of investigation, and I hope to hear from you all!
Read more…

Reading Saitek Pro Flight Yoke System Data for UAV Usage

Posted by Matt Fisher on March 31, 2009 at 4:00pm
Here is the (Python) code I used for getting my Saitek Pro Flight Yoke (http://www.saitek.com/uk/prod/yoke.htm) data from the device into something usable. Python has a fantasic pygame library which reads joystick data. This is just a simple script that is short and sweet. This code reads all the motion axis (ie. the yoke, hat and throttles, ) and all of the buttons. Feel free to play around with it. I really dont want to use a RC transmitter for my UAV as I can so so much more with this device. Let me know what you think.And you don't need the Pro Flight Yoke to use this - any joystick will do :)USAGE NOTE: to execute type 'python filenameyousavethecodeas.py'######################## START CODE ##############################import pygamejoy = []# Handel the joystick eventdef handleJoyEvent(e):# Check for joystick axis movementif e.type == pygame.JOYAXISMOTION:axis = "unknown"if (e.dict['axis'] >= 0):axis = 'a' + str(e.dict['axis'])if (axis != "unknown"):s = "%s|%f" % (axis, e.dict['value'])print s# Check for buttonsif e.type == pygame.JOYBUTTONDOWN:if(e.dict['button'] >= 0):print 'b' + str(e.dict['button'])# wait for joystick inputdef joystickControl():while True:e = pygame.event.wait()if (e.type == pygame.JOYAXISMOTION or e.type == pygame.JOYBUTTONDOWN):handleJoyEvent(e)# main methoddef main():# initialize pygamepygame.joystick.init()pygame.display.init()if not pygame.joystick.get_count():print "\nPlease connect a joystick and run again.\n"quit()print "\n%d joystick(s) detected." % pygame.joystick.get_count()for i in range(pygame.joystick.get_count()):myjoy = pygame.joystick.Joystick(i)myjoy.init()joy.append(myjoy)print "Joystick %d: " % (i) + joy[i].get_name()print "Depress trigger (button 0) to quit.\n"# run joystick listener loopjoystickControl()# allow use as a module or standalone scriptif __name__ == "__main__":main()
Read more…

Ground Target Tracking with Road Map Support

Posted by Matt Fisher on March 31, 2009 at 12:03pm
I found this paper titled "Ground Target Tracking with Road Map Support" written by Daniel Streller (daniel.streller@eads.com).http://subs.emis.de/LNI/Proceedings/Proceedings110/gi-proc-110-021.pdf (5 page PDF, 161KB)Its somewhat of a complicated read but very interesting as well.The UAV I am planning to build will have alot of onboard memory which I will use to store road data from a automobile GPA system. This data will be used to properly find waypoint by keyname rather then lat/long. Since my UAV is to have a good camera on it, I am very keen to dig into ground target tracking and autonomous waypoint creation and this seemed like a good start.
Read more…

flight time

Posted by Shawn Blake on March 31, 2009 at 1:02am
Does anyone know how to increase the flight time for an electric rc? I was thinking of finding a way to use solar panels to streatch the flight life. I was thinking of using flexible thin film solar modules from jamco electronics. My goal is to increase the flight time to a minamum of one hour. any suggestions would be appriciated thank you.
Read more…

And The Building Begins

Posted by Blair Davis on March 30, 2009 at 6:00pm


So the desk was clean but it's not anymore! I have started the building of the wings, and the construction is going good here are a couple of pictures, and more will be following shorly, especially when we get to the details in the sweep mechanics, and wing braces and supports.And for the electronic guru's - schematics are just about to be sent to the Fab house! this is going to be a awesome board.
Read more…

1500m altitude video from the Arctic

Posted by Martin Mueller on March 30, 2009 at 5:30am
We are still out on Spitsbergen flying Paparazzi. Finally the camera worked for one flight. Went up to 1500m and down in glider mode. Usually we fly slower downwards...but to have it more interesting we kicked it a little more. See the video athttps://www.youtube.com/watch?v=M1k_TLcQ2icand the corresponding Google Earth file athttp://paparazzi.enac.fr/wiki_images/09_03_29_17_39_11_55.kml
Read more…

Under Construction: A-to-Z Amateur UAV Development Guide

Posted by Paul Marsh on March 29, 2009 at 3:30pm
For the time being, I am going to move development of the flow chart version of an "A-to-Z Amateur UAV Development Guide" to this blog post on my personal page. It is far from ready for prime time and should not get much visibility at this stage. If it leads to a useful guide, then perhaps a link can be added to Chris' "Newbies guide to UAVs" which has top-level post visibility.My personal view of where this is going is not so much of a complete standalone set of instructions on how to build a specific UAV, but rather as an effort to capture and organize the wealth of information that already exists or becomes available. If successful, this guide will save future enthusiasts much time and effort in searching out the information they need to plan and execute their own UAV project.I don't necessarily see the flow chart as the final version of such a guide. This might just be the vehicle to capture the information and then become the framework for a Wiki site as has been suggested. While anyone is welcome to collaborate on the flow chart itself, there hasn't been much response to the original post on this. That's OK. I have decided to press ahead with the project and see where it leads.I intend to use this blog space to request help on specific topics as I develop the chart. Mainly, this will be asking for links that can provide specific information. I will try to find these on my own, but I suspect I will make frequent requests. Also, you might know of better links than the ones I find if you happen to be looking over the guide. If you come across a real gem that should be captured, please pass on that link and I'll fit it in.The following will always lead to the current version of the flow chart:DIY Drones A-to-Z Amateur UAV Development GuideAny comments, suggestions, input, etc. are welcome.Thanks,Paul
Read more…

Pan and tilt camera with basic headtracking and camera shutter based on Nunchuck, Arduino, and Xbee Pro 868

Posted by Reto on March 29, 2009 at 2:00pm
This is finally the post for my headtracking system. I still have some tweaking ahead, but here is the present situation.It is based on following components:- Arduino compatible board (I use a spare ArduPilot board) in the airframe- Arduino compatible board on the ground (I use a Arduino Pro Mini from Sparkfun)

- Nunchuck Wii console handle

- 2 Xbee Pro Rf modems

- a camera on a pan and tilt system

- a cheapo digital camera hacked with a simple transistor shutter- some cables, some resistors, some plastic box to fit components in, etc.Ground headtracking unit features:

- basic headtracking using 2 accelerometers from the Nunchuck device (panning occurs while tilting head sideways; no rotational movement because no compass/gyro is implemented; I got used to this side movement which felt strange at first)- accelerometer data average for smoothing movements- accelerometer circuit on the head (fixed to a baseball cap)- 2 possible calibrations of the accelerometer unit (device or user)- Nunchuck handle in the hand for following specific actions when in autopilot:- front view with square button- bottom view with oval button- digital camera shutter with both buttons- two axis joystick trim to center camera position at will- visual (led) and audible (buzzer) feedback on handle actions- powered with a 2 cell 1000 mAh lipo- voltage monitoring with audible alarms (2 levels: 3.3v/cell and 3.1v/cell)- accelerometer data segregation to keep serial data rate very lowAirborne system includes:- 180 degrees camera pan- 90 degrees camera tilt (from front view to bottom view)- automatic front view after 10 seconds without headtracking data- digital camera shutter from ArduPilot digital pin D13Well, I think that's all for the features. I am sure there could be a lot of improvement in the code. I am no programmer, so I tried to do it and document it as best as I could.There are two code parts:- ground headtracker: head_track.pde- airborne system: pan_tilt.pdeI tried to record some video with my digital camera, but the light was so bad in my living room (in the evening), that I'll postpone posting a video. Instead, I added pictures into my gallery so you may check them out.this project is largely based on the code posted by Andrea Salvatore. Thanks Andrea for the nice How To.So I started using code written by others and modified it on the fly. If you recognize parts of your code, please don't be mad at me but send me a note instead, so I can duly acknowledge your contribution here and in the code. Thanks for your understanding.
Read more…
3D Robotics

A newbie's guide to UAVs

Posted by Chris Anderson on March 28, 2009 at 2:00pm

3689312509?profile=original

What is an amateur UAV?

An Unmanned Aerial Vehicle (UAV) is an aircraft that has the capability of autonomous flight, without a pilot in control. Amateur UAVs are non-military and non-commercial. They typically fly under “recreational” exceptions to FAA regulations on UAVs, so long as the pilots/programmers keep them within tight limits on altitude and distance. Usually the UAV is controlled manually by Radio Control (RC) at take-off and landing, and switched into GPS-guided autonomous mode only at a safe altitude. (Confused by all the acronyms and unfamiliar terms in UAVs? A glossary is here.)

What do I need to make one?

---1) An RC plane, muticopter (quadcopter/hexacopter/tricopter, etc) or helicopter. You can buy them ready to fly, including autopilot, here. If you want to build your own, these instructions are a good starting point.
---2) An autopilot, such as Pixhawk (see below)
---3) Optional: a useful “payload”, such as a digital camera or video transmission equipment

What does DIY Drones have to offer?

The DIY Drones community has created the world's first "universal autopilots", ArduPilot Mega (APM) and its next-generation big brother, Pixhawk. They combines sophisticated IMU-based autopilot electronics with free autopilot software that can turn any RC vehicle into a fully-autonomous UAV.

A full setup consists of:

  • 3689312472?profile=originalPixhawk autopilot: The electronics, including twin processors, gyros, accelerometers, pressure sensors, GPS and more (shown at right). Available from mRo.
  • Mission Planner software:  Desktop software that lets you manage APM and plan missions, along with being a powerful ground station during flights and helping you analyze mission logs afterwards.
  • Autopilot software (automatically loaded by the Planners):

You can buy Ready-to-Fly UAVs planes from mRo and multicopters from HobbyKing

3689312382?profile=original

 

 

Last but not least is flight safety. The RCAPA guidelines are an excellent set of checklists and do's and don'ts, so please refer to them.

Also, here's the FAA's official word on what's legal and what's not.

3689312529?profile=original

Read more…

My Easyglider Pro Conversion

Posted by Bryan Cuervo on March 28, 2009 at 12:17pm
I chose the Easyglider for its size, high L/D and ease of modification/construction with Elapor foam. There is plenty of room to slide in up to a 3000mAh Lipo pack under the wing but, as Chris has mentioned, there isn't a lot of room under the canopy. I modified the canopy with a tab in the front and magnet aft for attachment. The original, forward canopy hold down tabs were left off and it turned out ArduPilot was almost a perfect fit in their place (see pictures).Just waiting for weather to improve for her maiden voyage. Has anyone flown this plane yet with ArduPilot 2.0? If so, any recommendations on setting the gains?

Read more…
T3

UAV DevBoard users: Wait for MatrixNav firmware

Posted by William Premerlani on March 28, 2009 at 10:39am
If you have a UAV DevBoard, and are anxious to do some flying with it, you should skip the GentleNav firmware and wait for MatrixNav, it is almost done, and will perform a couple of orders of magnitude better than GentleNav.GentleNav was originally developed for my previous board, which used the ET312 GPS, 2 gyros, and 2 accelerometers. The algorithm was rather simple, but worked well enough and I used it for several years.This season I decided to design a better board to use 3 gyros and 3 accelerometers to improve performance. Recently, I have been working with Paul Bizard on a "direction cosine matrix" approach to estimating orientation. It shows great promise, and is almost done.In the meantime, I thought that owners of the new board would want something to fly with, so I ported the GentleNav firmware from my previous board to the new one. Today was the first day I actually flew it, up until now I have been doing bench testing.Well, GentleNav does not work as well on the new board as it did on the old board. I traced the problem to the EM-406. It turns out that the dynamic response of the EM-406 is not nearly as good as that of the ET312. It takes the EM-406 around 15 seconds to respond to a 90 degree turn, while the ET312 responds almost instantly. Because of this large dynamic time lag, the GentleNav firmware is not stable in the return-to-launch mode.I could probably experiment with the feedback gains and get GentleNav to work with the EM-406, but since MatrixNav is almost done, I have decided to declare GentleNav to be obsolete and to focus my time on finishing MatrixNav, which should be available in a few days, a couple of weeks at the most. MatrixNav will completely resolve the issue with the dynamic delay, since it uses mainly the gyros rather than the GPS for direction information. The direction cosine matrix algorithm has a convenient way to compensate for GPS delay. MatrixNav is almost done, but I want to perform extensive flight testing before releasing it.So I suggest you wait for MatrixNav before using your UAV DevBoard in flight. Of course, if you do not want to wait, you are welcome to experiment with GentleNav, but I do not recommend it.In the meantime, you might want to try the roll-pitch-yaw demo to gauge what the performance of MatrixNav might be.Bill Premerlani
Read more…

ArduPilot failsafe RTL in case of out of RC range

Posted by Michal on March 27, 2009 at 4:13pm
Hello,My new board has arrived (thank you Chris) and is working fine. I am an FPV flyer at the first place and automatic RTL mode is so tempting for me... Arduilot doesnt want to cooperate with my Corona RP8D1 in case of loosing RC signal. I added two little friends to the wire mess inside my small FPV platform.This is one of them:

First one is added between IN CTRL of ArduPilot and RC Rx. Second one between CPD4 RMT and Rx. This way I am not afraid of loosing the airplane during long runs.I think most of todays RC transmitters would benefit from such setup.
Read more…
3D Robotics

The Space Shuttle's autopilot

Posted by Chris Anderson on March 26, 2009 at 4:30pm
Sparkfun and Jack Crossfire have been diving into the archives this week and looking at Apollo and Space Shuttle electronics. You think you've got tough memory and MIPS limits? Ain't nothing like what the NASA engineers had to deal with (punch card source code shown at right!). They went to the moon with computers not as powerful as ArduPilot's failsafe chip, to say nothing of its Atmega168. From a great Sparkfun roundup:
Apollo Guidance Computer ATmega168
$15M $2
55W Power
 0.055W Power
~1 MIPS?
 20 MIPS
70 lbs.
 0.0022 lbs.

Meanwhile, Jack Crossfile digs into the Shuttle's technical details and finds similar evidence of massive inginuity by NASA engineers: "The shuttle runs at 1Hz during liftoff & 6Hz in orbit. Most electronics R manually shut down in orbit to save fuel. The gyros were originally sampled to only 4 bits because they didn't have enough clockcycles. Full scale range was based on liftoff oscillations, not orbit. The shuttle doesn't use PID loops because there's not enough fuel to constantly hunt for equilibrium. It uses XY plane feedback. Given a start & end state, the computer looks up the exact required burn time in a table. The pilot has to manually select lookup tables based on payload, robotic arm position, & docking. The standalone shuttle is a rigid body while a docked space station & extended robot arm turn it into a flexing body. They calibrate the tables using very accurate mission simulations in software which accurately predict the center of gravity, moments of inertia, flexing modes, aerodynamics, & noise. On STS-1 they had an unpredicted oscillation during tank separation which almost killed the crew. Also, most of the computers failed on STS-1 because of floating solder balls." All info from here.
Read more…