Laika: a readable Python library for turning raw GNSS data into positions

The gap Laika fills: observables in, distances out

Laika is an open-source GNSS processing library, similar in ambition to RTKlib and GPSTK but written in Python with a strong focus on readability, usability and easy integration with other optimizers.

The scope statement in the readme is precise: Laika can process raw GNSS observations with data gathered online from various analysis groups to produce data ready for position and velocity estimation. It is described as the perfect tool to develop accurate GNSS-only or GNSS-fusion localisation algorithms.

That last phrase is the key to understanding the design. Laika is not a positioning library in the sense of giving you a latitude and longitude. It is the stage before that. The readme spends a paragraph on the GNSS problem to make the point: satellites broadcast signals, the receiver measures distances with an offset caused by the receiver clock error, and because the clock error is unknown the position problem is really four-dimensional trilateration. And that description is over-simplified, because getting accurate distance estimates to satellites, and the satellites' positions from the receiver observations, is not trivial. That procedure is the processing of the GNSS observables, and it is the procedure Laika is designed to make easy.

So the audience is narrow and technical: someone writing the estimator, who needs the boring, error-prone, network-dependent part of GNSS handled for them.

Why a weighted least squares solver is not the answer

Laika ships a basic weighted least squares solver, and the readme is direct about its status: it is provided for experimental purposes, and it is far from optimal due to the dynamic nature of the system, which makes a Bayesian estimator like a Kalman filter the preferred estimator.

That sentence tells you a lot about the project's priorities. A library that only shipped a good estimator would hide the interesting work. Laika instead makes the estimator replaceable. The whole point of producing clean, well-defined distance measurements and satellite positions is that you can feed them into whichever estimator your problem needs, including one that fuses GNSS with inertial or wheel odometry, and that is where a self-driving stack like the one comma.ai builds earns its keep.

The examples directory makes that concrete. There is a notebook on using Laika with a Kalman filter to get more accurate position fixes from a GPS module, a notebook computing the position of a Continuously Operating Reference Station, and a comprehensive walkthrough of the main functions of AstroDog and other useful Laika functions.

The design principles the project states are worth quoting as a design constraint rather than a slogan: Laika should work without configuration or setup, and the default configuration should not compromise accuracy for anything. The second one is the interesting one. It means the defaults are the careful ones, not the fast ones.

AstroDog: the object that fetches and caches everything

Astrodog is the main component of Laika, and the naming joke is explained in the readme: like the Soviet space dogs to which it owes its name, an astrodog will do everything to make the life of its owner easier, which in this case is fetching and processing all the necessary data to transform raw GNSS observables into usable distance measurements and satellite positions ready for position estimation.

It has two named capabilities, and they are the two things that make GNSS processing hard.

get_sat_info provides an accurate position, velocity and clock error for any satellite at any time in history. That is the orbit problem, and it is not something you compute yourself, because you download it.

get_delay provides a pseudorange delay correction for any satellite at any time in history for the requested receiver position, and that correction covers the tropospheric signal delay, the ionospheric signal delay and the differential code biases of the transmitting satellite. This delay can be estimated with mathematical models, or with DGPS station observations, which is more accurate but slower and only supported in the continental United States.

The architecture underneath is what makes repeated use practical. AstroDog downloads files from FTP servers from analysis groups such as NASA's CDDIS when it needs them, and because downloading and parsing all this data can be slow, it caches all downloaded files locally to avoid re-downloading. The parsed objects, DCBs, ionospheric models, satellite orbit polynomials and the rest, are then kept in memory, and each has a valid location area and or a valid time window, within which those objects can provide information relevant to GNSS processing.

Installing it, and the Earthdata account you cannot skip

The install is short, but one of the steps is a real dependency on an external service and is easy to miss.

Laika runs in Python 3.11.4 and has only been tested on Ubuntu 24.04, and running in a virtual environment is recommended. The pyproject is more permissive about the version, requiring Python 3.8 or above, and it is built with hatchling.

The scientific stack comes first, and the readme makes a performance point about it: if you do not yet have numpy and scipy installed, install them with pip, and having accelerated numpy will make Laika much faster.

pip install numpy scipy

Then Laika itself is installed from a checkout:

pip install .

The third step is the one that catches people. It is no longer possible to download GNSS data from NASA servers without an account, so you make an account at the Earthdata site, then create a.netrc file in the Laika folder with the content:

machine urs.earthdata.nasa.gov login your_username password your_password

That file is a plaintext credential sitting in your working directory, which is worth thinking about before you commit it by accident.

The notebook examples need extra pieces. A system package first:

sudo apt-get install libfreetype6-dev

then the Python requirements for the examples:

pip install -r requirements_examples.txt --user

After that you run jupyter notebook and open the.ipynb file you want. The runtime dependencies in the pyproject are modest and specific: numpy, certifi, requests, scipy, pycurl, tqdm, hatanaka, pycapnp for Cap'n Proto serialisation, and atomicwrites.

The accuracy claim, and what it does and does not show

The readme includes a validation section, and it is worth reading carefully because of how it is scoped.

The procedure was to run Laika's processing and a simple Kalman filter, with the procedure described in the examples, on 2000 minutes of driving a regular commute in San Francisco, with data from a u-blox M8 chip. The fixes computed with Laika's processed data were compared to the live navigation fixes given by the u-blox chip, and they were compared by looking at the standard deviation of all measured altitudes within every 5 by 5 square metre in the dataset.

Two things stand out. The first is that the reference is the consumer chip's own output, not a survey-grade ground truth. The readme acknowledges this directly: there is no way to compare horizontal accuracy without ground truth, but there is no reason to believe that vertical and horizontal accuracy are not equally correlated for Laika computed positions and u-blox's live positions. So the comparison is against a baseline that is itself approximate.

The second is that antenna placement is separated. Data with the antenna on the roof and antenna inside the car are compared separately, since the results are significantly different. That is an honest detail rather than a flattering one, because it means the headline improvement depends on where you put the antenna.

For an evaluator, the takeaway is that the library's value is in the processing stage, and that validating it against a real reference requires a real reference. The repository ships a laika_quality_check.html in the examples area and a distplot_laika.png at the top level, so the analysis is reproducible rather than a claim in prose.

Where Laika stops, and what you have to supply yourself

Three boundaries are worth knowing about before you commit to it.

The first is the estimator. Laika gives you a basic weighted least squares solver for experimental purposes and tells you to use a Kalman filter instead. If you want a turnkey position fix, Laika is the wrong library, because the hard part of the problem is the part it hands back to you.

The second is the network and the account. The data comes from FTP servers run by analysis groups such as NASA's CDDIS, and since that data is behind an Earthdata login, the library is not usable offline and not usable without an account. The caching layer means the cost is paid once, but the first run of any computation will download files, and the DGPS correction path, which is the more accurate one, is restricted to the continental United States.

The third is the platform. Laika runs in Python 3.11.4 and has only been tested on Ubuntu 24.04. The pyproject allows Python 3.8 or above and the classifiers say Development Status 4 - Beta, and the version in the pyproject is 0.0.1 with no GitHub releases published. The repository is not archived, and the last push was on 2026-09-25.

The dependency list tells you what kind of project this is. hatanaka, pycapnp, pycurl, certifi for TLS roots, tqdm for download progress and atomicwrites for safe file writes. None of that is exotic, and all of it is the kind of detail that a Python-first GNSS library inherits from the formats it has to read.

Editorial conclusion

Laika fits a developer writing a GNSS-only or sensor-fusion localisation algorithm who needs the raw-observation-to-distance stage done properly and readably, and it does not fit someone who wants a turnkey position solution, since the estimator is left to you. Before building on it, create the NASA Earthdata account and .netrc file the installation instructions require, confirm the Python version you run matches the one the project says it uses, and read the walkthrough notebook to see how much of the pipeline you are expected to own.

Frequently asked questions

Official sources

1. commaai/laika on GitHub
2. Issues
3. License: MIT
4. README