sun sensor

[sharaf-roboking]

Hi,
I have developed an algorithm and a sun sensor model using an array of photoresistors, similar to the one shown in the attached image.

I then simulated the trajectory of the sun in a Unity environment and tested my algorithm and sensor model. The current model is able to calculate the azimuth and elevation of the sun. After comparing the results with the ground truth data, I obtained an output error of around 1 degree in both elevation and azimuth.

Now, I would like to estimate the longitude and latitude using the calculated elevation and azimuth of the sun along with the time. Is it possible to determine the location using these values? I am currently struggling with this step and would appreciate your guidance on how to calculate the latitude and longitude on Earth using the sun’s elevation and azimuth.
can I use astropy of skyfield to estimate the lat and long?

thanks

[EndlessDex]

Not sure how much help you want. I could give you the exact code BUT I won't for now.

The answer lies with Spherical Trigonometry. These are the same principles as a sextant/astrolabe that were used for navigation pre-GPS.
This book is one of the most popular Astronomy textbooks. Section 2.5 has all the equations you will need. Note that historically measurements were only made at local noon which greatly simplifies the equations (bunch of terms go to 0/1).

Basically you can use Skyfield to calculate a theoretical Right Ascension and Declination of the sun (these values are historically presented to sailors and others in the Astronomical Almanac). This example shows how, just use the sun instead of mars.

From there you need to solve the equations presented in the book. Specifically
Eq 2.14: sin(dec) = sin(alt)*sin(lat) + cos(alt)*cos(lat)*cos(az)
Eq 2.16: cos(HA) = (sin(alt) - sin(lat)*sin(dec)) / (cos(lat)*cos(dec))
Eq 2.11 + wiki: HA = LST - RA -> HA = GMST + LON - RA -> LON = HA + RA - GMST

This is slightly non-trivial and I used an equation solver to build the matrix calculation.

[sharaf-roboking]

Hi @EndlessDex,

thanks a lot for your response I really appreciate your guidance here.
I come from a robotics background and I’m still quite new to celestial navigation.
but I’ve been going through your suggested approach based on spherical trigonometry (Section 2.5), and I just want to make sure I’m interpreting the problem correctly from an estimation point of view.

From what I understand, at a given UTC timestamp, I can use an astronomical model such as Skyfield to obtain the theoretical solar parameters including Right Ascension (RA), Declination (Dec), and GMST, while my onboard sun sensor measures the Sun’s elevation (alt) and azimuth (az). So effectively at time t, my known inputs are the measured altitude and azimuth together with RA(t), Dec(t), and GMST(t), while the unknowns are the observer’s latitude and longitude. However, when I look at the equations such as

Eq 2.14: sin(dec) = sin(alt)*sin(lat) + cos(alt)*cos(lat)*cos(az)
Eq 2.16: cos(HA) = (sin(alt) - sin(lat)*sin(dec)) / (cos(lat)*cos(dec))
Eq 2.11 + wiki: HA = LST - RA -> HA = GMST + LON - RA -> LON = HA + RA - GMST

it appears that latitude and longitude are required in order to evaluate these expressions. So my question is whether these equations are intended to be directly evaluated, or instead solved as a nonlinear system for latitude and longitude given the measured altitude, azimuth, and time-derived solar parameters.
In other words, I’m trying to treat this as an inverse observation problem similar to robotic localization, where we estimate the state (lat, lon) that best explains the measured sun vector at time t. In my project, I’m mounting a sun sensor on a marine robot (boat) to measure elevation and azimuth continuously at around 1 Hz, and using timestamped measurements to estimate geographic position in real time and compare the resulting trajectory against ground truth GNSS data, with a target position accuracy of around 100–500 m. Currently, I’ve implemented a Marcq St. Hilaire (intercept)-based solution, where each sun sight uses the measured altitude and timestamp to compute the Sun’s Geographic Position (GP), compares the measured altitude with the predicted altitude from an assumed position, computes the intercept to form a Line of Position (LOP), and then uses multiple sights at different times to generate LOP pairs whose intersections are averaged to reduce random sensor noise. Based on simulations, with approximately 0.5° elevation measurement error, this approach gives roughly 50–60 km position accuracy for around 10 sights.

Therefore, I’m unsure whether this classical LOP-intersection approach is appropriate for a continuously sampled robotic platform, or whether a nonlinear solver or filtering formulation based on solving Eq 2.14–2.16 over time would be more suitable for achieving sub-kilometer accuracy, and I would really appreciate your advice on whether your approach could realistically achieve 100–500 m accuracy under these conditions.

I would greatly appreciate it if you could share your code with me.
many Thanks