Trajectory Solver Failures - markmac99/ukmon-pitools GitHub Wiki
Full details of how the solver works are beyond the scope of a wiki, but it can be summarised as follows:
- detections are grouped into potential matches based on time and field of view of cameras.
- The intersecting-planes and line-of-sight methods are used to determine the feasibility of a solution.
- The data are then fed into a monte-carlo simulation which adds gaussian noise to each point, to determine a set trajectories that can be fit to the data within reasonable tolerances.
- These trajectories are then mapped back onto the line-of-sight data to determine the most probable path and velocity of the meteoroid.
While two detections might be within a couple of seconds of each other and in overlapping fields of view, they could actually be different meteors. During showers its common to get two or three meteors in a ten second window. When different events are matched by mistake, the result is usually physically unrealistic: the meteor starts or ends underground, or travels upwards, or its initial altitude or velocity is much too high or too low. Meteors are normally detected between 120 and 80km altitude and travel at between 15 and 80 km/s, so anything outside that range is not likely to be a meteor.
Each camera has a different view and will pick up the meteor at a different time depending on distance, atmospheric conditions and camera. The solver attempts to compensate for this by allowing up to five seconds difference in start time of the event as seen from different cameras. However, if the detections still can't be matched even after allowing for timing discrepancies, either they're different meteors, or the data are in some way too inaccurate. Perhaps one detection was through cloud, or near the horizon, or right on the edge of the field of view.
If the meteor is a long way off, or the cameras are relatively close together as seen from the meteor, then the convergence angle may be too small for accurate calculations. Imagine drawing a triangle with the cameras at two corners and the meteor at the third. If the triangle has a wide base and sides around the same length, then we can measure the meteor's position very accurately. However, if the base is narrow and the triangle is tall and thin, then the measurement is much less accurate.
Its important to remember that the data reported by the camera are the result of experiment and contains both systematic errors and random noise. For example, the camera sensor has a finite pixel size and we can only measure position to the nearest pixel. Thus sometimes, including a point causes the errors in the fit to stray outside the acceptable range and the point must be excluded. Sometimes an entire camera gets excluded - usually this happens because it had a bad angle on the detection, or only caught part of the event.
If too many data points are excluded, or no fit can be found that's within tolerances, then the solution will fail.