People often focus on the potential of quantum computing, but generally focus far too little on the potential of quantum sensing.
We revolutionized the precision of timekeeping with atomic clocks. Quantum inertial sensors could precisely track your location with very little drift and no satellite constellation maintenance.
sych a device would still require synchronization, it promises lower drift, but to eliminate drift you will always need to recallibrate to synchronize with reference points (stars, beacons, GPS, ...)
I wonder what kind of improvement you can get by using several of the devices at once? Could some sort of consensus monitoring at least tell you what kind of margin of error you are working with ? I guess for some applications being 100m out is fine (for example an Astute in open ocean), but getting it that wrong in, for example, the Med or the Sound of Skye is probably a problem.
That’s true when averaging together iid samples, but you could probably do something smarter if you know about the likely errors and the sensors’ covariance. For example, if three of the four sensors agree, you should probably completely disregard the fourth, rather than averaging it in.
Of course, when you decrease the size of the sensor by half in each dimension while maintaining its error rate you've quadrupled the number of sensors. If you can increase the computing power similarly, or decrease the computing requirements for combining those sensor measurements - it quickly becomes feasible to use massive numbers of sensors to improve the standard error significantly - but it is a lot of ifs.
Practical example, you'd only have to shrink the sensor by half 6 or 7 times to fit 100 in the same area as 1.
Even quantum sensors will need something (i.e., another sensor) to stabilize the vertical channel. The effect of imperfectly compensating the gravity component out of the specific force measurements from the accelerometers leads to a positive feedback loop. Finite precision arithmetic and fundamental algorithm error (solving the Bortz equation) leads to errors that will grow in the horizontal direction as well.
Before the days of GPS in the cockpit, a relative of mine was a 747 captain doing routes across the Pacific. On one flight, all of the gyros went offline.
He had been trained in the US Air Force in celestial navigation, so he was able to use that to get the aircraft within range of a beacon, and land safely.
Airplane compasses are indeed affected by the electrical system, but not so much as to make them unusable. A maintenance process known colloquially as "swinging the compass" involves turning on the electronics, positioning the aircraft over a compass rose painted on the ground, and noting the error at various bearings.
As for the metal, most metal airframes are aluminum.
A compass would probably be of marginal utility if you're flying a "great circle" route across an ocean. For instance, if you were to fly non-stop from Chicago to London, your initial route will have you heading north east, but at the end, you'll be heading south east.
While this is true, an aircraft has very critical fuel requirements - taking a longer and less efficient route combined with a faulty navigation system is a factor best avoided.
All airplanes (or almost all? I'm sure someone will know of an exception) have compasses. But without data on wind direction and speed, a compass isn't much good over any appreciable distance. Once off the ground, an airplane is like a boat crossing a swift river. The boat won't land where it's pointed; it'll move with the current as it crosses and end up landing downstream of where it's pointed. So it is with airplanes. They don't fly where they're pointed; they move with the wind as they fly.
Boeing 707s were equipped with sextant periscopes. It's popular belief that 737s used to be as well, though I believe that was only the case for a handful of 737s purpose built for the USAF.
does anyone know if astro navigation systems deduce time from star transits (or rather generalized star transits, so they don't need to actually be momentarily collinear, i.e. a database of stars with their distances included)?
The article mentions a "highly accurate chronometer" in regards to the Blackbird. So I don't think they deduce time from the stars.
Rhubidium atomic clocks are quite compact and not all that expensive. Hobbyist electronics people buy retired ones from cell phone base stations for an accurate 10 MHz sync signal in their home labs.
The SR-71 carried a clock accurate to a hundredth of a second [1]. It used that, combined with current observed locations of the brightest stars in the field of view to determine location (with reference to a catalogue).
consider for example 2 very distant stars, and a closer star in the middle, and all of them in a plane perpendicular to the ecliptic. as the earth rotates, the closest star seems to move left/right with respect to the "vertical" defined by the more distant stars. from such a star transit you know the earth has just passed through the plane defined by these stars, and hence know the earth's position, hence the time.
in the past catalogues for transits were optimized for human use, i.e. close to each other, ... but a modernized i.e. software solution should not need such proximity, and could make use of all the visible stars to make a more accurate assessment.
I was kind of asking if there were any free open source software, it would be kind of neat to have an emergency laptop (with some optics) loaded with openstreetmap and astronomical positioning software, ...
I might be off here, but it seems like resolution would be a real issue.
The variation you are looking for has a period of 1 year. To get hour accuracy out of that you'd need to be able to distinguish 356*24 different relative positions of these stars. It seems to me like camera's aren't going to be supplying that kind of data.
I don't see why they have to reach back and summon the mystic name of the Habu when astronav is still flying on the B-2 and Trident SLBM. It's not as if we have fogotten that the technology exists, it's just that GPS is non-mechanical and more deployable, cheaper and robust.
Side project I've wanted to do for years: smartphone AR app that you point at the night sky and it does the star recognition and calculations automatically. But I've no illusions that it would be much less practical than just using the onboard GNSS receiver.
It's about redundancy and failure modes. The fine article mentions this. What if GPS is jammed or spoofed? What do you do then? Celestial navigation gives a fallback (albeit with less accuracy).
Regarding your side project - Google Sky does the opposite already. Point your phone at the sky, and it tells you what stars, planets, constellations, etc are there.
The issue is light. Your typical smartphone camera in its default package simply cannot get enough light to create a stars-against-dark-background image regardless of how much machine learning and signal processing you throw at it. It's much easier when you have a massive roof mounted lens. There are ways to improve gain and boost the optical signal but there are limits to what's possible in a smartphone without hardware additions or modifications (even with dual cameras like modern flagships).
Doesn't work, unless you have a tripod and use a significant exposure time. Perhaps. It's nowhere near "AR" levels. If you are going to go that far, save yourself some trouble and get a proper astrophotography setup. Also, astronomy.net is overkill for this.
Precisely as I said. If you are going to get a tripod rig and long exposure then might as well save some effort and just do a full astrophotography system (star trackers are cheaper than you think) instead of trying to squeeze more light from tiny phone cameras.
Fwiw the OP's point of reference in the child post is Google Sky Map. The Pixel's AI post is so far from the UX required for AR that there's honestly not much point to it. If you are going to do night time photography, go get a lens or at least a photomultiplier. The Pixel's AI camera is a nice gimmick for improving nighttime photography but using it for AR live celestial navigation is a bit like key chording a Gameboy to control a XBox. Theoretically usable given enough patience and time but way out of the horizon from its intended UX. I have tried out the Night Sight before and it's nowhere close to Point and Shoot for astrophotography.
You can build a celestial navigation system pretty easily for e.g. your car. You don't even need a lot of computational power. A Raspberry Pi would be overkill but considering how cheap the RPi Zeros are, might want to consider using one.
Summary: You an mix the coordinates obtained from celestial navigation (stars) with signals of opportunity (Electromagnetic sources like FM) to find the position without GPS.
Problems: Anytime a military advertisement happens (LN-120G Stellar-Inertial-GPS from Northup G.) - if you don't see the total price of the unit, know that it was a waste of money and resources.
<rant> This is one of the most obnoxious websites I have ever encountered. It popped up an ad covering the content. I clicked on the close ad "x" like I always do. Then another box popped up asking if I never wanted to see this ad again, and I replied "yes". Then another box popped up asking why I didn't want to see this ad. I replied, and another box popped up saying the ad had been closed by Google. That box remained over the content for 3 or 4 seconds. That box eventually faded, but literally 2 seconds later, another ad popped up, covering the content, and I clicked the back button. I will never click on a story from that website again. </rant>
This is another pain point for me. I learned quite some time back to right-click on the back button to pull down the history, then click on the url I want to go back to.
<unrant> I must confess that when I went to the website containing this article, I was using a second computer that I rarely use, which did not have an adblocker installed. My primary computer has Firefox Privacy Badger installed, and when I went back to the article, using my adblocked machine, the experience was much less obnoxious.</unrant>
What I HIGHLY recommend now is that if you don't have an adblocker installed, do so. Privacy Badger, UBlock Origin, etc, whatever you prefer. I still see ads, but the experience is infinitely less obnoxious.
I'd like to point out that with uMatrix set to block all javascript, including first party, the article still renders just fine. The only thing missing is the youtube embeds, which are replaced by hyperlinks to the youtube videos.
I find this to be the case more often than not. Most people here would probably be surprised how often javascript is totally unnecessary.
Whenever someone asks me to explain how GPS works, I give the example given in the article: Sailors used to track the position of stars in the sky. Since stars are hard to see during the day, and you can see them through walls, we put some artificial stars in the sky that we can identify easy and we put enough of them there's always a few above you.
With stars, you measure angle above the horizon and compass heading of the star. With GPS you are measuring time-delay of a signal. Those are two very different ways of navigating.
GPS signals aren't cryptographically signed. It's a bizarre oversight since it could prevent spoofing. I guess it's just another example of the tradition for zero-security software.
If nothing else, the current interest in cryptocurrency will train a new generation of developers to trust no message.
How often would keys be rotated, and can that be done from the ground? And then, the nightmare of ensuring that updated certs for the keys get rolled out to all the devices so they don't all panic and say that the GPS isn't working at all anymore. For that, cell phones would probably be the easiest despite jerkass behaviour of manufacturers and service providers. Embedded GPS updating would be an absolute nightmare.
Of course, celestial navigation doesn't work in the daytime. It also seem weird to write an article aimed at readers who have never heard of it, but not mention the existence of terrain contour matching, which is widely used on cruise missiles and works any time of day.
A noonsite is just the base reference. Once you’ve done that and compared it in the table you have your position. Any site after that is the delta until the next noonsite.
They don't have to be visible to the human eyes, just visible to instruments. With band filters and a narrow field of view you can get a stronger signal that sticks out from the the approximately uniform sky background. I mean the altitude helps, but it's not necessary.
Celestial navigation works in the daytime. Star tracking was part of the SR-71 G&C system. The stellar inertial platform was aligned preflight with the aircraft at rest. Day or night made no matter.
It had many initialization modes, at least one of which required tracking two stars within 5 minutes. It's alluded to at [1].
Boots on the ground could use laser communications to satcom for coordinate corrections, bypassing the locale drift, or better yet, retransmitting over the spoofed signal with higher strength.
It's tough to align a laser precisely enough to reliably hit a satellite. The necessary equipment is too heavy and fragile for ground troops. Plus it doesn't work through clouds.
Neat article. The Pentagon has been aware of this for a while now (though as I understand, the Navy only recently brought back celestial navigation into it's curriculum) but what's neat to me is how we might have had say, one backup method for navigation before falling back to manual methods (usually INS, which the U.S. was a leader in). But modern computers allow for pulling together a vast array of sources like the NAVSOP system described.
One method I thought was neat: I play a lot of military flight sims, with my favorite aircraft being the AJS-37 Viggen from the 1970s. A lot of aircraft of this period used TACAN for navigation supplemented by INS for missions over friendly territory. But not the Swedes. They used INS, with fixes being made by the pilot using it's ground radar to identify features on the ground that would correspond on a map. The idea was that you'd program your flight plan into the computer, with your waypoints being say, a bit of land that jutted out on a coastline, or a bridge, or a tiny lake. When you're flying, as your approach the feature, there would be a little "+" where the feature should be, which may or may not have drifted. The feature would be visible on the radar, and since the pilot knew it had to be centered on it, he would correct the waypoint and skew it back onto the feature it should be on. That would then update the rest of the waypoints in the system, correcting the drift.
This is modeled in the game, and so when I'm going to hit a target, I'll have a nav fix some 20-30km from the target as the actual thing I'm hitting might not be identifiable on the radar. But my INS will be corrected just shy of the target, and I can be reasonably sure it won't drift too much when I arrive in the area. We can hit points in darkness or poor weather with no visibility, no GPS, no night vision. It's not fantastic, but it's reasonably capable, and requires no outside input.
The Swedes later added TERCOM to the jet in the 90s (same thing early models of the Tomahawk used to navigate) which means the INS drift is now largely corrected automatically, but if this for some reason isn't working (in the game you can perform a TERCOM fix anywhere, but in real life the amount of ground maps that could be stored was limited, so if you were wildly off course it wouldn't be able to match where you were), we still have the radar nav fix backup.
The maths behind this kind of fusion of different data sources is also pretty beautiful. Kalman filters (https://www.bzarg.com/p/how-a-kalman-filter-works-in-picture...) are similar to the sensor fusion community what RNNs are to machine learning; simply stick all your data sources in with their uncertainties, and put pops a corrected estimate (in this case, position). It makes it much easier to combine data sources with rapid refresh rate but high integral error (IMU, gyroscopes, ...) with GPS/celestial navigation.
You don't necessarily need people — the impact of snowfall on the Soviet landmass was a concern during the development of various types of guidance systems.
IT's funny how my understanding of warfare changes over time. As a youngling, it's all about sleek shapes and speed and boom boom (that may be a criticism of how society raises men as well).
Now, it's more about how one side's nerds outthinks the other side in terms of sensors, data, etc. Even in the macho world of fighter planes (i.e. JSF and how everyone is thinking of detecting signals vs. hiding signals).
It's a weird juxtaposition - the techworld and silicon valley's general ethos about changing the world, democratizing tech, etc, vs. nerds coming up w/ ways to better kill each other...
The USAF would prefer more accurate inertial systems. Modern bombing runs are often near the ground, not at high altitude where the stars are visible.
DARPA is working on this.[1][3] They're trying to get MEMS gyros up to navigation grade, and funding work on something called "single atom interferometry".[2]
76 comments
[ 4.6 ms ] story [ 136 ms ] threadWe revolutionized the precision of timekeeping with atomic clocks. Quantum inertial sensors could precisely track your location with very little drift and no satellite constellation maintenance.
https://www.newscientist.com/article/mg22229694-000-quantum-...
Assuming measurements are independent and errors are Gaussian, the Kalman filter is this smarter thing. Variants exist for nonlinear systems.
https://en.wikipedia.org/wiki/Kalman_filter
Practical example, you'd only have to shrink the sensor by half 6 or 7 times to fit 100 in the same area as 1.
He had been trained in the US Air Force in celestial navigation, so he was able to use that to get the aircraft within range of a beacon, and land safely.
edit: yes they do https://en.wikipedia.org/wiki/Flight_instruments
As for the metal, most metal airframes are aluminum.
Rhubidium atomic clocks are quite compact and not all that expensive. Hobbyist electronics people buy retired ones from cell phone base stations for an accurate 10 MHz sync signal in their home labs.
https://www.eevblog.com/2012/01/14/eevblog-235-rubidium-freq...
More info here: https://books.google.co.uk/books?id=6svmtOFa1JIC&pg=PA65&lpg...
What do you mean by a transit in this case?
https://en.wikipedia.org/wiki/Transit_instrument
consider for example 2 very distant stars, and a closer star in the middle, and all of them in a plane perpendicular to the ecliptic. as the earth rotates, the closest star seems to move left/right with respect to the "vertical" defined by the more distant stars. from such a star transit you know the earth has just passed through the plane defined by these stars, and hence know the earth's position, hence the time.
in the past catalogues for transits were optimized for human use, i.e. close to each other, ... but a modernized i.e. software solution should not need such proximity, and could make use of all the visible stars to make a more accurate assessment.
I was kind of asking if there were any free open source software, it would be kind of neat to have an emergency laptop (with some optics) loaded with openstreetmap and astronomical positioning software, ...
The variation you are looking for has a period of 1 year. To get hour accuracy out of that you'd need to be able to distinguish 356*24 different relative positions of these stars. It seems to me like camera's aren't going to be supplying that kind of data.
Side project I've wanted to do for years: smartphone AR app that you point at the night sky and it does the star recognition and calculations automatically. But I've no illusions that it would be much less practical than just using the onboard GNSS receiver.
Regarding your side project - Google Sky does the opposite already. Point your phone at the sky, and it tells you what stars, planets, constellations, etc are there.
See for example (not Night Sight though): https://ai.googleblog.com/2017/04/experimental-nighttime-pho...
Fwiw the OP's point of reference in the child post is Google Sky Map. The Pixel's AI post is so far from the UX required for AR that there's honestly not much point to it. If you are going to do night time photography, go get a lens or at least a photomultiplier. The Pixel's AI camera is a nice gimmick for improving nighttime photography but using it for AR live celestial navigation is a bit like key chording a Gameboy to control a XBox. Theoretically usable given enough patience and time but way out of the horizon from its intended UX. I have tried out the Night Sight before and it's nowhere close to Point and Shoot for astrophotography.
You can build a celestial navigation system pretty easily for e.g. your car. You don't even need a lot of computational power. A Raspberry Pi would be overkill but considering how cheap the RPi Zeros are, might want to consider using one.
Problems: Anytime a military advertisement happens (LN-120G Stellar-Inertial-GPS from Northup G.) - if you don't see the total price of the unit, know that it was a waste of money and resources.
What I HIGHLY recommend now is that if you don't have an adblocker installed, do so. Privacy Badger, UBlock Origin, etc, whatever you prefer. I still see ads, but the experience is infinitely less obnoxious.
I find this to be the case more often than not. Most people here would probably be surprised how often javascript is totally unnecessary.
But, I use FF with an adblocker and I never see ads, much less pop ups.
If your browser configuration allows that kind of annoyance, it may be "because it can."
With stars, you measure angle above the horizon and compass heading of the star. With GPS you are measuring time-delay of a signal. Those are two very different ways of navigating.
If nothing else, the current interest in cryptocurrency will train a new generation of developers to trust no message.
Also, there are other methods to find position data.
https://en.m.wikipedia.org/wiki/TERCOM
Even with a simple sextant you can use the sun. And the SR71's system did operate during daytime using starlight.
It had many initialization modes, at least one of which required tracking two stars within 5 minutes. It's alluded to at [1].
[1] https://www.sr-71.org/blackbird/manual/4/4-40.php
One method I thought was neat: I play a lot of military flight sims, with my favorite aircraft being the AJS-37 Viggen from the 1970s. A lot of aircraft of this period used TACAN for navigation supplemented by INS for missions over friendly territory. But not the Swedes. They used INS, with fixes being made by the pilot using it's ground radar to identify features on the ground that would correspond on a map. The idea was that you'd program your flight plan into the computer, with your waypoints being say, a bit of land that jutted out on a coastline, or a bridge, or a tiny lake. When you're flying, as your approach the feature, there would be a little "+" where the feature should be, which may or may not have drifted. The feature would be visible on the radar, and since the pilot knew it had to be centered on it, he would correct the waypoint and skew it back onto the feature it should be on. That would then update the rest of the waypoints in the system, correcting the drift.
This is modeled in the game, and so when I'm going to hit a target, I'll have a nav fix some 20-30km from the target as the actual thing I'm hitting might not be identifiable on the radar. But my INS will be corrected just shy of the target, and I can be reasonably sure it won't drift too much when I arrive in the area. We can hit points in darkness or poor weather with no visibility, no GPS, no night vision. It's not fantastic, but it's reasonably capable, and requires no outside input.
The Swedes later added TERCOM to the jet in the 90s (same thing early models of the Tomahawk used to navigate) which means the INS drift is now largely corrected automatically, but if this for some reason isn't working (in the game you can perform a TERCOM fix anywhere, but in real life the amount of ground maps that could be stored was limited, so if you were wildly off course it wouldn't be able to match where you were), we still have the radar nav fix backup.
Neat stuff. =)
1) using visual keypoints ala https://scape.io
2) a much older idea, used in cruse missiles: radar contour mapping.
3) decca or loran
3.5) passive radar
4) inertial dead reckoning(sensors are much, much better nowadays).
5) laser painting way points.
6) multi spectral, multi viewpoint cameras with slam/visual odometery (with a database of coast lines for pinpointing land fall.)
or better yet, a combo of all of them. The more data points the better.
Now, it's more about how one side's nerds outthinks the other side in terms of sensors, data, etc. Even in the macho world of fighter planes (i.e. JSF and how everyone is thinking of detecting signals vs. hiding signals).
It's a weird juxtaposition - the techworld and silicon valley's general ethos about changing the world, democratizing tech, etc, vs. nerds coming up w/ ways to better kill each other...
DARPA is working on this.[1][3] They're trying to get MEMS gyros up to navigation grade, and funding work on something called "single atom interferometry".[2]
[1] https://www.darpa.mil/program/adaptable-navigation-systems [2] http://web.stanford.edu/group/scpnt/pnt/PNT07/Presentations/... [3] https://www.darpa.mil/program/micro-technology-for-positioni...