Collision Avoidance, Cones of Uncertainty, and Appropriate CPA

[Dockhead]

Originally Posted by transmitterdan

Regarding AIS questions:

Ship position, COG and SOG come from GPS. Speed is always SOG, AIS does not care about speed through water. At least in the US, for class B the GPS must be integrated with the transponder. For class A the GPS can be external or internal, the turn rate and heading typically come from on board instruments (rate gyro, etc).

There are unapproved AIS class B units listed for sale on the Internet.

Yes. Speed and course are always ground referenced, as are CPA and TCPA derived from them. It's too hard to measure speed through the water accurately, and we don't actually have any realistic means of knowing CTW, which is not the same as Heading. I am not aware of any instrument system which even tries to calculate CTW.

On ships, there is a choice of using STW or SOG in the radar. You are supposed to use STW -- as far as I understand, so that the geometry of the crossing will be correctly presented so that you understand which Rule applies to the crossing. This is not an issue for us as we don't use radar this way.

[DotDun]

Originally Posted by Paul Elliott

The relevant AIS Class-A dynamic data is:
Navigational Status (entered by a human)
Rate of Turn
Speed Over Ground
Position Accuracy (indicates a high-accuracy or low-accuracy GPS fix)
Longitude
Latitude
Course over Ground
True Heading

There is other data, but none germane to collision avoidance. The only human-entered data is NavStat, and we already know to take that with a huge grain of salt. Heading and ROT are not always provided, and there are specific values that indicate "not available" (All data has the "not available" option) (*)

The Class-B dynamic data contains all of these except NavStat and ROT. I seldom see HDG transmitted by a Class-B transponder.

(*) I've only seen the Not Available flag on data other than HDG or ROT one time: On a USCG boat used for interdiction, where they only broadcast their lat/lon. SOG, COG, HDG, and ROT were all "unavailable". This was with a Class-A transponder. Usually Navy ships will not broadcast AIS of any sort (but sometimes they do). USCG ships will transmit AIS in my experience. I don't see any stealth advantage to what that USCG boat was doing, but I doubt it was an equipment failure.

I’ve never seen heading in AIS, hence I assumed it wasn’t there. Although I have seen ROT, which makes sense that heading can be there also.

[transmitterdan]

Heading is not too useful for AIS in my opinion. Course over ground is what drives the relative motion equations for CPA calculations. So I guess some AIS display software ignores heading. OpenCPN uses heading, if available, to draw the ship symbol and it uses COG and SOG to show the projected line of advance.

ROT is useful for obvious reasons. It gives advance information about a pending course change. OpenCPN does not bend the line of advance based on ROT but it may be possible to compute the arc.

[Uricanejack]

I think you have a fundamental misunderstanding there.

Relative motion is based on only one simple principle.
The position the observation is taken from remains constant.
The relative motion of the other object is taken from bearing and distance from the observers apparently constant position.

To display relative motion the instrument. must measure or calculate the distance and bearing from the observed location and display the result.

The relative motion would be the distance and angle between those positions.

An ARPA or MARPA will measure the distance a bearing from the apparent fixed origin at the center of the screen. giving an accurate relative motion. or a least as accurate as the accuracy of the instrument.

The ture motion calculated by the ARPA or MARPA may be incorrect due to the course and speed used to calculate the true motion being over the ground rather than through the water.


So now I am wondering how the various plotters calculate the relative motion.

If the AIS information is used to compare true ground positions to calculate the relative motion back wards from the true motion.

It will not be the correct relative motion.

[El Pinguino]

Originally Posted by transmitterdan

Heading is not too useful for AIS in my opinion. Course over ground is what drives the relative motion equations for CPA calculations. So I guess some AIS display software ignores heading. OpenCPN uses heading, if available, to draw the ship symbol and it uses COG and SOG to show the projected line of advance.

ROT is useful for obvious reasons. It gives advance information about a pending course change. OpenCPN does not bend the line of advance based on ROT but it may be possible to compute the arc.

Heading is everything.... that is what gives you the aspect of the other ship in relation to your ship's head and that is why IMO say that course and speed through the water should be used rather than SOG and COG....

I really truly can't be bothered explaining all this again but if you don't understand why then one day this lack of understanding may jump up and kill you..... but that is not my problem....

[transmitterdan]

No it isn't your problem. But for computing CPA the AIS calculations don't use speed through water or heading. They use COG and SOG for both vessels. I can't see how that will produce a wrong answer. So it would help me if you could show an example of that.

Knowing the aspect of the ship is helpful to the operator. And OpenCPN at least shows it on the display if the data is available. But it does not help a lot in computing the CPA or time of when that will happen. It is a second order effect that comes into play when the vessel proportions and antenna location are known.

In the extreme if one vessel is adrift and has AIS how would it help to know its STW and heading? Whether or not there will be a collision is dependent on its true speed and course relative to my own vessel over a fixed reference (ground). I guess if one assumes that current speed and direction are the same for two vessels in sight of one another the through water calculations would produce the same resultant CPA. But very few pleasure vessels have accurate STW and heading sensors.

[transmitterdan]

Originally Posted by Uricanejack

I think you have a fundamental misunderstanding there.

Relative motion is based on only one simple principle.
The position the observation is taken from remains constant.

AIS uses GPS position and speed which is computed relative to a fixed point on the earth (the WGS84 datum). So long as all data used to compute relative motion is based on that same datum I cannot see how the CPA calculation can be "wrong". So if you can give an example it would be helpful for non-professional boaters like me.

[Dockhead]

Originally Posted by Uricanejack

I think you have a fundamental misunderstanding there.

Relative motion is based on only one simple principle.
The position the observation is taken from remains constant.
The relative motion of the other object is taken from bearing and distance from the observers apparently constant position.

To display relative motion the instrument. must measure or calculate the distance and bearing from the observed location and display the result.

The relative motion would be the distance and angle between those positions.

An ARPA or MARPA will measure the distance a bearing from the apparent fixed origin at the center of the screen. giving an accurate relative motion. or a least as accurate as the accuracy of the instrument.

The ture motion calculated by the ARPA or MARPA may be incorrect due to the course and speed used to calculate the true motion being over the ground rather than through the water.


So now I am wondering how the various plotters calculate the relative motion.

If the AIS information is used to compare true ground positions to calculate the relative motion back wards from the true motion.

It will not be the correct relative motion.

Yes, AIS does exactly that -- it takes accurate GPS positions, COG and SOG of both vessels to project the courses of both vessels to their closest point of approach. It's all ground referenced and doesn't care about what the water is doing. As long as the references are the same (either ground, or water), then the relative motion will be correctly described -- there is only one relative motion! What is not described by this method is what either vessel is doing in relation to the water.

Radar sees relative motion directly -- why you can use the EBL for collision avoidance. But ARPA, just like AIS, gets CPA and TCPA after working through two levels of abstraction, just slightly different ones -- calculating range (not position), relative course, and relative speed, then projecting the relative motion of the two vessels to their closest point of approach, like we do a hand radar plot. Here the AIS method is better because it does not need to CALCULATE data about the other vessel -- it receives position, course and speed of the other vessel via the other vessel's position report.

In neither case is there any risk of using conflicting references, and there is only ONE kind of relative motion.

[Dockhead]

Originally Posted by El Pinguino

Heading is everything.... that is what gives you the aspect of the other ship in relation to your ship's head and that is why IMO say that course and speed through the water should be used rather than SOG and COG....

I really truly can't be bothered explaining all this again but if you don't understand why then one day this lack of understanding may jump up and kill you..... but that is not my problem....

Peace, my brothers.

The explanation for this is very simple --

Different Rules apply depending on how the vessels are meeting. You must know the aspect of the other vessel to know this. That is the ONLY reason why you are supposed to input STW into your radar on a ship.

I read a good article on this some time ago in the Journal of Navigation. I'll try to dig it up and scan it.

Ping is right -- it can kill you if you make wrong assumptions about how you're crossing, and apply the wrong Rule.

Of course you should anyway be checking your visualization of aspect of the target with your eyeballs, in any case.

But Transmitter Dan is also right -- none of this has anything to do with the calculations of CPA and TCPA, which are not subject to miscalculation due to water or ground references in either ARPA or AIS.

[Dockhead]

Here we go:

https://www.myseatime.com/blog/detai...ich-one-to-use

Same article, but online. This should sort out any differences between Ping and Transmitter Dan, who are both right. Classical case of two wise men grabbing different parts of the elephant.

[transmitterdan]

Ah, I see Ping's point. Knowing the relative orientation of the vessels determines the proper role for each when it is determined a risk of collision exists. Obviously I was not talking about that, rather about calculations of CPA and time thereof. Sorry for being too focused on one subject.

MARPA makes its calculations based on the radar observation which is on the observing (and possibly moving) boat. So it can determine relative motion without aid of GPS or knowing STW. Some rec radars give the target vessel course and speed and for that it needs the radar's course and speed as well. Most MARPA units have this data available.

[rgleason]

In OpenCPN, using Dirk's algorithm (with some adjustments perhaps) for "Attenuate less important targets", would there be an advantage/improvement to cognition to have a setting which circles "More important targets"? Particularly in the Solent and other high density areas?

[Dockhead]

Originally Posted by rgleason

In OpenCPN, using Dirk's algorithm (with some adjustments perhaps) for "Attenuate less important targets", would there be an advantage/improvement to cognition to have a setting which circles "More important targets"? Particularly in the Solent and other high density areas?

My Zeus plotters show the target carats in BOLD for targets which meet the set criteria (usually <30 min TCPA and <1 mile CPA).

OpenCPN works the same way, and I think will even show a different color if you set it up that way.

It's really useful, I would say essential function.

[Paul Elliott]

NavMonPc uses color (yellow and red target color) to indicate targets that meet the range / CPA / TCPA criteria. Yellow, as soon as the criteria are met, and red if the match is persistent. The audible alarm (if enabled) sounds when the target "goes red". This works well for me.

[rgleason]

Yes, Dirk's algorithm is not (T)CPA but is a blended and prioritized filter which "Attenuates less important targets" (makes them smaller) to help declutter the screen.
I was thinking of a similar, but additive indicator of the most critical targets, using a similar process.

I think you are both suggesting that (T)CPA settings are what should be used, however we have many users that are complaining that those alerts go off all the time in very crowded situations, basically because small boats bounce around and don't have as stable instruments, so I was trying to find a good way to provide better information to those user by using Dirk's algorithm.

We have some nmea recordings of these AIS situations (start of a race) which are a good example of what happens in these situations.