Early Days on Street View

Down until I'm done talking to Google about this post.

Sensors, Survey and Surveillance from Space

The SkyBox satellites are the first to use area array rather than pushbroom sensors for survey work, but they certainly aren't the first to use area array sensors.  I think the first satellites to do that were the KH-11 surveillance satellites, versions of which are still the principle US optical spysats in use today.  The first KH-11s sported area array sensors of about the same resolution as a standard definition TV.  The most recent KH-11s probably have a focal plane similar to this tiled 18,000 x 18,000, 10 micron focal plane (shown below, that circle is a foot in diameter).

Optical spysats have two missions; call them surveillance and survey.  When you already know where the thing is, that's surveillance.  Response time matters, but throughput is usually not a big deal.  When you don't know where your thing is, or you don't even know what it is yet, you are doing survey.  Throughput is king in survey work, and if response time matters, you have a problem.  Coast Guard aerial search and rescue, for example, has this problem.  You can read about the difficulties of search at sea in this NY Times article on rescue of a fisherman last July.

General Schwarzkopf said after the first Gulf War that spysats (he must have been referring to the earlier KH-11s) could not provide useful, timely imagery.  He was comparing single pictures of targets after a hit to the target camera footage of his planes, which gave him continuous video snippets of the target before, during, and after a hit.  These videos were very popular at press conferences and with his upper management.

Satellites are excellent for getting access to denied airspace -- there is no other way to take pictures inside China and Russia.  But in Iraq, Afghanistan, and Pakistan they are completely outclassed by airplanes and now drones with long-range optics (like the MB-110 reconnaissance pod which I still haven't written up).  In a 20 year battle against irrelevancy, I suspect that getting near-real-time imagery, especially video, from orbit has been a major NRO focus.  I'm sure the Block IV KH-11 launches in 2005, 2011, and recently in August 2013 can all do real-time downlinks of their imagery through the SDS satellite constellation.  However, the second part of real-time is getting a satellite into position to take the picture quickly.  The three KH-11s in orbit often cannot get to a surprise target in less than 30 minutes, and cannot provide continuous video coverage.  Guaranteeing coverage within 30 minutes would require dozens of satellites.  Continuous coverage, if done with satellites 300 km up, would require around 1000.  The KH-11 series is expensive (they refer to them as "battleships") and the US will not be launching a big constellation of these.

The Next Generation Electro-Optical program, which started in 2008 or so, is probably looking at getting the cost of the satellites down into the sub-$500m range, while still using 2+ meter telescopes, so that a dozen or two can be launched over a decade within a budget that NRO can actually sell to Congress.  My guess is they won't launch one of these until 2018.  In the meantime, SkyBox Imaging and ExactEarth, who are both launching constellations of small imaging sats, will be trying to sell much lower-resolution images that can be had more quickly.  These civilian operators have 50-60 cm apertures and higher orbits, and so can't deliver the resolution that NRO and NGA customers are used to, and they can't or don't use the SDS or TDRS constellations to relay data in real time.  (SkyBox can do video, but then downlinks it 10 to 90 minutes later when they overfly one of their ground stations.)

The second spysat mission is survey: looking for a needle in a haystack.  From 1972 to 1986 we had this in the form of the KH-9 Hexagon, which shot the entire Soviet Union every 2 to 4 months at 1 to 2 foot resolution.  The intel community at the time could not search or inspect all that imagery, but the survey imagery was great once they'd found something surprising.  Surprise, a new site for making nuclear weapons!  Survey answers the question: What did it look like during construction?  Or, How many other things like this are there?  Nowadays, Big Data and computer vision have got some handle on finding needles in haystacks, but we no longer have the KH-9 or anything like it to supply the survey imagery to search.  We still use the U-2 for aerial survey imagery, but we haven't flown that into denied airspace (e.g. Russia and China) for many decades.

From 1999 to 2005 Boeing ran the Future Imagery Architecture program,which was intended to make a spy satellite that could do radar, survey, and surveillance.  The program took too long and ran way over budget, and was eventually salvaged by cancelling the optical portion and having the team design a synthetic aperture radar satellite, which did get launched.  (Apparently this was the successor to the Lacrosse radar satellite.)

As I wrote, SkyBox does survey with a low-resolution area array.  They would need about 16,000 orbits to cover the entire surface of the earth, which is 2.7 years with one satellite.  I'm sure they can optimize this down a bit by steering left/right when over the ocean.  But this is 70 cm GSD imagery.

Two of the telescopes designed for FIA were donated to NASA in 2012, and the few details that have emerged tell us about late 1990s spy satellites.  From 300 km up, they could deliver 7 cm imagery, and had a (circular) field of view of about 50,000 pixels.  This could have been used with a 48,000 x 16,000 pixel tiled focal plane array.  Using the simple expedient of shooting frames along the line of the ground track, the ground swath would have been 3.2 km wide, and could have surveyed the entire Earth in about 2.7 years (the same number is a coincidence -- spysats fly at half the altitude and this one had twice my presumed field of view for SkyBox).

However, to keep up with the ground track pixel velocity, the sensors would have to read out at over 6 frames per second.  That's almost 5 gigapixels per second.  I don't believe area array sensors that big can yet read out that fast with low enough noise.  (The recent Aptina AR1411 reads out at 1.4 gigapixels per second, but it's much smaller, so the column lines have far less capacitance.)

The large number is not a result of the specifics of the telescope or sensor design -- it's fundamental to high resolution orbital survey.  It's just the rate at which the satellite flies over ground pixels.  Getting 5 billion tiny analog charge packets to A/D converters every second is hard.  Once there, getting 20 gigabits/second of digital data to the ground is even harder (I don't think it's been done yet either).  I'll defer that discussion to a later post.

Pushbroom sensors are more practical to arrange.

• The satellite simply stares straight down at the ground.  Attitude corrections are very slow.
• It's easy to get lots of A/D converters per sensor, you simply add multiple taps to the readout line.
• It's easy to tile lots of sensors across the focal plane.  You stagger two rows of sensors, so that ground points that fall between the active areas of the first row are imaged by the second row, like this focal plane from ESA Sentinel-2.  Once stitched, the resulting imagery has no seams.

Tiled area array sensors are more difficult, but have the advantage of being able to shoot video, as well as a few long exposures on the night side of the Earth.

• The image must be held steady while the field of view slides along the ground.  Although this can be done by rotating the whole satellite, survey work is going to require rapidly stepping the stabilized field forward along the optical path, several times a second.  Fast cycling requires a lightweight optical element, usually the secondary mirror, to have a fast and super precise tip/tilt mechanism to track out the motion.  Cycling this element back into position between shots can add vibration to the satellite.
• While the secondary mirror is moving the image back into position, the pixel photodiodes must not accumulate charge that affects the values read out.  This typically means that either the cycling time can't be used for readout, or (as in the VisionMap A3) the sensor is an interline CCD with two capacitors per pixel, one of which is shielded.  With this choice comes a bunch of minor but annoying problems.
• In one line time, charge is transferred from the pixels all the way across the array to the readout.  The bit lines can be long and capacitive and add noise.
• Take another look at the first pic in this blog post, and note the seams between the active arrays.  These are annoying.  It's possible to take them out with clever combinations of sparse arrays and stepping patterns.

Lenses generally resolve a circular field of view, and pushbroom sensors take a rectangular stripe down the middle.  It's possible to put an area array sensor in the leftover upper or lower crescent around a pushbroom sensor.  This gives a smaller area sensor, but in the context of a 50,000 pixel diameter focal plane, a "smaller" area sensor might be 10,000 pixels on a side, with 50 times the pixel count of an HD video sensor.  This allows for a 10:1 "digital zoom" for context with no loss of display resolution.

If I were building a government spysat today, I'd want it to do survey work, and I'd make surveillance the secondary mission.  Airplanes and drones are better for most surveillance work.  I'd want to shoot the whole Earth each year, which can be done with three satellites at 300 km altitude.  I'd use a staggered pushbroom array as the primary sensor and a smaller area array for surveillance.

The step-stare approach that SkyBox is using makes sense when a big, fast area array sensor covering the whole field of view can be had at low risk.  Sensors are developing quickly, so this envelope is growing over time, but it's still an order of magnitude away from what large-aperture spysats can do.

Maybe I'm wrong about that order of magnitude.  In 2010 Canon announced a 205 mm square CMOS sensor that supposedly reads out 60 frames per second.  Here it is pictured next to a full-frame 35mm DSLR sensor -- it's slightly bigger than the tiled array at the top of this post.  Canon did not announce the resolution, but they did say the sensor had 100 times the sensitivity of a DSLR, which suggests a pixel size around 35 microns.  That's too big for a spysat focal plane, unless it's specifically for use at night.

No subsequent announcement was made suggesting a purpose for this sensor.  Canon claims it was a technology demonstration, and I believe that (they would not have been allowed to show a production part for a spysat to the press).  Who were they demonstrating that technology to?  Is this the focal plane for a Japanese spysat?

The SkyBox camera

Christmas (and Christmas shopping) is upon us, and I have a big review coming up, but I just can't help myself...

SkySat-1, from a local startup SkyBox Imaging, was launched on November 21 on a Russian Dnepr rocket, along with 31 other microsatellites and a package bolted to the 3rd stage.  They have a signal, the satellite is alive, and it has seen first light.  Yeehah!

These folks are using area-array sensors.  That's a radical choice, and I'd like to explain why.  For context, I'll start with a rough introduction to the usual way of making imaging satellites.

A traditional visible-band satellite, like the DubaiSat-2 that was launched along with SkySat-1, uses a pushbroom sensor, like this one from DALSA.  It has an array of 16,000 (swath) by 500 (track) pixels.

The "track" pixel direction is divided into multiple regions, which each handle one color, arranged like this:

Digital pixels are little photodiodes with an attached capacitor which stores charge accumulated by the exposure.  A CCD is a special kind of circuit that can shift a charge from one pixel's capacitor to the next.   CCDs are read by shifting the contexts of the entire array along the track direction, which in this second diagram would be to the right.  As each line is shifted into the readout line, it is very quickly shifted along the swath direction.  At multiple points along the swath there are "taps" where the charge stored is converted into a digital number which represents the brightness of the light on that pixel.

A pushbroom CCD is special in that it has a readout line for each color region.  And, a pushbroom CCD is used in a special way.  Rather than expose a steady image on the entire CCD for tens of milliseconds, a moving image is swept across the sensor in the track direction, and in synchrony the pixels are shifted in the same direction.

A pushbroom CCD can sweep out a much larger image than the size of the CCD.  Most photocopiers work this way.  The sensor is often the full width of the page, perhaps 9 inches wide, but just a fraction of an inch long.  To make an 8.5 x 11 inch image, either the page is scanned across the sensor (page feed), or the sensor is scanned across the page (flatbed).

In a satellite like DubaiSat-2, a telescope forms an image of some small portion of the earth on the CCD, and the satellite is flown so that the image sweeps across the CCD in the track direction.

Let's put some numbers on this thing.  If the CCD has 3.5 micron pixels like the DALSA sensor pictured, and the satellite is in an orbit 600 km up, and has a telescope with a focal length of 3 meters, then the pixels, projected back through that telescope to the ground, would be 70 cm on a side.  We call 70 cm the ground sample distance (GSD).  The telescope might have an aperture of 50cm, which is as big as the U.S. Defense Department will allow (although who knows if they can veto a design from Dubai launched on a Russian rocket).  If so, it has a relative aperture of f/6, which will resolve 3.5 micron pixels well with visible light, if diffraction limited.

The satellite is travelling at 7561 m/s in a north-south direction, but it's ground projection is moving under it at 6911 m/s, because the ground projection is closer to the center of the earth.  The Earth is also rotating underneath it at 400 m/s at 30 degrees north of the equator.  The combined relative velocity is 6922 m/s.  That's 9,900 pixels per second.  9,900 pixels/second x 16,000 pixel swath = 160 megapixels/second.  The signal chain from the taps in the CCD probably will not run at this speed well, so the sensor will need at least 4 taps per color region to get the analog to digital converters running at a more reasonable 40 MHz.  This is not a big problem.

A bigger problem is getting enough light.  If the CCD has 128 rows of pixels for one color, then the time for the image to slide across the column will be 13 milliseconds, and that's the effective exposure time.  If you are taking pictures of your kids outdoors in the sun, with a point&shoot with 3.5 micron pixels, 13 ms with an f/6 aperture is plenty of light.  Under a tree that'll still work.  From space, the blue sky (it's nearly the same blue looking both up and down) will be superposed on top of whatever picture we take, and images from shaded areas will get washed out.  More on this later.

Okay, back to SkySat-1.  The Skybox Imaging folks would like to shoot video of things, as well as imagery, and don't want to be dependent on a custom sensor.  So they are using standard area array sensors rather than pushbroom CCDs.

In order to shoot video of a spot on the ground, they have to rotate the satellite at almost 1 degree/second so that the telescope stays pointing at that one point on the ground.  If it flies directly over that spot, it will take about 90 seconds to go from 30 degrees off nadir in one direction to 30 degrees off in the other direction.  In theory, the satellite could shoot imagery this way as well, and that's fine for taking pictures of, ahem, targets.

A good chunk of the satellite imagery business, however, is about very large things, like crops in California's Central Valley.  To shoot something like that, you must cover a lot of area quickly and deal with motion blur, both things that a pushbroom sensor does well.

The image sliding across a pushbroom sensor does so continuously, but the pixel charges get shifted in a more discrete manner to avoid smearing them all together.  As a result, a pushbroom sensor necessarily sees about 1 pixel of motion blur in the track direction.  If SkySat-1 also has 0.7 meter pixels, and just stared straight down at the ground, then to have the same motion blur it would have to have a 93 microsecond exposure.  That is not enough time to make out a signal from the readout noise.

Most satellites use some kind of Cassegrain telescope, which has two mirrors.  It's possible to cancel the motion of the ground during the exposure by tilting the secondary mirror, generally with some kind of piezoelectric actuator.  This technique is used by the Visionmap A3 aerial survey camera.  It seems to me that it's a good match to SkyBox's light problem.  If the sensor is a interline transfer CCD, then it can expose pictures while the secondary mirror stabilizes the image, and cycle the mirror back while the image is read out.  Interline transfer CCDs make this possible because they expose the whole image array at the same time and then, before readout, shift the charges into a second set of shielded capacitors that do not accumulate charge from the photodiodes.

Let's put some numbers on this thing.  They'd want an interline transfer CCD that can store a lot of electrons in each pixel, and read them out fast.  The best thing I can find right now is the KAI-16070, which has 7.4 micron pixels that store up to 44,000 electrons.  They could use a 6 meter focal length F/12 Cassegrain, which would give them 74 cm GSD, and a ground velocity of 9,350 pixels/sec.

The CCD runs at 8 frames per second, so staring straight down the satellite will advance 865 m or 1170 pixels along the ground.  This CCD has a 4888 x 3256 pixel format, so we would expect 64% overlap in the forward direction.  This is plenty to align the frames to one another, but not enough to substantially improve signal-to-noise ratio (with stacking) or dynamic range (with alternating long and short exposures).

And this, by the way, is the point of this post.  Area array image sensors have seen a huge amount of work in the last 10 years, driven by the competitive and lucrative digital camera market.  16 megapixel interline CCDs with big pixels running at 8 frames per second have only been around for a couple of years at most.  If I ran this analysis with the area arrays of five years ago the numbers would come out junk.

Back to Skybox.  When they want video, they can have the CCD read out a 4 megapixel region of interest at 30 fps.  This will be easily big enough to fill a HDTV stream.

They'd want to expose for as long as possible.  I figure a 15 millisecond exposure ought to saturate the KAI-16070 pixels looking at a white paper sheet in full sun.  During that time the secondary mirror would have to tilt through 95 microradians, or about 20 seconds of arc for those of you who think in base-60.  Even this exposure will cause shiny objects like cars to bloom a little, any more and sidewalks and white roofs will saturate.

To get an idea of how hard it is to shoot things in the shade from orbit, consider that a perfectly white sheet exposed to the whole sky except the sun will be the same brightness as the sky.  A light grey object with 20% albedo shaded from half the sky will be just 10% of the brightness of the sky.  That means the satellite has to see a grey object through a veil 10 times brighter than the object.  If the whole blue sky is 15% as bright as the sun, our light grey object would generate around 660 electrons of signal, swimming in sqrt(7260)=85 electrons of noise.  That's a signal to noise ratio of 7.8:1, which actually sounds pretty good.  It's a little worse than what SLR makers consider minimum acceptable noise (SNR=10:1), but better than what cellphone camera makers consider minimum acceptable noise (SNR=5:1, I think).

But SNR values can't be directly compared, because you must correct for sharpness.  A camera might have really horrible SNR (like 1:1), but I can make the number better by just blurring out all the high spatial frequency components.  The measure of how much scene sharpness is preserved by the camera is MTF (stands for Modulation Transfer Function).  For reference, SLRs mounted on tripods with top-notch lenses generally have MTFs around 40% at their pixel spatial frequency.

In summary, sharpening can double the high-frequency MTF by reducing SNR by a factor of two.  Fancy denoise algorithms change this tradeoff a bit, by making assumptions about what is being looked at.  Typical assumptions are that edges are continuous and colors don't have as much contrast as intensity.

The atmosphere blurs things quite a bit on the way up, so visible-band satellites typically have around 7-10% MTF, even with nearly perfect optics.  If we do simple sharpening to get an image that looks like 40% MTF (like what we're used to from an SLR), that 20% albedo object in the shade will have SNR of around 2:1.  That's not a lot of signal -- you might see something in the noise, but you'll have to try pretty hard.

The bottom line is that recent, fast CCDs have made it possible to use area-array instead of pushbroom sensors for survey satellites.  SkyBox Imaging are the first ones to try this idea.  Noise and sharpness will be about as good as simple pushbroom sensors, which is to say that dull objects in full-sky shade won't really be visible, and everything brighter than that will.

[Updated] There are a lot of tricks to make pushbroom sensors work better than what I've presented here.

• Most importantly, the sensor can have more rows, maybe 1000 instead of 128 for 8 times the sensitivity.  For a simple TDI sensor, that's going to require bigger pixels to store the larger amount of charge that will be accumulated.  But...
• The sensor can have multiple readouts along each pixel column, e.g. readouts at rows 32, 96, 224, 480, 736, and 992.  The initial readouts give short exposures, which can see sunlit objects without accumulating huge numbers of photons.  Dedicated short exposure rows mean we can use small pixels, which store less charge.  Small pixels enable the use of sensors with more pixels.  Multiple long exposure readouts can be added together once digitized.  Before adding these long exposures, small amounts of diagonal image drift, which would otherwise cause blur, can be compensated with a single pixel or even half-pixel shift.

[Updated] I've moved the discussion of whether SkyBox was the first to use area arrays to the next post.

Optical Bar Cameras

[Update: I'd like to thank Phil Pressel, John Gregor, and Gordon Petrie for their corrections to this post.  The changes required have been so extensive I have not marked them.]

[Update 2: Phil Pressel just released his book Meeting the Challenge: The Hexagon KH-9 Reconnaissance Satellite (get it at AIAA or Amazon).  I've ordered it and will post a review after I get it.]

From 1957 to 1965, a high tech startup called Itek made the world's most sophisticated satellite reconnaissance cameras for a single customer -- the CIA.  The company has a fascinating subsequent history, as they ended up building cameras for Apollo and Viking.  Eventually they ended up building the DB-110 reconnaissance pod, which I'll do a blog post on some day.

Merton Davies at RAND apparently originated the idea of using a spinning camera mounted on a spin-stabilized satellite to take panoramic shots with a narrow-angle lens.  Amrom Katz passed the concept to Walter Levinson at Boston University Physical Research Laboratory (BUPRL).  Levinson refined the idea to that of using an oscillating lens, for use in the HYAC-1 panoramic camera in Air Force high altitude reconnaissance balloons.  Itek, just a few weeks after incorporation in late 1957, bought BUPRL, which was developing the HYAC-1 panoramic camera to take pictures from high altitude balloons.

Soon after, the CIA contacted Itek to discuss the camera requirements for the first spy satellites.  All of these initial satellites came to use the rotating panoramic camera.  I think this is the KH-4A or KH-4B Corona.

Itek also built versions of these cameras for use in the U-2 and SR-71 aircraft, in which they were called the OBC (Optical Bar Camera, named for the appearance of the field of regard on the ground).  These were first used in the 1960s and are still in use today.  Here is an Itek Optical Bar Camera that goes in the nose of an U-2:


Take a look at the big, wide blue bar under the airplane.  That's what a single frame of the camera shot.  It's huge.  I've heard that this "bar" looking frame was why they called it the optical bar camera.  However, the NRO's Hexagon documentation refers to the rotating optical assembly (what in many cameras is called the "Optical Tube Assembly") as the optical bar.


After a string of successful programs, requirements racheted up and tensions grew between NRO and CIA over the next program, Fulcrum.  Early on, Itek was contracting with both the NRO and the CIA on competing projects.  Itek pulled out of the CIA's project, and some combination of the NRO and the CIA took all their (government-owned) work and gave the job to Perkin-Elmer.  When the dust settled the project was renamed Hexagon.  Perkin-Elmer built the KH-9 Optical Bar Camera with their own design rather than Itek's, as they didn't think the Itek design would work.  Here is a look into the aperture of the KH-9 Optical Bar Camera.

The Itek OBCs in the U-2, SR-71, and Apollo spacecraft all had a rotating structure called the roller cage, which I suspect was fixed to the rotating camera.  The Perkin-Elmer design in the KH-9 deleted the roller cage and the rotating fold mirror inside it, and instead had a servo controlled twisting platen.

Here is a comparison of various optical bar cameras built up to 1971 (the launch of the first KH-9).

	KA-80 (U-2/SR-71/Apollo)	(U-2/SR-71)	(KH-9)
Focal length	610 mm (24 inches)	760 mm (30 inches)	1524 mm (60 inches)
Aperture	174 mm (f/3.5)	218 mm (f/3.5?)	508 mm (f/3.0)
Cross-track Field of View	108 degrees	140 degrees	120 degrees
Film width	127 mm (5 inches)	127 mm (5 inches)	168 mm (6.6 inches)
Film length	2005 m (6500 feet)	3200 m (10500 feet)	70,000 m (230,000 feet)
Format	114 x 1073 mm	114 x 1857 mm	155 x 3190 mm
Film resolution	3.7 micron	3.7 micron	1000:1 contrast: 3.7 micron 1.6:1 contrast: 7.4 microns
Depth of focus	+/- 13 microns	+/- 13 microns	+/- 11 microns
Format resolution	31k x 290k = 9 Gpix	31k x 502k = 15 Gpix	42k x 862k = 36 Gpix
Frames	1650	1640	21,000
Nominal Altitude	24.4 km (80k feet)	24.4 km (80k feet)	152 km (82 nm)
Center ground resolution	14.8 cm	11.9 cm	37 cm
Swath	67 km	134 km	555 km
In-track field of view, center	4.55 km	3.66 km	15 km
Nominal overlap	55%	55%	10% (each camera)
Area collected	226k km2	362k km2	2x 80m km2
Nominal ground velocity	1000 m/s	1000 m/s	7,800 m/s
Cycle time	2 sec	1.65 sec	1.73 sec
Film velocity at slit	1.9 m/s	2.9 m/s	5.5 m/s
Maximum slit size	7.62 mm	12? mm	22? mm
Max exposure time	4 ms	4? ms	4? ms

Take a look at the area collected by the KH-9.  The Soviet Union was a big place: 20m km².  Each of the four film re-entry capsules could return the entire USSR, in stereo, with plenty of side overlap and margin for images fouled by clouds.  Typically they chose to take more frames with smaller swaths (90 degrees or 60 degrees) to get higher average resolution, which brought down the total take somewhat to around 60 million km².

My resolution numbers up there are slightly inflated.  The film used could only eke out 130 lp/mm when given the maximum possible amount of contrast, such as would be seen at a shadow line.  For finding something like paint on a road they were about half that.  Pixellated sensors have a much more drastic cliff, of course.  So the e.g. KH-9 resolution above might be compared to anything like a 20 to 30 gigapixel camera today.  I'll note that I don't have any of those to suggest.

There are two big concepts here that I think are important.  The first is the mechanical and logistical difficulties of using film.  Below I've spelled out some of the details.  The second is that despite these headaches, until very recently, film has been superior in many ways to electronic sensors for massive survey work.

The basic problems with using film stem from the fact that the sensor surface is a thin, pliable, moving, relatively inexpensive object that has to be held within the camera with very high precision.  There must have been several problems associated with getting the film aligned within +/- 11 microns of the lens's focal plane. Among other things, the machines resemble Van de Graf generators, and so the film is subject to static electricity buildup and discharges, along with heating that tends to make it even more pliable and sticky.  To reduce the static buildup, many of these cameras slid the film over surfaces with hundreds of pores lifting the film with pressurized air.

I think the Itek designs spun the entire optical assembly at a constant rate.  The entire spinning optical assembly is inside a gimbal which rocks back and forth 1.6 degrees in each cycle.  The rocking motion accomplishes forward motion compensation, so that the sweep of the slit across the ground is orthogonal to the direction of flight.  This compensation ensures that the motion of the image on the film moves almost exactly with the film, and there is no blurring in the direction of flight during longer exposures.  This rocking motion must have required fairly large torques, and I'm sure this is one of the things that the Perkin-Elmer folks balked at when considering the Itek design in space.  Note that a constantly rotating camera sweeps at the outer edges faster than at the center, so the forward motion compensation probably had to vary it's rate of rocking as it went to compensate.


Here is a diagram which shows how the film was wrapped around the roller cage in the Itek designs.  As the optical assembly (including the roller cage) twists counterclockwise, the film is transported clockwise.

However, even with a constant spin rate, the film does not transport at a constant rate.  For instance, in the SR-71 OBC, a frame is exposed for 640 ms, during which time the film rips around the roller cage at 2.9 meters per second (that's what the rollers see).  For the next second, the film advances at just 1 meter per second, so that the frame boundary going across the top of the roller cage can meet up with the slit going around the bottom.  Because of the speed change, many of the freewheeling rollers on the roller cage will contact unexposed film coming from the framing roller with a tangential speed difference of 1.9 meters per second.  As each freewheeling roller changes speed to match the film, it seems to me it would tend to scuff the film.  I'm sure they made sure to make those rollers as lightweight as possible to reduce their rotational momentum.

Note the unlabeled slit after the second mirror right next to the film wrapped around the roller cage.  Only the portion of the film after this in the optical chain has light on it, so this is the only spot that must be held accurately.  I don't really know how it was done, since every moving belt of material that I've even seen has vibrated.  They may have had a glass reseau plate that the film slid across.  Sliding film across glass at 2.9 meters per second seems like an excellent way to scratch one or both.  I have no evidence for it yet, but this seems like a good application for the compressed air film handling scheme.

The Itek forward motion compensation gimbal also took out airplane pitch motions.  Airplane roll motions were taken out by varying the optical tube roll rate.  That's easy enough (it doesn't require torque), but the film rate supplied to the roller cage assembly in the back also had to change to match.

That last diagram gives a pretty good clue to another challenge in this design -- film curvature.  Although I've not found any labelled dimensions, it looks like the roller cage in the Itek designs was about 300 mm in diameter.  The design of the roller cage really had me puzzled for a while, because the film transport path is cylindrical, but the film being exposed by the slit has to be flat.  I finally figured it out when I took a good look at this photo of the Apollo OBC (also made by Itek):


The roller cage is a cylindrical cage of ROLLERS!  Duh!  As the film passes between the rollers, it's locally flat, and that's how they keep the film surface matched to the lens focal plane.  Here's a 5x blowup of the roller cage in the picture above.  It looks like the rollers are packed together as close as they can get in order to minimize the polygonal variation in film distance from the center of roller cage rotation.  I think this variation leads to a (small) variation in film speed at the exposure site.

There should be a spot in the roller cage where there aren't any rollers, and the film becomes planar for a while.  This spot would be over the exposure slit.  In the Apollo OBC pictured here, the gap between the rollers must be at least 7.6mm, and given the orientation of the lens at the top it should be on the back side of the roller cage that we don't see here.


The film is pulled taut around the stuttering, bucking and twisting roller cage with an assembly that looks like the following.  During the exposure film is pulled around the roller cage at 5.7 meters/second.  Here's the film path:

If the tension on the film is too small, small irregularities in it's "set" curvature will make it lift off as it goes around the roller cage, and small patches of the film will lift away from the cage.  With a +/- 11 micron depth of focus, it doesn't take much lift off to make a problem.  If the tension is too high, the film will wrinkle longitudinally.


The Perkin-Elmer design did not have the roller cage or the gimbal.  Instead, they had a twisting platen assembly at the focal plane.  This would twist back and forth through 130 degrees as the optical bar rotated through 360 degrees.  The two were nearly locked together through the 120 degrees of rotation that were used for exposure.

Because the Perkin-Elmer design has no rocker gimbal doing forward motion compensation, and the optical assemblies rotate at constant speed, the sweep is faster at the edges than in the center, and the area swept in each frame is slightly S shaped.  They may have splayed the roll axes of the optical bars to get first order forward motion compensation, but this doesn't change the S shape.  To keep the image from smearing across the film, the KH-11 has to keep the slit perpendicular to the motion of the slit across the ground, accounting for the changing sweep rate versus spacecraft velocity, as well as the rotation of the Earth, which is 6% of the spacecraft velocity at the equator.

This is why the twisting platen in the KH-11 is servo locked to the twisting optical assembly.  They have to vary the relative twist of the two a little bit to keep the projected slit perpendicular to it's projected motion.

After the picture was shot the film sat around for a month in a temperature and humidity controlled environment, and then was dropped, recovered, and developed.  There was a lot of opportunity for the film to shrink differentially.  All the mechanical twisting, as well as film shrinkage, must have made photogrammetry a nightmare.

The Sunny 16 rule says that you can properly expose ISO 100 film in bright daylight conditions with a f/16 lens with a 10 ms exposure.  The KH-9 used mostly monochrome Kodak 1414, which has an Aerial Film Speed of 15, which I think is equivalent to ISO 38.  In full sun a 1 ms exposure at f/3 would have worked fine.  On the Apollo OBC that corresponds to a 1.9mm wide slit.  They did have exposure control hardware, and it looks like they could exposure for two stops dimmer than full sun.  They might have also stopped down from that, in order to avoid blowouts over ice.

---

At this point, I'm sure those of you who have worked with digital sensors are feeling pretty smug.  But consider how wonderful film was for capturing and returning large amounts of imagery.

Each of the four re-entry vehicles on the KH-9 would bring back 5,000 36 gigapixel images.  If somehow compressed to 1 bit per pixel, that would be about 20 terabytes.  These days that's about 10 hard disks, and would take about three months to downlink at a constant 25 megabits per second.  Since they were returning these re-entry vehicles every few months, a modern downlink is only barely adequate.  It has only been in the last 10 years or so that disk drive capacities have become high enough to fit the data into the payload of one of those re-entry vehicles -- 30 years after the KH-9 was originally deployed.

In 1971, the area of film actively integrating photons in the KH-9 was 155 mm x 15 mm.  The largest, fastest TDI CCD sensors commercially available in 2013 are 64 mm x 1.3 mm.  The pixels on these are 5.2 microns rather than 3.7 as on film.  The smaller integrating length (1.3 mm versus 22 mm) gives a maximum exposure time of  240 microseconds, which is smaller than the 2 milliseconds we would prefer.  155 mm x 10 mm CCDs with 3.7 micron pixels are not commercially available, but could probably be custom made.

Another issue would be the readout rate.  A fast TDI in 2013 reads out lines at 90 KHz.  The KH-9 was exposing film in the roller cage at 5.5 meters/second, which corresponds to a line readout rate of 1.5 MHz.  This could be achieved with a custom built TDI sensor maybe 5 years ago.  It would require 1300 ADCs running at 45 MHz, which would burn a lot of power.  This might be possible with interesting packaging.

The capture rate of the KH-9 was so enormous it completely overwhelmed the ability of the photointerpreters at the CIA to examine the photographs. It's only recently that computers have gotten large enough to store and process imagery at this volume, and it's not at all clear that anyone has yet developed algorithms to find the "unknown unknowns" in a bunch of raw imagery.  I think they call this "uncued image search".

To my knowledge the U.S. never again fielded a spysat with the ability to survey major portions of the earth at high resolution.  Later Keyhole satellites appear to have concentrated more on taking valuable single shots at higher resolution (7 cm GSD), and on having the orbital maneuverability to get those shots.  I think the intelligence folks lost interest in survey satellites when it became clear that they couldn't take advantage of the comprehensive coverage which was their primary feature.  It's kind of ironic that the very problem that Itek was founded to solve (managing the huge volume of survey photography) ended up being a major reason why satellites with survey capacity made possible by Itek's cameras faded away.  It's fascinating for me to see what has become of this problem.

Brian McClendon is on record as saying that Google has 5 million miles and 20 petabytes of Street View imagery.  That's the processed imagery, not the raw take.  The KH-9 raw take that overwhelmed the CIA photointerpreter capacity 30 years ago was less than 1% of what Google Street View shot.  Unlike the KH-9 imagery, most of which I suspect has never been looked at, every one of the Street View panoramas has been seen by a real user.  And Google is hardly the only organization using Big Data like this.  The consumption problem that the CIA and NRO never solved has been utterly crushed by organizations with entirely different goals.  (Granted, uncued search remains unsolved.)

Now that Big Data has caught up with the photo throughput of digital satellites, it's fun to think about what could be built with modern technologies.  But that's probably best saved for another post.

R7 baffle being laser cut

Check it out!  This is the baffle for the R7 StreetView camera.  The final apertures are being cut with a laser.  These apertures have to line up with the view cone of the cameras fairly tightly, in order to clip off a ghost reflection in the lens that I missed during optical design.  The ghost only hits the sensor when the sun is in a 5 degree wide band just outside the field of view.  I suspect it's a fairly complex internal reflection path, since a simple double bounce ghost ought to sweep through the center of the lens as the sun does.

I had the idea of welding the whole baffle together and then as a final operation cutting the apertures, with the hope that the metal would stop moving around once we'd cut smaller apertures and finished welding.  It didn't really work out perfectly.  There was a fair bit of tolerance stackup between the internal lenses and this external baffle.  Also, the baffle mounted to 8 screws, and those 8 points would tend to get significantly out of alignment, so that the baffle shape that you ended up with depended on what order you tightened the screws.  As a result we had to open up some extra margin on the baffle openings.  I know for a fact that the sun can leak into the corners.  After a quick check, I can't find any examples of the ghost, though, so the baffle is doing a decent job.

R7 at work:

R7 at play.  Hi Ryan!  Note the ears on top.  Those are the twin GPS antennae... the way I intended all R7s to be.

Thousands of drones

Someone recently asked me if aerial survey could be accomplished with a swarm of tiny drone aircraft.  Imagine foot-long planes made of styrofoam, carrying the camera, IMU, and GPS of a cellphone, minus the display, with a far larger battery for propulsion.  How can this fail to be a cheaper way to survey large areas?

I've worked on a drone program before, but that was with a gas-powered UAV weighing 25 kg empty with a 2 kg payload and a range of around 1100 km over an 6 hour flight, costing in excess of $50k.  Operational costs were expected to be dominated by the cost of crashing.  I can say confidently that these are not a cheap way to survey anything.

In researching this blog post, I learned about solar-electric RC airplanes, which are a completely different kettle of fish.  The Aphelion, above, was built for under $500 (materials only) in Professor Mark Drela's MIT lab, and can fly at 5-6 m/s for as long as the sun is 6.5 degrees above the horizon, which is something like 8 to 12 hours a day.  That puts the daily range around 150 km.

Crucially, the whole airplane weighs 1300 grams distributed over a 3.3 meter wingspan.  My guess is that a Cessna might survive an in-flight impact with one of these, and maybe even something a bit heavier.

A survey drone version would be ruggedized for e.g. 1000 flights MTBF, would carry a 200 g camera payload and a 50g battery, would fly at 12 m/s, and cover 300 km during a day's flight.  Higher speeds lead to more coverage and better survivability in higher winds, but also smaller wings and less solar power.  The battery allows flight with intermittent solar coverage, due to clouds and building blockages.

This range is not great.  If a drone maintained 10 m/s from 9AM to 3PM, it would cover 216 km.  For comparison, a King Air B200, which is something of a standard twin-turboprop airplane for aerial survey, flies at 140 to 150 m/s and can cover 1700 km in a morning.

These drones are going to require an ultralight camera -- basically a cellphone camera.  The camera scales surprisingly well, primarily because you are comparing cellphone sensors to huge custom CCDs used in e.g. Leica ADS80 aerial cameras, and of course the cellphone sensors are far better because they have far more engineering investment.  Nowadays I would use an Aptina MT9F002 14-megapixel sensor with a 10mm lens, which will deliver 2 inch resolution from 1000 feet up.  This will deliver a swath of over 200 meters.  Because the drone will bounce around a fair bit, we'll need a very generous overlap between the imagery captured in one flight line and the next, so the flight pitch will be something like 150 meters.  For comparison, an ADS80 camera in a B200 flies with a 1 kilometer flight pitch when shooting this resolution.

Due to the close range and excellent sensor there is no need for a gimbal for the drone camera.  I'd use a 400 microsecond exposure time.  Combine that with the 140 microradian pixel field of view, and the camera can tolerate rolls and pitches of 25 to 50 degrees per second without excessive motion blur.  I think even a little drone with very low wing loading can deliver that most of the time.  If we shoot 94% forward overlap between frames (1 frame per second), which is possible because we are going so slowly, then if we lose a few shots due to motion blur we can afford to just drop them.  We'll collect about 100 GB of data in 6 hours at that frame rate, which will be storable on a microSD card next year.

Now we come to the very bad news for this idea.  The combination of low speed and small flight pitch means that we'll need something like 100 drones to replace a ADS80 in a B200.  If you talk to R/C folks, you will find that they spend at least as much time fixing their aircraft as they do flying them.  So those 100 drones are going to require an army of people to launch, recover, and repair them.

The bottom line is that using drones instead of manned aircraft still seems like a bad idea... if you can use a manned aircraft.  But here is how survey drones might turn out to be a really wonderful idea:  If you can make the drone light enough that it just won't hurt anyone when it crashes, then you might be able to get permission to fly down city streets.  THAT would rock, because you'd simultaneously solve a bunch of problems that a bunch of folks (Nokia/Navteq, TomTom/TeleAltas, Google) are spending hundreds of millions of dollars a year on today:

• You would be collecting street level imagery without having to wait for traffic.  Much, much faster.
• The native perspective of the cameras would be the one that people actually want.  This is just my intuition, but my sense from working on Street View is that it was too damn slow and difficult to navigate.  I think people want a raised perspective, but just not raised too much.
• You would be collecting the sides of buildings at high resolution.  Right now there is a major gap between street-level resolution (Google's Street View is 3mm resolution) and aerial resolution (Google's 45 degree view is 100mm resolution).  That gap means that the sides of buildings don't match up well, which is a problem if, like Apple and Google, you want to deliver great looking 3D models of buildings.
• Aerial obliques don't actually work in places like New York because the buildings are too tall compared to the street width.  However, if you fly between the buildings, this is no longer a problem!  This is a major issue now that over half the world's population (likely the wealthier half) live in cities.

I think it's a big stretch to imagine getting permission to fly your UAVs down city streets, and technically it would be a big challenge just to plan the routes... you'd probably end up needing to survey the city from high altitude first.  It sure is fun to think about, though.

Dragonfly Eyes - the Wonders of Low Resolution

Continuing with the recent theme of analyzing both natural and man made cameras, I thought I'd analyze an insect eye in this post.  In previous posts I've analyzed a gigapixel airborne security video camera and the eye of a raptor.  I'm working on analyses of the F-35's Distributed Aperture System as well as a really gigantic film camera for future posts.

The picture above is of a blue-spotted Hawker dragonfly.  This creature apparently catches its prey in midflight, so it's supposed to have big, high resolution eyes.  According to John Patterson in this Discover magazine article, it has 28,000 lenses in each eye.  Judging from the picture, those eyes are probably covering half of the possible 4*pi solid angle, so each tiny lens is covering a solid angle of 112 microsteradians.  That would be Low Resolution to my mind.  Critters like spiders and grasshoppers, with even smaller eyes, must be commensurately worse.

To give some context, a human in bright light has a pixel field of view of 25 nanosteradians.  You can see across your yard (70 feet) what the dragonfly can see from 1 foot.  If it is going after an 8mm long house fly, it needs to close within 80 cm in order to get a full pixel on the target.  At that range the house fly can probably hear the dragonfly, although I haven't analyzed that and insect hearing might also be much worse than human hearing.  This dragonfly is not a long-range hunter like a bird, but rather an opportunist.  I very much doubt it can pull off a high-relative-speed attack like a Peregrine falcon, which requires good angular resolution and gimbal stabilization.

Interestingly, the creature collects about the same amount of light per pixel that the human eye does.  The entire creature is about 70mm long.  Judging from the picture below, the eyes are probably 10 mm across.  That means those little lenses are 53 microns across.  On a bright day outside, your human pupils constrict to 3 mm, 55 times larger.  But since the dragonfly's pixel field of view is 70 times bigger, it actually receives about 50% more light per pixel than you do.

I used to be concerned that the tiny dragonfly lenses would cause diffraction blurring.  Supposing for a moment that they look at green light, their Rayleigh criterion is about 12 milliradians, nicely matched to their pixel angular field of view of 10.5 milliradians.  If the effective pupil of each lens is substantially smaller than the allotted space (low fill factor), then the dragonfly would have to use a shorter wavelength to avoid diffraction problems.  It doesn't look like a big problem.

I don't think the dragonfly has to stabilize the scenery with it's neck.  A dragonfly flying at 1 meter/second sees scenery 50 cm away to the side going by at 2 radians/second.  To get less than 3 pixels of motion smear, it would have to integrate the exposure for less than 15 milliseconds.  That's just a bit quick, so the creature probably sees some motion blur to the side, but not so much in front of it, since there is considerably less angular motion in the direction of flight.

ARGUS-IS

Here's an exotic high flying camera: ARGUS-IS.  I've been trying to figure what these folks have been up to for years, and today I found an SPIE paper they published on the thing.  What follows is a summary and my guesses for some of the undocumented details. [Updated 30-Jan-2013, to incorporate new info from a Nova documentary and a closer reading of the SPIE paper.]

Vexcel Ultracams also use four cameras
with interleaved sensors

• It looks like BAE is the main contractor.  They've subcontracted some of the software, probably the land station stuff, to ObjectVideo.  BAE employs Yiannis Antoniades, who appears to be the main system architect.  The lenses were subcontracted out to yet another unnamed vendor, and I suspect the electronics were too.
• Field of view: 62 degrees.  Implied by altitude 6 km and object diameter 7.2 km.
• Image sensor: 4 cameras, each has 92 Aptina MT9P031 5 megapixel sensors.  The paper has a typo claiming MT9P301, but no such sensor exists.  The MT9P031 is a nice sensor, we used it on the R5 and R7 Street View cameras.
• 15 frame/second rate, 96 MHz pixel clock, 5 megapixels, 2592 x 1944.
• It's easy to interface with, has high performance (quantum efficiency over 30%, 4 electrons readout noise, 7000 electrons well capacity), and is (or was) easy to buy from Digikey.  (Try getting a Sony or Omnivision sensor in small quantities.)
• Focal length: 85mm.  Implied by 2.2 micron pixel, altitude of 6 km, GSD of 15 cm.  Focal plane diameter is 102mm.  The lens must resolve about 1.7 gigapixels.  I must say that two separate calculations suggest that the focal length is actually 88mm, but I don't believe it, since they would have negative sensor overlap if they did that.
• F/#: 3.5 to 4.  There is talk of upgrading this system to 3.7 gigapixels, probably by upgrading the sensor to the Aptina MT9J003.  An f/4.0 lens has an Airy disk diameter of 5.3 microns, and it's probably okay for the pixels to be 2.2 microns.  But 1.66 micron pixels won't get much more information from an f/4.0 lens.  So, either the lens is already faster than f/4.0, or they are going to upgrade the lens as well as the sensors.
• The reason to use four cameras is the same as the Vexcel Ultracam XP: the array of sensors on the focal plane cannot cover the entire field of view of the lens.  So, instead, they use a rectangular array of sensors, spaced closely enough so that the gaps between their active areas are smaller than the active areas.  By the way guys (Vexcel and ObjectVideo), you don't need four cameras to do this problem, it can be solved with three (the patent just expired on 15-Jul-2012).  You will still need to mount bare die.
• The four cameras are pointed in exactly the same direction.  Offsetting the lenses by one sensor's width reduces the required lens field of view by 2.86 degrees, to about 59 degrees.  That's not much help.  And, you have to deal with the nominal distortion between the lenses.  Lining up the optical axes means the nominal distortion has no effect on alignment between sensors, which I'm sure is a relief.
• The sensor pattern shown in the paper has 105 sensors per camera, and at one point they mention 398 total sensors.  The first may be an earlier configuration and the latter is probably a typo.  I think the correct number is 92 sensors per camera, 368 total.  So I think the actual pattern is a 12x9 rectangular grid with 11.33mm x 8.50mm centers.  16 corner sensors (but not 4 in each corner) are missing from the 9x12=108 rectangle, to get to 92 sensors per focal plane.  The smallest package that those sensors come in is 10mm x 10mm, which won't fit on the 8.5mm center-to-center spacing, so that implies they are mounting bare die to the focal plane structure.
• They are carefully timing the rolling shutters of the sensors so that all the rolling shutters in each row are synchronized, and each row starts it's shutter right as the previous row finishes.  This is important, because otherwise when the camera rotates around the optical axis they will get coverage gaps on the ground.  I think there is a prior version of this camera called Gorgon Stare which didn't get this rolling shutter synchronization right, because there are reports of "floating black triangles" in the imagery, which is consistent with what you would see on the outside of the turn if all the rolling shutters were fired simultaneously while the camera was rotating.  Even so, I'm disappointed that the section on electronics doesn't mention how they globally synchronize those rolling shutters, which can be an irritatingly difficult problem.
• They are storing some of the data to laptop disk drives with 160 GB of storage.  It appears they may have 32 of these drives, in which case they've got enough space to potentially store the entire video stream, but only with very lossy video compression.  The design presented has only JPEG2000 (not video) compression, which will be good for stepping through the frames, but the compression ratio will be bulky enough that there is no way they are storing all the video.
• They have 184 FPGAs at the focal plane for local sensor control, timestamping, and serialization of the data onto 3.3 Gb/s fiber optics.  Supposedly the 3.3 Gb/s SerDes is on the FPGA, which sounds like a Virtex-5 20T.  But something is odd here, because having the SerDes on the FPGA forces them to choose a fairly beefy FPGA, but then they hardly do anything with it: the document even suggests that multiplexing the two sensor data streams, as well as serialization of those streams, happens outside the FPGA (another typo?).  So what's left for a Virtex-5 to do with a pair of sensors?  For comparison, I paired one Spartan-3 3400A with each sensor in R7, and we were able to handle 15 fps compression as well as storage to and simultaneous retrieval from 32 GB of SLC flash, in that little FPGA.  Maybe the SerDes is on some other device, and the FPGA is more of a PLD.
• The data flows over fiber optics to a pile of 32 6U single board computers, each of which has two mezzanine cards with a Virtex 5 FPGA and two JPEG2000 compressors on it.

Now here's my critique of this system design:

• They pushed a lot of complexity into the lens.
• It's a wide angle, telecentric lens.  Telecentric means the chief rays coming out the back, heading to the focal plane, are going straight back, even at the edges of the focal plane.  Said another way, when you look in the lens from the back, the bright exit pupil that you see appears to be at infinity.  Bending the light around to do that requires extra elements.  This looks a lot like the lenses used on the Leica ADS40/ADS80, which are also wide angle telecentric designs.  The Leica design is forced into a wide angle telecentric because they want consistent colors across the focal plane, and they use dichroic filters to make their colors.  The ARGUS-IS doesn't need consistent color and doesn't use dichroics... they ended up with a telecentric lens because their focal plane is flat.  More on that below.
• The focal lengths and distortions between the four lenses must be matched very, very closely.  The usual specification for a lens focal length is +/- 1% of nominal.  If the ARGUS-IS lens were built like that, the image registration at the edge of field would vary by +/- 500 microns.  If my guesses are right, the ARGUS-IS focal plane appears to have 35x50 microns of overlap, so the focal lengths of the four lenses will have to match to within +/- 0.07%.  Wow.
• "The lenses are athermalized through the choice of glasses and barrel materials to maintain optical resolution and focus over the operational temperature range."  Uh, sure.  The R7 StreetView rosette has 15 5 megapixel cameras.  Those lenses are athermalized over a 40 C temperature range, and it was easy as pie.  We just told Zemax a few temperature points, assumed an isothermal aluminum barrel, and a small tweak to the design got us there.  But those pixels have a field of view of 430 microradians, compared to the pixels behind the ARGUS-IS lens, which have a 25 microradian PFOV.  MIL-STD-810G, test 520.3, specifies -40 C to 54 C as a typical operating temperature range for an aircraft equipment bay.  If they had anything like this temperature range specified, I would guess that this athermalization requirement (nearly 100 degrees!) came close to sinking the project.  The paper mentions environmental control within the payload, so hopefully things aren't as bad as MIL-STD-810G.
• The lenses have to be pressure compensated somehow, because the index of refraction of air changes significantly at lower pressures.  This is really hard, since glasses, being less compressible than air, don't change their refractive indices as fast as air.  I have no particularly good ideas how to do it, other than to relax the other requirements so that the lens guys have a fighting chance with this one.  Maybe the camera can be specified to only focus properly over a restricted range of altitudes, like 4km to 8km.  (ARGUS-IR specifies 0 to 10km.  It's likely ARGUS-IS is the same, so no luck there.)  Or maybe everything behind their big flat window is pressurized.
• They made what I think is a classic system design mistake: they used FPGAs to glue together a bunch of specialized components (SerDes, JPEG compressors, single board computers), instead of simply getting the job done inside the FPGAs themselves.  This stems from fear of the complexity of implementing things like compression.  I've seen other folks do exactly the same thing.  Oftentimes writing the interface to a off-the-shelf component, like a compressor or an encryption engine, is just as large as writing the equivalent functionality.  They mention that each Virtex-5 on the SBC has two 0.6 watt JPEG2000 chips attached.  It probably burns 200 mW just talking to those chips.  It seems to me that Virtex could probably do JPEG2000 on 80 Mpix/s in less than 1.4 watts.  Our Spartan-3 did DPCM on 90+ Mpix/s, along with a number of other things, all in less than 1 watt.
• I think I remember reading that the original RFP for this system had the idea that it would store all the video shot while airborne, and allow the folks on the ground to peruse forward and backward in time.  This is totally achievable, but not with limited power using an array of single-board PCs.

Let me explain how they ended up with a telecentric lens.  A natural 85mm focal length lens would have an exit pupil 85mm from the center of the focal plane.  Combine that with a flat focal plane and sensors that accept an f/1.8 beam cone (and no offset microlenses), and you get something like the following picture.  The rectangle on the left is the lens, looking from the side.  The left face of the right rectangle is the focal plane.  The big triangle is the light cone from the exit pupil to a point at the edge of the focal plane, and the little triangle is the light cone that the sensor accepts.  Note that the sensor won't accept the light from the exit pupil -- that's bad.

There are two ways to fix this problem.  One way is to make the lens telecentric, which pushes the exit pupil infinitely far away from the focal plane.  If you do that, the light cone from the exit pupil arrives everywhere with it's chief ray (center of the light cone) orthogonal to the focal plane.  This is what ARGUS-IS and ADS-80 do.

The other way is to curve the focal plane (and rename it a Petzval surface to avoid the oxymoron of a curved focal plane).  Your retina is curved behind the lens in your eye, for example.  Cellphone camera designers are now looking at curving their focal planes, but it's pretty hard with one piece of silicon.  The focal plane array in ARGUS-IS is made of many small sensors, so it can be piecewise curved.  The sensors are 7.12 mm diagonally, and the sag of a 85 mm radius sphere across 7.12 mm is 74 microns.  The +/- 9 micron focus budget won't allow that, so curving the ARGUS-IS focal plane isn't going to allow a natural exit pupil.  The best you can do is curve the focal plane with a radius of 360 mm, getting 3.6 mm of sag, and push the exit pupil out to about 180 mm.  It's generally going to be easier to design and build a lens with an exit pupil at 2x focal length rather than telecentric, but I don't know how much easier.  Anyway, the result looks like this:

As I said, the ARGUS-IS designers didn't bother with this, but instead left the focal plane flat and pushed the exit pupil to infinity.  It's a solution, but it's not the one I would have chosen.

Here's what I would have done to respond to the original RFP at the time.  Note that I've given this about two hours' thought, so I might be off a bit:

• I'd have the lenses and sensors sitting inside an airtight can with a thermoelectric cooler to a heat sink with a variable speed fan, and I'd use that control to hold the can interior to between 30 and 40 C (toward the top of the temperature range), or maybe even tighter.  I might put a heater on the inside of the window with a thermostat to keep the inside surface isothermal to the lens.  I know, you're thinking that a thermoelectric cooler is horribly inefficient, but they pump 3 watts for every watt consumed when you are pumping heat across a level.  The reason for the thermoelectric heat pump isn't to get the sensor cold, it's to get tight control.  The sensors burn about 600 mW each, so I'm pumping 250 watts outs with maybe 100 watts.
• I'd use a few more sensors and get the sensor overlap up to 0.25mm, which means +/-0.5% focal length is acceptable.  I designed R5 and R7 with too little overlap between sensors and regretted it when we went to volume production.  (See Jason, you were right, I was wrong, and I've learned.)
• Focal plane is 9 x 13 sensors on 10.9 x 8.1 mm centers.  Total diameter: 105mm.  This adds 32 sensors, so we're up to an even 400 sensors.
• Exiting the back of the fine gimbal would be something like 100 flex circuits carrying the signals from the sensors.
• Hook up each sensor to a Spartan-3A 3400.  Nowadays I'd use an Aptina AR0330 connected to a Spartan-6, but back then the MT9P001 and Spartan-3A was a good choice.
• I'd have each FPGA connected directly to 32GB of SLC flash in 8 TSOPs, and a 32-bit LPDDR DRAM, just like we did in R7.  That's 5 bytes per pixel of memory bandwidth, which is plenty for video compression.
• I'd connect a bunch of those FPGAs, let's say 8, to another FPGA which connects to gigabit ethernet, all on one board, just like we did in R7.  This is a low power way to get connectivity to everything.  I'd need 12 of those boards per focal plane.  This all goes in the gimbal.  The 48 boards, and their power and timing control are mounted to the coarse gimbal, and the lenses and sensors are mounted to the fine gimbal.
• Since this is a military project, and goes on a helicopter, I would invoke my fear of connectors and vibration, and I'd have all 9 FPGAs, plus the 8 sensors, mounted on a single rigid/flex circuit.  One end goes on the focal plane inside the fine gimbal and the other goes on the coarse gimbal, and in between it's flexible.
• I'd connect all 52 boards together with a backplane that included a gigabit ethernet switch.  No cables -- all the gigE runs are on 50 ohm differential pairs on the board.  I'd run a single shielded CAT-6 to the chopper's avionics bay.  No fiber optics.  They're really neat, but power hungry.  Maybe you are thinking that I'll never get 274 megabits/second for the Common Data Link through that single gigE.  My experience is otherwise: FPGAs will happily run a gigE with minimum interpacket gap forever, without a hiccup.  Cheap gigE switches can switch fine at full rate but have problems when they fill their buffers.  These problems are fixed by having the FPGAs round-robin arbitrate between themselves with signals across that backplane.  Voila, no bandwidth problem.
• The local FPGA does real time video compression directly into the flash.  The transmission compression target isn't all that incredible: 1 bit per pixel for video.  That gets 63 channels of 640x400x15 frames/sec into 274 Mb/s.  The flash should give 1 hour of storage at that rate.  If we want 10 hours of storage, that's 0.1 bits/pixel, which will require more serious video compression.  I think it's still doable in that FPGA, but it will be challenging.  In a modern Spartan-6 this is duck soup.
• The computer tells the local FPGAs how to configure the sensors, and what bits of video to retrieve.  The FPGAs send the data to the computer, which gathers it up for the common data link and hands it off.
• I'll make a guess of 2 watts per sensor+FPGA+flash, or 736 watts.  Add the central computer and switch and we're at 1 kilowatt.  Making the FPGAs work hard with 0.1 bit/pixel video compression might add another 400 watts, at most.
• No SSDs, no RAID, no JPEG compression chips, no multiplexors, no fiber optic drivers, no high speed SerDes, no arrays of multicore X86 CPUs.  That's easily half the electronics complexity, gone.

UPDATE 25-Jan-2013: Nova ran a program on 23-Jan-2013 (Rise of the Drones) which talks about ARGUS-IS.  They present Yiannis Antoniades of BAE systems as the inventor, which suggests I have the relationship between BAE and ObjectVideo wrong in my description above.  They also say something stupid about a million terabytes of data per mission, which is BS: if the camera runs for 16 hours the 368 sensors generate 2,000 terabytes of raw data.

They also say that the ARGUS-IS stores the entire flight's worth of data.  I don't think they're doing that at 12 hertz, certainly not on 160 GB drives.  They've got 32 laptop drives in the system (one per single board computer).  If those store 300 GB apiece, that's 10 terabytes of total storage.  16 hours of storage would require 0.05 bits/pixel -- no way without actual video compression.  The JPEG2000 compressor chips are more likely to deliver at best 0.2 bits/pixel, which means they might be storing one of every four frames.

UPDATE 27-Jan-2013: An alert reader (thanks mgc!) sent in this article from the April/May 2011 edition of Science and Technology Review, which is the Lawrence Livermore National Laboratory's own magazine.  It has a bunch of helpful hints, including this non-color-balanced picture from ARGUS-IS which lets you see the 368 sensor array that they ended up with.  It is indeed a 24 x 18 array with 16 sensors missing from each corner, just as I had hypothesized.

The article mentions something else as well: the Persistics software appears to do some kind of super-resolution by combining information from multiple video frames of the same nearly static scene.  They didn't mention the other two big benefits of such a scheme: dynamic range improvement and noise reduction (hence better compression).  With software like this, the system can benefit from increasing the focal plane to 3.8 gigapixels by using the new sensor with 1.66 micron pixels.  As I said above, if the lens is f/3.5 to f/4.0 lens they won't get any more spatial frequency information out of it with the smaller pixels, but they will pick up phase information.  Combine that with some smart super-resolution software and they ought to be able to find smaller details.  Question though: why not just go to the MT9F002, which gives you 14 million 1.4 micron pixels?  This is a really nice, fast sensor -- I've used it myself.

The article also mentions 1000:1 video compression.  That's very good: for comparison, H.264 level 4 compresses 60 megapixels/second of HDTV into 20 megabits/second, which is 0.33 bits/pixel or 36:1 compression.  This isn't a great comparison, though, because Persistics runs on almost completely static content and H.264 has to deal with action movie sequences.  In any case, I think the Persistics compression is being used to archive ARGUS-IS flight data.  I don't think they are using this compression in the aircraft.

Camera Guy at work

One of the nice things about working here is that when we need stuff, we get it.

5 Ways to Die During Reentry

If you haven't already seen it, the Columbia Crew Survival Investigation Report.

During reentry, there is a 10 minute long window of maximum heating.  They almost made it through all 10 minutes.  Right at the end they lost their hydraulics.  Makes me wonder if they could have flown the orbiter at a funny incoming angle to spare the load on the left wing.  Maybe they wouldn't have gotten Columbia onto the ground, but if it had broken up five minutes later things might have gone a bit better.

There were 40 seconds after loss of control during which the Columbia pitched up into something like a flat spin, and the folks inside tried to get their hydraulic systems back.

After that, they had a depressurization that took less than 17 seconds and probably, hopefully knocked everyone unconscious.  Nobody dropped their visors (which would let their suits handle pressurization).  Apparently they were all in "fix the vehicle" mode and not in "survival as long as possible" mode.

After that the cabin seperated from the rest of the vehicle, the crew's shoulder and other restraints mostly didn't work, and they got thrashed to death: fatal trauma to their heads from the insides of their helmets.  Owww.

From my reading, had they dropped their visors, gone to suit oxygen, and braced, several of the crew could have made it through both depressurization and cabin separation.

But then the cabin blew apart and they were in their suits in a mach 15 airstream.  I didn't actually read this anywhere, but it sounds like most of the suits came off before they hit the ground.

Side note for camera geeks: notice how crappy the home video shots of the breakup look.  Then look at the Apache Helicopter shots of the same thing, especially when it zooms in.  That chopper has some nice telescopes!

Discovery Launch

I just got back from watching the Discovery launch. My boss, Ed Lu (former 3-time astronaut, second from left), hosted us, which really made the experience for me because he was able to introduce us to lots of folks. Every time we walked into a restaurant, and every 5 minutes while we were at Kennedy Space Center, someone would smile and come over to talk with Ed. NASA doesn't pay well and most folks don't get to try wacky things like we do at Google, but they seem to have great interpersonal relationships. It's heartwarming to see.



On launch day, we were 3 miles from the pad at the media site. This is as close as you can get. We had a lot of waiting around to do. Here is a cherry spitting contest.



I know there is a great deal of speculation out there about whether hacking on camera hardware at Google makes one a babe magnet. While such question are only academic for me personally, I can tell you that getting out in the midst of a bunch of media types with some very customized photographic hardware attracts all sorts of attention. I don't actually know who this person is but I think we can all agree she's gorgeous, and she was very interested in the camera hardware and what Google was doing with it.



From our vantage point 3 miles away, the shuttle stack was just a little bigger than the full moon, which meant that the flame coming out the back was about that size too. There have been some comparisons to the shuttle exhaust being as bright as day....

Let me put that myth to rest. After two years of designing outdoor cameras, I can tell you that just about nothing is as bright as the sun. From our vantage point it had more angular size than the sun -- maybe 400 feet long by 100 feet wide, viewed from 3 miles, is 1.5 by 0.5 degrees.  The sun is 0.5 degrees across.  But the Shuttle plume is not as hot as the sun -- 2500 K at most, compared to 6000 K for the sun.  Brightness increases as the 4th power of the temperature, so the Sun's delivered power per square meter is something like 11x larger.  Furthermore, most of the light coming from the Shuttle is in the deep infrared where you can't see it, compared to the Sun's peak right at yellow.  So my guess is that the shuttle was lighting us up to 9,000 lux illumination.  That's twice as bright as an operating room, and way brighter than standard office bright (400 lux).  But it's just nothing like the 100,000 lux that you get outside in bright sunlight.  Nobody's going to get a suntan exposing themselves to the shuttle.  (Yes, the shuttle flame reflects off the exhaust plume, but the sun reflects off clouds, which are much bigger, so there is no relative gain there.)

Anyway, back to the people we got to meet. Here we are at lunch in the KSC cafeteria, the day before the launch. That guy two to my right is... named at the bottom of the blog. Have a guess. He had a really neat retro electronic watch and talked about how much he likes his Segway. Picture was shot by Jim Dutton, one of the F-22 test pilots who is now an unflown astronaut.


Here's a terrible picture of Scott Horowitz (former #2 at NASA, the guy who set the direction for the Ares rockets and Orion capsule) talking with Ed. The two were talking about their airplanes, a subject that gets both of them fairly animated ("I love my airplane. It's trying to kill me.")  Sadly, Ed's plane was subsequently destroyed by Hurricane Gustav (while in a supposedly hurricane-proof hanger) later this year.

Sorry about the quality, it was incredibly crowded and Ed and Scott weren't posing. This was on the day of the launch. Scott came out and looked at our Street View vehicle, then narrated the launch for us. Scott is a former 4-time astronaut and has a great deadpan delivery ("okay we just burned off a million pounds of propellant"); he's probably done it a hundred times.

Here's Mike Foale, who Ed has closed the hatch on twice (that means Mike was in the crew after Ed at the ISS twice).


I enjoyed meeting the people and looking at the hardware quite a bit more than the spectacle of the actual launch itself. Basically, the Shuttle makes a big white cloud, climbs out, loud noises ensue, and within two minutes you can just make out the SRB seperation with your unaided eyes, and it's gone. The Indy 500, for instance, is louder, and more interesting because there are always going to be crashes and various anomalies, which are not usually injurious and therefore lots of fun for the crowd. After meeting all those competent people who are working so hard to thread this finicky beast through a loophole in Murphy's law, I was just praying the thing wouldn't break on the way up.


P.S. That's Steve Wozniak, cofounder of Apple Computer.