Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
https://steamcommunity.com/sharedfiles/filedetails/?id=2262182547
So triangulation inside the same vehicle isn't feasible. You would have to drop a buoy with a locator, gps, and a radio system.
Probably the best system is simply a distance reading, and another controller that compares your horizontal speed to the delta on the distance reading, and shows you if you are closing in on the signal at the optimum heading. That won't show you what direction to correct in, but should be faster.
The basic method is to just use a distance reading, then head off in each of the cardinal directions for a km or so and see what the distance does. This can show you which quarter of the compass the target is in. It is just a bit slower, because you have to tack back and forth as you go.
I would assume any triangulation calculation would involve two readings and maybe an input or two at your nav station.
You would have to drop a buoy that is fitted with beeps to distance logic, gps, and a radio. This would transmit distance and location to your vessel.
The other half would be on your boat/heli, with gps and distance reading.
The rest is all trigonometry. Find the distance or the angle between the two gps readings using atan2 maybe, then simply solve the triangle.
Its something I've been meaning to get round to.
No, you wouldn't.
I described how a two reading triangulation calculation works in description of my MC above. Submarines use passive sonar with only direction as an indication... and can triangulate on a target. It's called Target Motion Analysis (TMA). Although we could use that approach to triangulate on the target with readings at various points along a course, we don't need to because our target is stationary in this game.
So the calculation is fairly simple.
All we need are two distances, taken at two different x,y coordinates and we can triangulate. Keep in mind, our target in this game isn't moving... so all we need are two observations.
But yes, close enough to static. It would need a big gap between taking samples, and with +/- 100m accuracy, its going to be pretty inaccurate, especially when you are headed straight for the target.
I think an effective system is going to need to to recalculate on every beep, reliative to every previous beep, and find the trend, with suitable weighting for each result.
I think when you are roughly in the right direction, comparing rate of change of the distance to your speed would be far more accurate.
I doubt that a heading readout is ever going to be accurate, or apropriate. I was thinking of ways to display the data, and it is going to have to show a probability curve of some sort.
I did want to build the buoy system so that I could cover the whole ocean with them, and get instant results.
Ultimately I got bored with vanilla rescue missions about the same time I built my own simple beeps to distance controller, so never got round to it.
A ship adrift is not going to be an issue... you'll get to the spot and easily be within a km.
I use the MC in a submarine and typically surface underneath the craft without a triangulation. As I mention in the MC, once you have a decent read on the distance, you don't really even need to do a formal triangulation. There just comes a point where you need to make a guess at a left or right turn and see if you get closer. So I haven't really even bothered with anything complex.
Accounting for drift would just be a function of wind speed and direction. ...but if you know the general direction of wind/drift, you also know which way to turn to most likely account for it.
It only gets more complex if you have a target moving at 8-20 knots on the surface. TMA would provide target location, and a speed-heading vector. ...but if all you're accounting for is a bit of wind drift, you can treat the target as stationary and you'll find it just fine.
If you were actually going to create a tracking station, with any sort of relative motion taken into consideration... You'd still be solving for a course/heading to the target. Keeping in mind that both your craft and the craft adrift are both subject to the same relative drift (so zero impact in the analysis).
https://steamcommunity.com/sharedfiles/filedetails/?id=2308050926
The post above is essentially the "Tracking Station" I eluded to in the last sentence of my last post on this thread.
As a result, I did go back and delete the other ELT example I started with that just gave a distance reading on a digital display.
The ELT plotter in MoBo plots a faint range circle with every beep and no limit on the sample size. So visually, you end up with a high degree of accuracy in determining the target location by using (potentially) hundreds of overlapping range circles. Outliers are easily dismissed by your own intelligent observation. The plotter in MoBo actually seems a bit unfair. There's no doubt where the craft is... you can literally point to it, every single time.