Autonomous Celestial Navigation for sUAS

Project Goal:

Small Uncrewed Aircraft Systems (sUAS) are a class of aircraft that weigh less than 55 lbs and have been used for agriculture, disaster response, logistics, climate research, and wildlife monitoring among many other functions. As such, reliable and consistent navigation is of paramount importance for sUAS.

Today, the state of the art in navigation is GNSS, or global navigation satellite systems, thanks to its widespread availability and high-accuracy capabilities. However, due to the inherent vulnerability of GNSS to jamming, multipath effects and other weaknesses stemming from its reliance on a satellite network, significant need has been expressed in the subject of autonomous navigation systems for sUAS.

Of particular interest are celestial navigation systems (CNS), for their autonomous capabilities in the absence of terrain features. CNS fused with a dead-reckoning Inertial Navigation Systems (INS), have demonstrated significant promise for low-cost autonomous navigation.

This project explored the feasibility of implementing CNS/INS in sUAS given reasonable Size, Weight, Power, Cost, Cooling, and Compatibility (SWaP-C3) constraints, among others. It began with a literature survey to evaluate the state of the art in CNS/INS. I then worked to characterize an improved system that may be reasonably be designed and manufactured in house. The development of the geolocation algorithm will be discussed as will be its future expansion.

Example of an sUAS. Image Source: San Juan College, https://www.sanjuancollege.edu/education-training/programs/small-unmanned-aerial-systems-certificate/

Skills Used:

MATLAB
Simulation and validation
Hardware/software schematic development
Project management
Technical writing

Results/Significance:

A promising and reliable daytime celestial navigation algorithm was developed based on a low-cost hardware setup. The algorithm shows potential for even more improvement through Kalman filtering and is designed with this next step in mind. The feasibility of autonomous celestial navigation in sUAS is demonstrated through simulation.

Figure 1: Intersection of two zenith LOPs. Image Source: Geoffrey Kolbe, Celestial Navigation Terms, geoffrey-kolbe.com

Background/Problem Space:

Celestial navigation has been used as a maritime navigation method for centuries. Broadly speaking, the process involves the construction of two Lines of Position (LOPs), where each line represents all the points on Earth where the observer would measure the same angle to a celestial body, such as the azimuth or zenith of a star. The azimuth angle is the compass direction the observer is facing to see a celestial object, measured in degrees from the north pole. The zenith angle is how "high" the object is in the sky, measured as the angle between the object and the point directly above the observer. If the object is directly above the observer, the zenith angle is 0 degrees, and if its at the horizon, the zenith angle is 90 degrees.

Typically, this LOP is constructed using the zenith angle, where the LOP becomes a circle centered around the Geographic Position (GP) of the celestial reference, or the location on the earth where the measured zenith would be 0 degrees. The GP can be thought of as the location "directly below" the celestial reference. By obtaining at least two LOPs, two intersections can be deduced as is shown above in Fig. 1. Often, the intersections are far enough apart that one can easily be selected the navigation solution.

Celestial navigation presents a unique challenge for sUAS because they typically operate in low-altitude conditions, where the optical effects from the atmosphere limit nighttime star visibility and all but eliminate it during the daytime. For this reason, daytime navigation solutions often rely on the sun as a celestial reference. However, this presents a problem because in order to converge on a solution, we need at least two LOPs. For this reason, my celestial navigation solution, written in MATLAB, employs not one but two celestial measurements: the zenith and the azimuth of the sun, as shown in Fig. 2.

Figure 2: Intersection of a zenith LOP and an azimuth LOP. Image Source: "Interval-Based Celestial Geolocation using a Camera Array", by Cheng Liu, Fei Yang, and Kartik B. Ariyur, IEEE Sensors Journal, 16(15):5964-5973, August 2016

Figure 3: Hemispherical Camera Array. Image Source: "Interval-Based Celestial Geolocation using a Camera Array", by Cheng Liu, Fei Yang, and Kartik B. Ariyur, IEEE Sensors Journal, 16(15):5964-5973, August 2016

These requirements could be met with a fairly cheap and easy to manufacture setup: a hemispherical array of nine twenty dollar charged coupled device cameras (CCD), and a two-hundred-dollar Attitude Heading Reference System (AHRS) would suffice, as is shown in Fig. 3. Development of the MATLAB script is discussed in the next section. My solution would also employ a two hundered dollar mid-tier IMU.

Improved Algorithm Implementation:

My program begins with a simulation module, where a set of positions across time are predefined, and the solar azimuth and zenith values that would have been measured at those positions are simulated. At the time time, IMU data is simulated using a predefined MATLAB package.

The subsequent geolocation module takes a general outline similar to that discussed in the reference paper (Liu et. al, 2016), with a major difference coming from the simulated IMU data. The dead-reckoning IMU solution can be used to make an initial guess as to the current location of the sUAS. A grid of coordinates is constructed around this initial guess, with some predetermined latitude and longitude ranges and a predetermined number of grid locations. The theoretical solar azimuth and zenith at each point are calculated and checked with the "measured" values (from the simulation module) within some tolerance. The grid is reduced to include only the points that qualify from this previous check, and the process is repeated, with the tolerances decreasing after each iteration until they reach a desired tolerance, ideally one based on instrumentation error.

Figure 4: Navigation Solution with azimuth and zenith-matching locations, and mean estimate and covariance ellipse.

This approach avoids the computational burden that would come with brute-force calculating the azimuth and zenith values for every point on a high-resolution grid of the Earth. It takes a-priori IMU data to inform the next estimate, and an iterative approach to achieve satisfactory tolerances and grid resolutions. The reference paper (Liu et. al) ends here though, where my algorithm goes yet one step further: the grid of locations that satisfy the zenith and azimuth conditions aren't a suitable solution for implementation in state estimation filters such as Kalman Filters which represent the standard in modern navigation.

My program models the fact that each point on this grid of satisfactory locations are not equally probable, a fact that turns out to be crucial. By modeling instrument error as a Gaussian and propogating these probabilities to the grid locations, I found that the solution can be fitted to a 2D Gaussian, leading to a solution in the form of a mean location and a stochastic covariance ellipse. One such probability distribution is shown in Fig. 5. The covariance ellipse can be see more clearly beneath the grid in Fig. 4. Thus, my algorithm produces a navigation solution fit for use in state estimation filters, which would lead to an even more robust navigation solution overall, adequate for application in sUAS control algorithms.

Figure 5: Probability Distribution for a grid of locations centered in Huntsville, AL.

Future Developments:

While I was able to produce a navigation solution with a frequency of about 5 Hz (up from 0.05 Hz) I believe steps can be taken to improve it even more.

Figure 5: IMU-simulated trajectory drift.

Kalman Filtering: Implementing a state estimation algorithm such as a Kalman Filter would not only lead to a more robust navigation solution with lower uncertainties, but it would also rectify a problem that occurs with the current algorithm: as the duration of a trip goes on, the IMU estimation trajectory drifts away from the true trajectory. This problem, known as IMU drift, means that the initial grid constructed around the IMU estimate must become larger after each iteration to compensate, or a cap must be set on trip durations. However, by implementing a Kalman Filter, the IMU trajectory may be "fused" with the celestial navigation solution, thus compensating for this drift
Implement Real Hardware: This is an obvious one: what's an algorithm without hardware to support it? Just as importantly, though, by implementing and characterizing hardware, I can get a better idea as to the limits of the algorithm. For example, in certain instances, decreasing the azimuth angle error by a factor of 10 can result in a covariance ellipses hundreds of km smaller.

A more detailed/technical account of this project can be found here!

Investigation_of_Celestial_methods_Applied_to_sUAS.pdf

Page updated

Google Sites

Report abuse