[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[GavinZac]

Just my 2 cents.

I see the talking about using Kethane style interface, but personally I prefer the SCANSat way of visualization, more realistic.

I preferred the old Kethane interface as well. Would be perfect if we could visualize Kethane as an overlay on ScanSat map for example.

It's a beautiful interface, but it's just not for my taste. I think it's ok as an option for the people who like it though.

I'd just like it as an option. I don't think of it as 'looking out the window' and seeing the biomes magically laid out, but surely if nuclear propulsion exists in the Kerbal Universe, Google Earth "Koogle Kerbin" should exist.

[Justin Kerbice]

Hi,

I use a FireSpitter K-17 plane fully equipped with SCANsat sensors, all ON (except the one which have only "open map" action) and I have this:

After a few kms of flying (I've made also 90 kms on a previous flight in the same config), no data recorded.

Strangely, for this previous flight, some color have appeared on the map but I'm not sure on the way to did it, maybe some warp while flying.

On another KSP install, I start by putting a SCANsat satellite on orbit, gathering some data, then a same plane, same kind of flight, and I got data on the move.

Is this a bug or it's me who don't use SCANsat as designed ?

Thanks.

[Pondafarr]

SCANSat has minimum altitude requirements. The only low-altitude scanner is the BTDT (with a scan range of 2km) all the others are at least 100 km I believe, but ranging up to 750km.

[Horus]

AFAIK, scanners are height dependent.

Each scanner has in its' configs the following:

fov = #

min_alt = #####

max_alt = #####

best_alt = #####

When your height exceeds min_alt or max_alt the scanner becomes inoperable.

No more magic here (well... except fov usage & warping)

[Greys]

While we're on the subject of intermod integration, I'd really love to be able to see mechjeb rover waypoint routes, and aet new waypoints via SCANsat. As well as Bloody has done with his interface the mapview doesnt reflect actual terrain to any real precision, and the ship view has it's own assorted problems. Most of it would be straight forward drawing points over the map, inaccuracies in the map projection may complicate drawing lines but that's more a matter of math and subdivision. I've spoken to BloodyRain2K on the matter and I believe he said that the routes system already makes point data and point entry possible.

I'd also like a larger zoom popup, that little 1"x1" window is infuriating

[Starstrider42]

- A sensor's field of view degrades linearly below the optimal altitude,

and remains constant between optimal and maximum altitude. Parameters

are scaled based on planet radius and SoI size, so you can still map

Gilly.

How does the scaling work? For example, if I'm trying to map the Mun (1/3 the radius of Kerbin, 3% its SoI), what are the optimal and maximum heights for the low-resolution radar?

[sidfu]

starstrider look in the .cfg each one tells the maxium height it can read at. for me i normaly get close to that and let it roll normaly finish in day or 2 at most at 90

[DMagic]

How does the scaling work? For example, if I'm trying to map the Mun (1/3 the radius of Kerbin, 3% its SoI), what are the optimal and maximum heights for the low-resolution radar?

I believe the values vary by 600/(radius of the current body), or maybe by the square root of that, I'm not entirely sure. It also seems that the scale doesn't change for anything bigger than Kerbin.

[Pondafarr]

The scan altitude parameters are located in the part's config file, and does not appear to change when it is around a different body. Of course, thats where you can manually change the min/max altitudes to fit your requirements. I changed all my scanners to be linearly consistant from the original versions.

for example:

SCAN RADAR Altimetry Sensor

MODULE

{

name = SCANsat

sensorType = 1

fov = 5

min_alt = 5000 <---minimum altitude

max_alt = 500000 <---maximum altitude

best_alt = 5000 <--- ideal altitude

[DMagic]

The scan altitude parameters are located in the part's config file, and does not appear to change when it is around a different body. Of course, thats where you can manually change the min/max altitudes to fit your requirements.

From what I can gather the FOV definitely changes based on the planets radius. I can't see anything that directly changes the alt values though.

[Pondafarr]

Ahh, i see what you mean. I didn't notice the entry for FOV. I think I was also confusing with Kethane sensors, which have a "detecting period." Logicly, a larger FOV will increase the width of the scan path. For example, the BTDT scanner has a FOV of 1, while the SAR has a FOV of 5. Appears to be generally inversely proportional to level of detail available. Basic scan has wide path, specific scan has narrow. Functionally, this means the most efficient scan coverage should be at maximum height (to cover widest area, taking fewer orbits), but that will be slower due to orbital velocity at higher altitudes. Lower altitude would cover a narrower area, but may be compensated by traveling over the surface faster (taking more orbits)

I believe you can calculate the actual width of scanned area by plugging the scanner altitude into a triangle formula, using the FOV number as the angle of the top of the triangle, and the altitude on both sides to derive the base (or viewed area)

This will effect scan pattern on other bodies, because the diameter of those bodies are different from Kerbin. At 750km, a the basic SCAN RADAR Altimetry Sensor (fov 5) will cover approx 65km wide path regardless of which body its over. This width APPEARS bigger on a smaller body like Minmus, but its still 65 km wide.

Very interesting variability of capability.

Edited March 2, 2014 by Pondafarr

[Starstrider42]

So the documentation is wrong and parameters *aren't* scaled to different planets? That does make my life easier...

@Pondafarr: AFAIK, Scansat doesn't use conical FOVs or realistic scaling with distance from the surface. On Kerbin, at least, the "FOV" parameter is the width of the stripe in degrees of latitude, and it's a constant on-ground width anywhere between the optimal and maximum altitudes.

Edited March 2, 2014 by Starstrider42

[Pondafarr]

Would you please point me to where you found that info? I want to learn a bit more...I was simply using a logical interpretation of the data I had...so as usual, I was prolly completely wrong

[DMagic]

So the documentation is wrong and parameters *aren't* scaled to different planets? That does make my life easier...

@Pondafarr: AFAIK, Scansat doesn't use conical FOVs or realistic scaling with distance from the surface. On Kerbin, at least, the "FOV" parameter is the width of the stripe in degrees of latitude, and it's a constant on-ground width anywhere between the optimal and maximum altitudes.

I believe the FOV scaling with distance is (current altitude / ideal altitude) * FOV, so just a linear scale up to the ideal altitude then fixed up to the max altitude (or the SOI for Gilly). I guess it doesn't really make sense for the ideal altitude values to change with planetary radius, the scanner should work the same regardless of how big the planet is.

Edit: I see in changelog 4 that FOV scaling works just like I described above. It does also mention that parameters are scaled based on the radius and SOI, but as far as I can see this just refers to changing the FOV based on radius and checking to see if the SOI is less than the ideal scan altitude. I think Gilly is the only planet where this applies, its SOI is only a 100 or so km, so that is where the ideal altitude is.

Edited March 2, 2014 by DMagic

[Starstrider42]

I've since confirmed that FOV for Minmus is about 7 times that for Kerbin, and that the maximum altitude doesn't change at all, so the comments that it's the FOV that gets rescaled seem to be spot on. I'm not sure where the number 7 comes from, though: Minmus has 1/10 the radius of Kerbin, and 2.7% its SoI.

[Pondafarr]

How did yoju test that? It would be good to discover the actual methodology behind the scan pattern, so our orbits can be optimized.

[Starstrider42]

How did yoju test that? It would be good to discover the actual methodology behind the scan pattern, so our orbits can be optimized.

That was why I asked my original question -- so I could better plan missions.

As for the test, simple. Get into an orbit at the maximum scanning altitude. Briefly turn the scanner on to get one "pixel" (or, if your ground track is well behaved, don't bother turning it off). Measure the coordinates of the edges of the scanned area on the big map (preferably latitude, since a degree of longitude has a variable length). Repeat for Kerbin if you feel the need to calibrate.

[Hodo]

So has anyone found a way to combine the Kethane scan with the maps for scansat? Because I am looking, after I downloaded the RSS mod my grid has gone away and quite frankly I got tired of seeing it anyway, I would rather see it on a SCANsat map report it makes a bit more sense that way. If anyone has any ideas on how to get the Kethane scanners to render their reports to the SCANsat map please tell me.

[GavinZac]

So has anyone found a way to combine the Kethane scan with the maps for scansat? Because I am looking, after I downloaded the RSS mod my grid has gone away and quite frankly I got tired of seeing it anyway, I would rather see it on a SCANsat map report it makes a bit more sense that way. If anyone has any ideas on how to get the Kethane scanners to render their reports to the SCANsat map please tell me.

AGAIN, it is not a case of "figuring something out". It would require a rewrite of SCANsat's code. That's how you do it. Best of luck, looking forward to it, cheers.

[Hodo]

AGAIN, it is not a case of "figuring something out". It would require a rewrite of SCANsat's code. That's how you do it. Best of luck, looking forward to it, cheers.

Never said I was going to recode the files, was asking. No need to get bent over it.

[darkshockwave78]

Hey does anyone know how to get SCANsat to scan all of the planet with one pass? I'm kinda just playing around with it.

[Pondafarr]

for a 0 deg equatorial orbit, I would try changing the FOV in the scanner config to be >90 <180. If it works, you may still miss the poles.

[DMagic]

for a 0 deg equatorial orbit, I would try changing the FOV in the scanner config to be >90 <180. If it works, you may still miss the poles.

I think the fov limits itself to 20. You can try, and it might work, but at the least it will make it go much faster.

[Horman]

During gaining more and more experience in the game, I also gain more parts in my tech tree - but also some more questions are coming up:

1) Are the anomalies, shown in the map equivalent to the "easter-eggs"?

I just finished my first run with the BTDT-Scanner at the KSC - and as you all know, it shows me the KSC-Astronautskomplex. But if I get close to the monolith close to the shore, nothing happens.

2) When I opened the options window, I discovered, that Kerbol is also scanable. With this in mind, I am planning my first Kerbol-Probe. But now I am not sure, in what orbit I shall send it, to get the best scan-results. I guess, I might not be able to use the low-res-scanner, because of the max-altitude? Any suggestions in this case?

Thx for your help!

[Pondafarr]

1) yes, until scanned by the BTDT, the anomalies are not named. It seems the KSC monolith is considered to be part of KSC

2) each scanner uses a different minimum and maximum altitude. So while you could put all the scanners on one probe, you may have to adjust your orbit to optimize the scans.