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. |
Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
Quote:
|
Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
Quote:
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. |
Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
Quote:
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. |
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. |
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. |
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?
|
Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
Quote:
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. |
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.
|
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. |
Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
Quote:
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. |
Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
Thanks Dockhead. That's very useful.
|
Re: Collision Avoidance, Cones of Uncertainty, and Appropriate CPA
Quote:
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.