Why doesn't New Horizons have a tracking function

Question

Dr. John Spencer mentioned in the live feed for the Ultima Thule flyby they're taking a series of LORRI shots along a precomputed path hoping to capture the KBO. What were the obstacles to equip the spacecraft with object tracking capability?

Answer 1

TLDR: It probably would be possible but would only be feasible during the approach phase.

---

In theory the New Horizons probe probably could do so. In practice is would be awkward to implement and would likely negatively impact data collection.

New Horizons has two computers (plus one spare for each). The first is "Command and Data Handling" (C&DH) which handles the science instruments, science data storage, radios, and system health monitoring. The second is "Guidance and Control" (G&C) which handles power, navigation (star and sun trackers, IMUs), attitude control, propulsion, and thermal control. Each computer is similar in specs to a ca. 1989 workstation (SGI Personal Iris 4D/20 or /25) with a 12 MIPS¹ CPU and 16MB of RAM². While there is some very detailed information available on these systems there are also a lot of big gaps. This makes it hard to definitively answer but I'll do my best.

^{1 I've seen this given as 15 MIPS but the R3000 CPU isn't superscalar. They may be underclocked 15 MHz parts.
2 At least for the G&C; I suspect that the C&DH has about the same.}

Raw CPU

The most obvious bottleneck is the CPU. The CPU used is essentially a pipelined MIPS R3000 CPU that (ideally) can retire one instruction per clock cycle. Let's look at a toy example to see whether it's up to the task. Let's scan an image buffer and do something for non-zero pixels; in (non-ideal) MIPS assembly:

      LA   $1, buffer      # Load buffer start address (to register 1)
      LI   $2, size        # Load buffer size in pixels (to register 2)

loop: LHU  $3, ($1)        # Read one pixel of image data (to register 3)
      BEQ  $3, $0, cont    # Skip processing for zero pixels (register 0 is always 0)
      JAL  do_something    # Call subroutine for non-zero pixels
cont: ADDU $1, $1, 2       # Increment buffer pointer (16-bit pixels)
      SUBU $2, $2, 1       # Decrement length
      BGTZ $2, loop        # Loop if we still have data to process

Let's assume that all code is cached, that we never encounter pipeline stalls, and that all loads are free.³ The above loop would then average 6 clock cycles to examine one pixel so at 12 MHz we can look at 2 million pixels or about two sparse 1024×1024 LORRI frames every second. Actually doing something useful would probably be at least an order of magnitude slower. So a bit slow but certainly feasible.

^{3 This is unrealistic but good enough for a very rough estimate.}

Memory

Any new program added takes up memory and New Horizons only has 768kB of RAM devoted to program storage on each processor. Any image analysis program added would need to small so as to not impinge on other programs. Since there's always a trade-off between size and speed any added program would likely favor small and slow.

Image processing can require a lot of memory. One frame from LORRI takes about 2×1024×1024 bytes (2MB).⁴ The NH computers only have about 16MB⁵ of RAM⁶ each so even a single image buffer takes up a lot of space. I would think that in its as-launched configuration RAM is likely at a premium especially since the system already likely needs large buffers for IO and compression. The CPUs do support up to 256MB of DRAM or 192MB of SRAM so NH could have been designed with enough RAM for in-depth image analysis but probably doesn't actually have it. More RAM would have resulted in higher power requirements, higher total system cost, and greater chance of system failure, all good reasons to keep RAM to a minimum. Though RAM would probably be too scarce to do non-trivial image processing during a flyby it might be possible during approach when large IO buffers aren't needed.

^{4 LORRI actual uses 12-bit words, not 16, but 16 is easier to process so I'll use that.
5 I've actually only found a value for the G&C but let's assume they're similar.
6 It's not clear whether this is DRAM or SRAM.}

Real-time multitasking

The New Horizons computers run multitasking operating systems yet are also real-time systems. Care must be taken not to overload the system and to avoid deadlocks or resource starvation.⁷ There are mitigation techniques and NH implements some of them⁸ but heavy processing (even as a low-priority task) is still something to avoid during critical mission phases.

^{7 This isn't just theoretical; on July 4, 2010 NH experienced an overload while concurrently recording new commands to flash and compressing science data. The system went into failsafe mode and about 30 observations were lost.
8 For example, New Horizons won't go into safe mode during a flyby.}

Limited bandwidth

Though New Horizons has two computers, sharing bulk data between them is slow. The cameras are connected to the C&DH and its only connection to the G&C computer is a 1Mb/s bus⁹ that is shared by all subsystems on the G&C side. Assuming exclusive use of the bus, a single LORRI frame would take about 15 seconds to transfer. Offloading image processing tasks to the second processor (G&C) could thus be possible but would be slow and might be impractical in practice.

^{9 As with many of the numbers quoted here, this value is a best guess based on multiple sources.}

Software

The image analysis software would need to be written and thoroughly tested. There is limited program memory available so making it both small and fast could be a challenge. Interaction with existing software and the impact of program-commanding maneuvers on thruster fuel consumption would need to be carefully considered.

Other solutions

Had the system design been changed before flight a number of other approaches could have been taken:

• Allow G&C access to flash memory — As mentioned above, one option would be offloading image analysis to the second processor; this approach is hampered by the slow bus speed. One way to speed up data transfer between the sensor data (e.g. from LORRI) and the G&C computer would be to allow direct access by G&C to the 8GB flash memory holding the imaging data. I see two issues with this: 1) Added complexity and new point of failure in a critical area (the flash memory holds all the science data) 2) Any flaws in software, hardware, or the interaction of the two systems could destroy the data gathered. I think therefore that this approach would be unlikely.

• Dedicated processor card — The C&DH has a standard PCI bus and an dedicated card could be added to handle object search and tracking. Such a card could have a full computer on-board including dedicated processor and RAM¹⁰ and would run little risk of impacting the rest of the C&DH's operations. Being on C&DH's high-speed bus would make image transfer fast and easy. Some of the downsides to this approach are higher power budget, thermal considerations, and of course development and hardware cost.

  ^{10 The various instruments already have similar systems embedded.}

• Dedicated subsystem (sensors and processor) — A dedicated subsystem could have been added to the G&C side. Placed on the G&C's bus, it would have its own dedicated processor and RAM as well as one or more cameras¹¹. Such a system could find and track targets on its own then, say, feed attitude control commands directly to the G&C computer. Costs/benefit considerations are similar to those for a dedicated processor card with the caveat that costs would be much higher due to the dedicated imaging system.

  ^{11 New Horizons' star trackers are quite similar to this. Note that since the star trackers are absolutely critical it's highly unlikely that they would be modified to search for anything but stars. Using similar hardware (perhaps with the addition of a narrow-field camera) with modified firmware could be an option though.}

Conclusions

The computers and systems on New Horizons are limited in capability but in theory could be used to do simple object tracking. Running a heavy algorithm such as target search during a flyby is probably not feasible. Up until maybe 12 hours before flyby target selection and programming could be done from the ground. This leaves the approach phase as the only time when on-board image analysis and targeting would be both feasible and useful.

New Horizons specifications

New Horizons block diagram
^{Source: New Horizons Launch Press Kit, p. 26, NASA/JHUAPL/SwRI
(cropped, enhanced, and highlighted)}

All computers (and most subsystems) configured as redundant pairs. Note that many of these subsystems are full computers themselves with the own CPU, RAM, etc.

• Guidance and Control computer (red)
  Responsible for attitude control, orientation sensing, power control, and thermal control
  12 MHz Mongoose-V CPU, 16MB RAM (768kB for programs)
  1MHz MIL-STD-1553 bus connecting to rest of system

• Command and Data Handling computer (blue)
  12 MHz Mongoose-V CPU, 16MB RAM (768kB for programs)
  PCI bus for subsystem connections, connection (slave) to the G&C's 1Mb/s MIL-STD-1553 bus

  Each C&DH has:

  • SSR — 64Gb (8GB) solid state recorder (dark blue) with up to 13Mb/s bandwidth
  • Instrument Interface card that connects to all science instruments.
    ALICE, RALPH (MVIC and LEISA), and LORRI (the imagers) have high-speed LVDS links (purple) to each C&DH for image data.
    All other connections are 480Kb/s RS-422 serial lines
  • Downlink Tx card for transmitting science data back to Earth and for conducting radio experiments

• Science, radio, and health-monitoring systems (cyan)
  Connect directly to the C&DH

• Guidance, power and propulsion systems (yellow)
  These (along with the C&DH) connect to the G&C over a 1Mb/s bus (green)

Mongoose-V functional blocks

Source: Synova via the Internet Archive

References and further reading

• New Horizons Launch Press Kit
  Covers all aspects of the mission
• Spacecraft Overview
  Nice overview of New Horizons' systems
• Inside New Horizons
  Another overview of the systems
• The New Horizons Spacecraft (doi:10.1007/s11214-008-9374-8)
  Fairly detailed technical overview of New Horizons' computer systems
• Mongoose-V 32-bit MIPS Microprocessor Architecture Description
  The Mongoose-V is the radiation-hardened version of the MIPS R3000 CPU used on New Horizons
• Star tracker scan mode capability for the New Horizons mission
  Very interesting (but unfortunately paywalled) paper on the New Horizons star trackers
  See here for how you might get a free copy

Answer 2

New Horizons has an object tracker, a star tracker needed for navigation and attitude control.

There are two redundant A-STR star trackers. 10 times per second a wide area image of the background is taken and compared to a stored star chart containing 3000 stars.

Only bright stars may be used to get an image with a short exposure time. Faint stars and Kuiper belt objects are too dark to be imaged by this star camera in a short time.

The LORRI camera used for the many excellent pictures of Kuiper belt objects has a very small field of view: 0.29 degrees and needs long exposure times of 1 up to 30 seconds.

The detection of unknown Kuiper belt objects using LORRI is very difficult due to the very small field of view and the necessary long exposure time. To assemble a very moderate wide angle view of 30 ° width and height, about 10700 single images are needed for the mosaic. For detection of unkown objects, a series of such images should be compared to find tiny differences caused by the moving objects between the many fixed stars.

Answer 3

Excellent answer Alex, thank you.

For the technical implementation aspect I'd like to add 2 points:

• it might be possible to forgo taxing the cpu and not processing full resolution LORRI images in defining the target as a region at least a few pixels across and sampling a raster.
• as there's already 2 star trackers in there, I imagine adapting one for the task should have been possible at an acceptable time/cost overhead.

Speculating, I guess this wasn't implemented also because New Horizons was primarily conceptualized as a Pluto exploration mission, for which a programmed exposure pattern was good enough - the Kuiper Belt extension Alan Stern had to propose to NASA afterwards (he's a media savvy guy ;).

Nevertheless, it's quite a waste of valuable exploration (and downlink) time, even diregarding the risk of a miss. I also assume with precise position information, it would have been possible to compensate for motion blur, thus enhancing resolution.