Welcome to the NavList Message Boards.

NavList:

A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Compose Your Message

Message:αβγ
Message:abc
Add Images & Files
    Name or NavList Code:
    Email:
       
    Reply
    Running fix Monte Carlo analysis
    From: Paul Hirose
    Date: 2013 Oct 06, 23:52 -0700

    To combine two LOPs (lines of position) obtained at different times, a
    traditional method is the "running fix," in which the previous LOP is
    advanced to the time of the most recent LOP, just as one would advance
    the vessel's position to a future time. The intersection of the old and
    new LOP is the fix.
    
    Another way to use a single LOP is to correct the navigator's EP
    (estimated position) to the nearest point on the most recent LOP, as
    soon as the LOP is obtained. That is, a perpendicular to the LOP is
    drawn through the old EP. The vertex of the right angle is the new EP.
    Although not a fix in the usual sense, I call this a "walking fix" for
    lack of a better name. (Is there a generally accepted name?)
    
    The walking fix is superior as regards clutter on the chart and labor,
    since each LOP is plotted only once. Additionally, the navigation
    solution is improved immediately. There is no need to wait perhaps hours
    for another LOP. But what about accuracy? Unable to answer the question
    on a theoretical basis, I decided to program a Monte Carlo simulation.
    That is, the reckoning and plotting is simulated numerically for a great
    number of trials, with random numbers controlling the orientation of the
    LOPs and the injection of errors.
    
    In the simulation I make some simplifying assumptions:
    
    1. The vessel moves on a flat surface at constant speed and direction.
    
    2. The LOPs are straight lines, have no error, and are obtained at equal
    intervals of time.
    
    3. The orientation of each LOP is random but at least 30° from the
    previous LOP.
    
    With these assumptions, the analysis is performed on a rectangular
    coordinate system in which the origin always represents the true
    position of the vessel.
    
    To simulate a running fix:
    
    1. Displace the previous LOP (the "old LOP") a random distance and
    direction from the origin to simulate the error of advancing it.
    
    2. Generate a new LOP. Since LOPs are assumed to be without error at the
    time of observation, the new LOP passes through the coordinate origin.
    Its orientation is random but at least 30° different from the old LOP.
    
    3. Determine the intersection of the old and new LOPs. This is the
    running fix. Due to the error introduced in step 1, the fix is not at
    the coordinate origin. The distance from the origin is the fix error,
    which is recorded.
    
    4. Return to step 1. Continue for the selected number of iterations.
    
    
    To simulate a walking fix:
    
    1. Apply a random displacement to the EP (estimated position) to
    simulate the accumulated errors since the last position update. (Before
    this step the EP already has some error from the last iteration.)
    
    2. Generate a new LOP through the origin.
    
    3. Find the point on the LOP closest to the EP. This is the walking fix.
    Its distance from the origin is the error of the fix, which is recorded.
    
    4. Return to step 1. Continue for the selected number of iterations.
    
    
    The running fix and walking fix algorithms have much in common. In
    my program the errors induced in step 1 and the LOPs generated in step 2
    are shared. That is, I simulate two separate navigators who have
    identical errors in their estimated reckoning and use identical LOPs.
    Note that the random error applied in step 1 does not have the 30°
    restriction. It can be any direction.
    
    The magnitudes of the errors inserted in step 1 have a normal
    distribution (Gaussian). Also, the program allows a systematic error
    (always the same value) to be added to the random error to simulate the
    effect of a compass error, undetected currect, etc.
    
    
    According to my simulation, either the "walking fix" or traditional
    running fix can be more accurate, depending on the relative proportion
    of random and systematic error. In the table below, the random error
    (first column) is the CEP (circular error probable): a radius within
    which 50% of the errors fall. The systematic error (second column) is
    the magnitude of the fixed error. Both columns are inputs from the user
    to set the parameters of the simulation run.
    
    The third and fourth columns are the results: the root mean square
    accuracy for 10000 iterations of the running fix and walking fix. The
    unit of measure for all columns is the distance the vessel moves between
    LOPs. Remember, the vessel's actual velocity is constant and LOPs are
    obtained at equal time intervals. Thus the distance unit can be the true
    distance traveled from LOP to LOP. This is simpler and just as effective
    as specifying speed in knots and time between LOPs in hours.
    
        error     accuracy
    ---------  -----------
      ran  sys   run   walk
    .000 .050  0.046 0.057
    .025 .050  0.053 0.062
    .050 .050  0.071 0.076
    .050 .025  0.060 0.058
    .050 .000  0.054 0.050
    
    The table shows the traditional running fix to be generally more
    accurate if the error is purely systematic, as in the top row. In that
    extreme case, the running fix has 80% of the walking fix error. The
    running fix continues to be more accurate until the random error
    increases to twice the systematic error. At this point both methods are
    equal. With an even larger proportion of random error, the walking fix
    is more accurate.
    
    An error of .05 - the maximum I used - corresponds to about 3° (= arc
    tangent .05), or an equivalent distance error. If error is reduced to,
    say, half of the table values, then the results are twice as accurate
    but the relative performance of the fix methods is the same.
    
    If the number of trials per run is reduced from 10000 to say 10, it
    becomes obvious that the "winner" is highly dependent on the luck of the
    fix geometries. For example, the middle row of the table shows a slight
    advantage for the running fix if the random error CEP is identical to
    the systematic error. However, this is impossible to see if you view the
    statistics for only 10 iterations at a time. The statistical noise from
    run to run is far greater than the difference in the table. I have not
    been able to isolate the conditions that favor one fix method over the
    other.
    
    I recommend these results be viewed with a skeptical eye unless
    confirmed by someone else.
    
    --
    
    
    

       
    Reply
    Browse Files

    Drop Files

    NavList

    What is NavList?

    Get a NavList ID Code

    Name:
    (please, no nicknames or handles)
    Email:
    Do you want to receive all group messages by email?
    Yes No

    A NavList ID Code guarantees your identity in NavList posts and allows faster posting of messages.

    Retrieve a NavList ID Code

    Enter the email address associated with your NavList messages. Your NavList code will be emailed to you immediately.
    Email:

    Email Settings

    NavList ID Code:

    Custom Index

    Subject:
    Author:
    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site