TRACKING: CARTESIAN vs SPHERICAL COORDINATES

A widespread missed opportunity began many years ago and continues to this day.  It is still widely believed that significant nonlinearity is inescapable in a tracker – whether for dynamics with spherical coordinates or for measurements with Cartesian coordinates.  The first half of that is definitely true for dynamics using the classical (range/elevation/azimuth) frame in air-to-air encounters at close range; we’ll take that issue first here.

One question that could be raised immediately might sound something line this: Since expressing dynamics in a range/elevation/azimuth frame causes so many problems (not only linearity but many more, to be discussed shortly), why even consider that as a candidate approach?  Old-timers will readily recall that analog radars provided no other choice.  They had range trackers, while angle tracking was done separately in outer loops with bandwidths narrow in comparison to inner stabilization loops maintained via antenna-mounted gyros.  Couldn’t that still be done after digitization?  Yes – in fact, it was done.  In the early 1970s I reviewed a paper for IEEE showing just that.  I gave it the green light because it was correct.  For my own design, though, I used a Cartesian frame ( publication #24, 26, 28, 30, 32, 36, 60, 61, 66, and 69 -- It is worth noting that #66 combines #60 and #61).  No contest.

The widely recognized nonlinear degradation of a range/elevation/azimuth representation for dynamics only begins to explain why that choice is fraught with problems.  For one issue, that loop-within-a-loop situation imposed a demand on inner stabilization bandwidth; if too low it would compromise the overall operation’s stability.   Alternatively that requirement could be viewed as a constraint on track loop responsiveness.  Another very serious issue was the interfacing requirements; gyro and accelerometer data had to be used in that track configuration (which added another burden of time-tagging plus another degradation from time-tag imperfections).  Still another limitation was inability to represent multiple track files; they aren’t all in the same direction and their Line-of-Sight rates are anything but uniform.  Finally, if handoff of a track file became necessary (e.g., from a forward-looking to a side-looking sensor during fly-by), I wouldn’t want to inherit that task with (range/elevation/azimuth) dynamics at close but wildly changing distances and geometries.

The item just noted brings up a favorite example raised by my coauthor of publication #24 and 32 : Two aircraft approach each other on parallel tracks separated by 1000 ft.  With each having constant 1000 ft/sec groundspeed, the centripetal acceleration ( see Ex. 8-12c on page 295 of Integrated Aircraft Navigation ) at the instant of closest approach (sidelong position) is

or about 125 g.  The example is extreme but, even with more moderate encounters no range track loop can perform adequately in both responsiveness and noise rejection.  The second derivative of scalar distance is very high in close range scenarios.

Now a comparison to the Cartesian frame can begin.  Instantly the “problem” just shown disappears.  There isn’t any acceleration at all; all Cartesian velocity components are constant.  Then handoff is easy too.  We’re off to an excellent start.  Next: interfacing – that’s also easy – never mind the gyros and accelerometers, just adopt the INS nav frame as the Cartesian reference for tracking and use the nav computer output.  Eq. (2.13) of GNSS Aided Navigation and Tracking shows that it’s just as easy to track from a maneuvering fighter jet as it is while at rest.  Stabilization loop?  It isn’t inside any other loop; let it have whatever bandwidth it has.  Separate the stabilization offsets from tracker inputs as illustrated in Figure (9.2) of  GNSS Aided Navigation and Tracking .  That same “dot-off-the-crosshairs” figure, with its accompanying analysis (Section 9.2.2), readily reduces to negligible levels any measurement nonlinearities as well.  Multiple targets?  Again, easy – just maintain one track file for each object being tracked.

That was fast, wasn’t it?