Combining GPS with accelerometer and gyroscope is sometimes called "sensor fusion" - one common way of doing it is with a "Kalman filter" and if you google that you'll find a wealth of information.
If you've got plenty of money, companies like https://www.oxts.com/ have working systems available off the shelf. They're used for things like measuring the dynamic performance of cars.
Such systems will sorta work indoors but not very well. The gyroscope/accelerometer will gradually drift; when you're outdoors with a clear view of the sky, the GPS can compensate for that but when you're indoors that isn't possible. How fast the drift happens depends on how much money you spend to get the highest performance gyroscopes and accelerometers.
It's also possible to integrate other sensors, but that's application-dependent; for a car going through a tunnel, an odometer is a great addition, for a smartphone not so much.
GPS-denied navigation is the search term. It works well enough for driving through a tunnel, because eventually you get a known location to correct previous estimates. For a fully-indoor environment it's very difficult to get good results and the technique depends on the use-case.
"Indoor GPS" using bluetooth beacons is technically possible but the space is filled with proprietary protocols/apps that try to make money by serving ads. It unfortunately doesn't seem to be evolving into a more useful extension of google maps.
For indoor you will prefer UWB[0] where you can set up base stations yourself that offer a service pretty much like GNSS signals (i.e., you can passively receive them from 4+ base stations and turn those pseudoranges into a position, provided you are told where they are and kept updated about their clock drift relative to each other (e.g. by them listening to their neighbors and piggybacking 2-way-ranging sessions on top of the beacons they already broadcast, each offering the clock offset to their neighbors in the data payload of their own beacon)), with the added benefit that by using a shared-key CSPRNG to generate the bitstream of the ranging code instead of a fixed known sequence, you can get authenticated ranging where MITM attacks are limited to artificially inflating the range (i.e., a trigger of "has to be close enough to the door handle that e.g. a pair of cameras looking at the areas right in front of either side of the door have it in view" can't be faked with a wireless MITM).
There are some links/papers in the publications section[2] of [1].
For indoor, there's UWB, ultra wide band. Can also use Bluetooth or even lights blinking at different (high, non-humanly-visible) frequencies to do indoor positioning.
Making charts (of any kind) accessible is a really hard endeavour. I watched the demo videos and if I’m allowed to make a suggestion... Add the context to the data points. A simple “50k” might not cut it for people navigating the plot with their fingers over a smartphone.
Full disclosure: I worked with those peeps a decade ago and really love their work.
> Making charts (of any kind) accessible is a really hard endeavour.
Agreed! I've done a lot of experimenting with my canvas library to try and make accessibility a "first class citizen" in graphical representations, including charts. Things (I think) I've got right is to make it easier for people to use keyboard navigation to interrogate a chart, and making sure that graphical text gets properly copied into the DOM in an ordered way, and updates when the graphical text changes.
The main failure I face is getting screen readers to recognise that the graphical text exists/updates. For example, this chart demo[1] is responsive, interactive and keyboard accessible but, when listening to that page with VoiceOver on a Mac, there's a clear failure to get the current data point from the screen to the listener.
I know screen reader tech is the wildest of Wild Wests when it comes to front end. My only hope is that there's an easy solution to the issue, like I've badly misunderstood how screen readers work and the solution will be obvious when I stumble across the key errors I'm making ... and correct them!
One of my most favourite recursive acronyms is XINU which stands for "XINU Is Not Unix". The delightful thing about this acronym is that "XINU" is also the reverse of "UNIX".
Upon a closer look, it turns out that for a given word W, a recursive acronym proclaiming that it is not W while simultaneously being the reverse of the word W, we need W to be of the form W = "?NI?" where each "?" denotes a distinct letter. Some fictitious examples:
* ANIL ⇒ LINA = LINA Is Not ANIL.
* KNIT ⇒ TINK = TINK Is Not KNIT.
Words of the form "?N?" also work if we are happy with a contracted "is" in the acronym. In fact we can get circular recursive acronyms in such cases:
* ANI = ANI's Not INA ⇔ INA = INA's Not ANI.
* ONE = ONE's Not ENO ⇔ ENO = ENO's Not ONE.
Both acronyms in each pair refer to each other thus making them circular while also being the reverse of each other! These could be useful names to express friendly banter between rival projects.
Wow! I was an avid reader of the XKCD comics about 15 years or so ago but I somehow missed this one. For others who are wondering what this is, here's the link to the relevant XKCD comic: https://xkcd.com/917/
What is so clever about this phrase is that it naturally completes to a full sentence that contains itself as an acronym!
I'm So Meta, Even This Acronym IS META!
A wonderful tribute to Hofstader's books that are full of such fascinating self-references.
Ah, good ol'e Dr Comer. Back in school I worked on a project rewriting XINU in Rust. It was quite difficult in the early days of Rust, but it was a fun project to get insight into how XINU worked.
I recently build an AR indoor navigation system for people with cognitive impairments. Is there any way to include an inertial measurement unit (IMU) in this form factor so we can use VIO?
