View Full Version : Compound Collision Course Method
Well it seems that autumn came early this year and it's raining "methods"
Here is another one!
Based on the "compound" collision course concept already mentioned here (http://www.subsim.com/radioroom/showpost.php?p=1472764&postcount=48) but extended so as to be easily implemented (graphically) in SH4.
The text describing the method is here (https://docs.google.com/fileview?id=0B02tqepvya5KYjk0ZmQyY2YtYThjMy00N2Q3L Tk3OTQtMjE2NGEzM2RhZTIw&hl=en&authkey=CICFqOoM).
Have a look at it and post a comment.
Considered W.I.P.
And BTW I don't claim that the method is original or novel in any way (I would REALLY be suprised if it was).
.
This method certainly must work, in theory anyway. You have two situations (equations), with 2 unknowns in common. The more I look at diagram 3, the more I am reminded about the formula derivation of the 3-bearing method. It looks very similar, though is from a completely different setup. (see my 1st message in Nisgeis equal-bearing interval thread) Maybe the style of that derivation can help further with yours.
Whether you have enough time to establish 2 collision courses before the actual merge in praxis is something I am not sure of. Also, if you lag too much behind for stage 2, then your topspeed may not be adequate enough to keep up with the constant bearing required speed.
Damn, too many methods, not enough braincells that are fit to divide them over.
...
Whether you have enough time to establish 2 collision courses before the actual merge in praxis is something I am not sure of. Also, if you lag too much behind for stage 2, then your topspeed may not be adequate enough to keep up with the constant bearing required speed.
....
Well, the in-game use remains to be seen. Since we are "blessed" with full sonar on the surface, you can contemplate using it even in "over the horizon situations" as part of your "shadowing" process. Another probable use is verifying the course and speed you have already estimated without the need to pop up the scope a mile from the flanking escort.
Handling the "lag phase" may well turn out to be the "make it or break it" part of the procedure... :hmmm:
...
Damn, too many methods, not enough braincells that are fit to divide them over.
Bahhh, you only need one! But a real fast one!! :D
.
Bahhh, you only need one! But a real fast one!! :D
It's the Navy, after that last liberty, it's TWO brain cells—but they're held together by a spirochete. :)
JoeCorrado
08-27-10, 12:05 AM
Doesn't it take FOUR brain cells to perform any type of trig function?
Is it cheating to use a 21st century calculator to do the math and just pretend like you have a math wiz doing the calculations for you, or is long hand absolutely required for the sake of realism? :hmmm:
K.I.S.S.
Is it cheating to use a 21st century calculator to do the math and just pretend like you have a math wiz doing the calculations for you, or is long hand absolutely required for the sake of realism?
There's always an option between 21st century calculator and long hand. It's even an authentic method.
http://www.antiquark.com/sliderule/sim/virtual-slide-rule.html
Armistead
08-27-10, 12:36 AM
I'll stick with OKane, Vector or EZplot and my version of quick guesswork sonar shooting in a storm.
I do enough math homework with my son.
JoeCorrado
08-27-10, 12:58 AM
I'll stick with OKane, Vector or EZplot and my version of quick guesswork sonar shooting in a storm.
I do enough math homework with my son.
Amen brother! :yeah:
if you know target's speed and course you can do whatever you please.
The Compound Collision Course Method (CCCM) is about getting/verifying/fine-tuning that kind of data.
It is not a firing method per se.
.
Doesn't it take FOUR brain cells to perform any type of trig function?
Is it cheating to use a 21st century calculator to do the math and just pretend like you have a math wiz doing the calculations for you, or is long hand absolutely required for the sake of realism? :hmmm:
K.I.S.S.It's a personal choice. But since it is usually much easier to just spin a wheel making numbers align, than it is to punching numbers (and risk starting over if you punch in the wrong one) on a calculator, I try to find a more authentic way. But yeah, when testing methods out I too use a calculator to make sure the intermediate steps are dead-accurate.
Solving something graphically is perfectly acceptable. But the drawing tools can induce major inaccuracy in certain situations. Like in this case, two relative bearings that are close together. The point where they cross could be a very slender 'X'. This would lead to a wildly changing intercept angle (W).
...
Solving something graphically is perfectly acceptable. But the drawing tools can induce major inaccuracy in certain situations. Like in this case, two relative bearings that are close together. The point where they cross could be a very slender 'X'. This would lead to a wildly changing intercept angle (W).
Yeap, that is a limitation of many graphical methods, more so with SH4's nav tools. The only way to eliminate the effect is to allow the data points to "spread out" a bit (more points and/or larger "sampling" intervals). I'm certain that this would be a problem in RL nav plotting work, too. :yep:
.
I'll stick with OKane, Vector or EZplot and my version of quick guesswork sonar shooting in a storm.
I do enough math homework with my son.
No math involved in this method.
.
Rockin Robbins
08-27-10, 09:44 AM
In general, graphical solutions expose defects in the numbers too! In this condition, with a long narrow triangle, it is child's play to see in the graph how even a tiny difference in one parameter can result in a huge difference in another. That shows a method VERY intolerant of error.
Let's take the triangle where you have a target at an AoB of 10º. There's your long narrow triangle, with you crawling at a knot or so to track the collision course of your normal speed target. Here's where the narrow triangle bites! A lousy quarter knot difference in your speed would change your target speed result by 1.44 knots! In other words, using the collision course method on an 80º AoB target to derive target speed multiplies any error in your speed by almost six times in the resulting target speed! That is terrible precision.
Since we can only be accurate to about a half knot, that means that we can only measure the target speed to an accuracy of +-2.88 knots. That's not acceptable. Long narrow triangles mean either great precision or lousy precision, depending on which leg of the triangle you are. If you're the short leg, as in the slow speed of the sub compared to the high speed of the target, you can toss that method out the window for now and use something else until your leverage is much better.
Using just the numbers gives you no obvious clue when your method is full of holes or when you've made a critical error that results in a miss. Graphical methods are self-validating. If it's tough to accurately draw that long narrow triangle, that MEANS SOMETHING. Pay attention!
On the other hand, if the angles are larger, the figure is much easier to draw and slight errors don't make much difference in the graphical result, that means that your solution is very error tolerant and you can proceed with confidence. So Diopos is exactly right: spread those data points out. Widen those triangles!
So rather than numbers being superior, there is more information in a graphical solution which can markedly improve your success rate if you understand what you are looking at. It is the numbers which deceive, by looking precise when they are not.
Insert discussion of the concept of significant figures here. 5<>5.0.
Doesn't it take FOUR brain cells to perform any type of trig function?
Is it cheating to use a 21st century calculator to do the math and just pretend like you have a math wiz doing the calculations for you, or is long hand absolutely required for the sake of realism? :hmmm:
K.I.S.S.
I would really like to hear how you'd solve the "problem" as stated and solved in CCCM with a 21st century calculator. No irony intended, I am really interested. :yep:
.
...
So rather than numbers being superior, there is more information in a graphical solution which can markedly improve your success rate if you understand what you are looking at. It is the numbers which deceive, by looking precise when they are not....I didn't mean to imply that numbers are superior. I completely agree that a graphical representation would immediately show the defects of a situation intolerant of errors. Which is less apparent if you use just numbers. Drawing with the map tools would enhance error simply by errors in placement and orientation of lines and angles. And that is something I would like to avoid if I'm trying to understand how it works exactly
Rockin Robbins
08-27-10, 10:18 AM
No doubt understanding the problem both from a graphical and mathematical basis helps with understanding the situation. Many times I'll take a graphical situation and then mathematically calculate my error tolerance to see if it's worthwhile to shoot. I did that with the Mark 1 version of the fictitious course brainstorm, finding that the method sucked but if I could reduce to a range of 500 yards I would hear booms. Of course so would a blind chimpanzee, but you gotta salvage what dignity you can!:har:
Still brainstorming on CCCM: Link (https://docs.google.com/fileview?id=0B02tqepvya5KZDE2MzljMzQtMjk3Zi00ZWNiL TlkMjQtNmRmYzczMDk2ZDk5&hl=en&authkey=CJOl1JYI)
Geometrical solutions expanded to include:
change in sub's direction,
non "sequential" collision runs
multiple collision runs
"diverging" target situations
Still not formulated as an """official""" method, but you can experiment with it.
It is a long read, but give it a try anyway!
.
I'll stick with OKane, Vector or EZplot and my version of quick guesswork sonar shooting in a storm.
I do enough math homework with my son.
lol
commandosolo2009
06-10-11, 06:46 PM
hmmm..... I'll take it. I'll read it, implement it, and give you feedback. In the meantime, try overcharging your cranium to more solutions. We could use a twist anytime. :03::rock::salute:
I continue work on the subject and have formulated a more easy method to implement in situations where the sub can move faster than the target. Please read through the material and comment if you have time to spare.
.
I took a look at your method. Nice work. :)
My only reservation is it seems like it might take too long to obtain the data in many situations. But I would like to try it sometime when circumstances permit. How much have you used it in your game?
I took a look at your method. Nice work. :)
My only reservation is it seems like it might take too long to obtain the data in many situations. But I would like to try it sometime when circumstances permit. How much have you used it in your game?
The basic problem is "establishing" a collision course, in particular if the target is distant. For example the bearing to the target can remain unchanged, for a specific QwnShip speed but for a "span" of courses. As the target approaches this tends to become less of a problem. But of course as it approaches your ability to remain on the surface becomes ... uhmmm ...."tactically challenging" :D. Now after you submerge your speed limit becomes lower and if you have DDs close enough even more so. Another drawback is that sometimes you need a "fine tunning" of your speed which I can achieve within the game (alrhough Ithink there is a mod that allows you to control speed to 1/10 of a knot).
At the moment I'm trying to combine a collision course+bearings only simple target motion analysis method. Looks promising ... but this time I'll do all the testing before posting! :yep:
.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.