Cruisers & Sailing Forums (https://www.cruisersforum.com/forums/)
-   Seamanship & Boat Handling (https://www.cruisersforum.com/forums/f90/)
-   -   Collision Avoidance, Cones of Uncertainty, and Appropriate CPA (https://www.cruisersforum.com/forums/f90/collision-avoidance-cones-of-uncertainty-and-appropriate-cpa-189919.html)

transmitterdan 20-12-2017 05:51

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
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 20-12-2017 05:56

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
Quote:

Originally Posted by Uricanejack (Post 2539691)
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 20-12-2017 06:11

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
Quote:

Originally Posted by Uricanejack (Post 2539691)
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 20-12-2017 06:22

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
Quote:

Originally Posted by El Pinguino (Post 2539697)
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 20-12-2017 06:24

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
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 20-12-2017 07:03

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
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 05-01-2018 08:58

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
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 05-01-2018 09:28

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
Quote:

Originally Posted by rgleason (Post 2549106)
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 05-01-2018 09:50

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
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 05-01-2018 11:12

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
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.

Dockhead 05-01-2018 12:04

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
Quote:

Originally Posted by rgleason (Post 2549212)
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.

Let's consider separately the case of alarms, versus the case of "attenuation", bolding, coloring, etc.

Alarms are simply not useful in cases where you are in crowded pilotage waters with vessels following channels and fairways and often coming on to momentary collision courses. Alarms are just meaningless in such situations, so just turn them off. The purpose in my opinion of a collision avoidance alarm is to call your attention to the screen when you are in more open water and not watching the traffic constantly. In crowded pilotage waters you simply don't need it -- your eyes are on the screen anyway.

Highlighting targets in some way -- even if it's a momentary situation which triggers it -- is no problem in my opinion. Let the flash red as they turn across your path -- I'd like to know about that actually. And go black again as they continue turning. Also attenuating them -- let them be un-attenuated if they turn in a way which causes a momentary conflict. What problem is that? I think it's actually good to see them.

It would be useful to be able to set the criteria for alarms separately from the criteria for visual indicators.


It might be nice to have some kind of super-highlighting for a target which seems especially dangerous -- CPA/TCPA criteria PLUS maybe fulfilling those criteria for a longer period of time, and/or stricter criteria like 10 minutes and 0.5 miles (for example) instead of 30 minutes and 1 mile (for example. Red flashing icon and/or a separate audio alarm. That would be great. That is the only feature I don't already have and would like to have.

rgleason 05-01-2018 14:53

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
Thanks Dockhead. That's very useful.

Juho 08-01-2018 17:01

Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
 
Quote:

Originally Posted by Dockhead (Post 2549241)
Let's consider separately the case of alarms, versus the case of "attenuation", bolding, coloring, etc.

I think one could develop an alarm system that could be useful also in crowded environments. I don't have much experience on what would be practical since I don't have AIS, but in theory this could work. :smile:

The basic idea is that there could be alarms e.g. when some new vessel seems to be more dangerous or about equally dangerous as the current most dangerous vessel is. This would be combined with bolding and colouring. I might tune the system so that after the first alarm (based on CPA and TCPA) the system would focus on the (max) three most dangerous vessels (that meet the original CPA and TCPS criteria), display them accordingly (highlighted), and give alarms (maybe not so loud) when there is something new to be noted. These new things to be noted could be e.g. "the most dangerous vessel has changed" and "new vessel in the top three". There would be some hysteresis in the system, and memory of the past given alerts and their timing, to avoid unnecessary alerts due to variation in the measurements and other minor changes in the environment.


All times are GMT -7. The time now is 05:25.

Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2021, vBulletin Solutions, Inc.


ShowCase vBulletin Plugins by Drive Thru Online, Inc.