Why does the Orbit Solver sometimes fail - markmac99/ukmon-pitools GitHub Wiki

The trajectory solver we're using is pretty complex but for simplicity it can be broken into two parts.

The Intersecting Planes Stage

The first part is an "intersecting planes" solution.

How does this work? Well, imagine you used your arm to trace the path of the meteor as seen from your location. Your arm sweeps across the surface of an imaginary plane that runs through the meteor's track and your shoulder. The software does the same from the viewpoint of each camera though because meteors decelerate once they hit the atmosphere, and therefore their path curves, the software only uses the first few points of each detection.

Then the software tests if the planes intersect along a straight line. Of course, they won't intersect perfectly for all sorts of reasons, so to validate the answer, the software checks a couple of things. Firstly, are the start and end heights reasonable - above ground level, not travelling upwards, not starting beyond the orbit of the Moon, that sort of thing. Secondly, is the implied velocity sensible - meteors are moving between 10 and 80 km/s. This helps exclude aircraft, satellites etc as well as impossibly fast objects like the USS Enterpise or the Rocinante.

If the planes intersect, and the solution seems reasonable, then the detections are considered a candidate match.

Now comes the second part

The Monte Carlo solution.

Many meteor trajectory solvers use a theoretical model of meteor behaviour and try to fit the data to this. Unfortunately, meteor behaviour is influenced by many factors for which we don't have data - for example, high altitude wind and changes in atmospheric density can influence meteors and we generally don't have any realtime data on that. So theoretical models are often extremely complex or indeed indeterminate. Additionally, each measurement has some innate uncertainty for example because the minimum spatial resolution is one pixel and minimum time resolution is 1/18000 of a second, during which a meteor may have moved several metres, or be a few arcseconds away from where we thought it was.

Our solver takes a different approach that avoids these problems. It plots all the points that it has, adds some random noise to every point to represent the uncertainties, and fits a smooth curve to the data using a Monte Carlo approach. For every point it calculates the difference between the fitted curve and the actual data to get a total error.

It then repeats this process over and over, adding different random noise each time, until it has at least twenty different solutions. The solution with the smallest total error is then chosen as the answer.

However, as it evaluates each solution, it examines the errors on each individual point. If the errors are too large then the point is "ejected" ie not used in the solution. The solution is then recalculated without the point. This may result in another point being ejected, and another, and eventually there may be too few points left for a sensible solution. If this happens for every attempted solution, then the whole solution fails.

And so, we have reached "Too many Observations Ejected"....

Why Bad Data Though?

You're probably asking why might a point have such a large error? Consider what a measurement is; its an estimate of the centre of the meteor in each frame (the centroid). The software tries to find this by measuring where the meteor is brightest along the estimated track. But, meteors don't burn up evenly, so the brightest part might not be the centre. Also, if the meteoroid fragments, the parts might have different brightnesses. Or the meteor might pass so close to a star that the star's light overlaps the meteors. Or, thin cloud might diffuse the light in one direction but not another. Or, the event might be low down and far away, so that one pixel error was a big deal. Or so near that the sensor was overloaded and the centre could be anywhere. And so on. All these factors can cause individual points to be away from the true centroid.

So, if you see "too many observations ejected", it probably means that the event was viewed under poor conditions of one sort or another.

Can it be Fixed?

In general, a human being will be able to guess the centroid better than any software. So its often the case that manual review of the data will find a solution. This is however time consuming and boring, and so i generally only do it for really interesting events !!