Feature request: Add ability to point antenna in arbitrary directions

[drveyl]

Feature request: Add ability to point antenna in arbitrary directions

[DRVeyl]

The tricky part is that something would need to update the 'target point' as the body they're in the SOI of, rotates.

Accurate.

Change RealAntenna.ToTarget() to handle a third object type for Target, some kind of AimingOffset object, that has a CelestialBody, Elevation, Azimuth (and maybe distance, but we wont need that here) properties. Unless there's a way to get the current SOI celestial body, in which case use that.

Close. I was thinking about this this morning. Which is a good sign for its chances of making it into RA. Let me broaden the scope a bit, to actually match the title, because the point is to give arbitrary pointing, and the question is why not?

The original design DID intend to limit what you could point at. It was a design choice to originally not include specific ground stations. I revised things slightly to make them a valid target for purposes of the planner, but don't include them in what you can select through UI. There's work-arounds: you can always go put your own vessel where a ground station would be, and target that proxy, though I don't know if anyone has ever bothered. Mostly it's a usability thing, where the player doing it carefully would help, but doing it naively might just produce worse results. ("There's a ground station right below me, but I'm not using it because my antenna slewed off towards the horizon and the peer just dipped out of sight...")

So let's try the best of both worlds. What we really want is independent targeting modes. We have 2 [3] right now:

• Vessel
• Body-center
• [Ground Station]

You're proposing an Az/El mode, where the antenna is oriented as if it is on the ground at whatever altitude it happens to be at. This will have unexpected behaviour in orbit, but it can be consistent, and "Choose a more appropriate target mode" is a valid remedy. Azimuth 000 is aligned towards the north pole wherever you are.

Another proposed mode is offset from body center. Not quite az/el, but similar. The question is what are the two axes? This is simple for an equatorial orbit, but which way is "north" for a highly inclined one? The planet axes for lat/lon are probably inappropriate. But how about relative to vessel velocit, adjusted for eccentric orbit? Let "In" be the vector from vessel to body center. "Up" is vessel prograde cross "In". "Forward" is "In" cross "Up." Valid values are in [-180,+180] for each (so you could theoretically use this frame to point outward).

There is probably a mapping between this mode and Az/El. Az/El is easier to understand from a user's the perspective on the ground.

Note this would have strange behaviour on highly eccentric orbits: looking 30 degrees to the side will still encompass much of the planet at low altitude, but might not cover any of it at high altitude. Is there a variant that keeps the same axes, but the deflections are from -1.0 to +1.0, as the fraction of the current angle from body center to horizon? Or is this variant strictly better than the other line?

Body-center would become just a specific configuration of the above, either variant, with the offset as [0,0].

Another mode is Body Fixed Lat/Lon. Antenna points at a spot on the ground, wherever that is on the planet [including occluded]. Use at your own discretion. Ground Station targeting is a specific configuration of this.

I use all that to set the stage for this: the complexity of dealing with these is currently nested in that ToTarget logic, and a bunch of other little pieces that try to make sense of it and store it, and it's sort of brittle to expanding. I believe a much better way forward is to convert the targeting mechanic to no longer require a Vessel/CelestialBody [... or a GroundStation, functionality that was added later], but instead just an arbitrary Monobehaviour that will independently track . How it tracks depends on the mode. (Implementation: Write a separate Monobehaviour for each mode, and switching modes destroys one and instantiates a new. This makes it very easy to add or remove modes to the system. The ToTarget function itself is simplified to just the vector towards the target Monobehaviour's position. The added complexity is in actually following the thing you want to track, and keeping a handle on the parameters and what they mean.)

(I appear to have run out of steam at this point!)

[austinjames314]

This doesn't even need to check whether the vessel is landed. You could do the same thing pointing down with a commsat: Have multiple spot beams that are spread out to collectively cover the whole body.

[austinjames314]

Looking through the code more, here are some more ideas for what would need to be done (attempting to work back from PointingLoss() )

1. Change RealAntenna.ToTarget() to handle a third object type for Target, some kind of AimingOffset object, that has a CelestialBody, Elevation, Azimuth (and maybe distance, but we wont need that here) properties. Unless there's a way to get the current SOI celestial body, in which case use that.
2. At this point I wanted to work the vector math out for you, but I can't make heads or tails of the notation in the KSP API documentation. I'd need to figure out quaternions I guess...

Well that didn't go very far. I really want to help realise this as I think it addresses all the issues you pointed out (by setting each dish pointing in a fixed direction), but solves the problem of needing to cover multiple relay 'clients' coming and going. I can't think of any way of contributing to the actual code, so let me know if there's anything else I could do.

[austinjames314]

Yeah I've been thinking about this heaps as well, lol. To the point I've already worked out the best way to overlap beams to cover a wider area, like this:
https://upload.wikimedia.org/wikipedia/commons/3/33/Flower_of_Life_7-circles_hexagonal.svg
Including what multiple of the beamwidth each beam needs to be from each other (2 * beamwidth * Cosine(𝜋/6)), and the width of the new area completely covered by the beams (2 * single-beamwidth).

I originally come at this idea from the point of wanting to be able to point straight up from the ground, and then realised an azimuth/elevation scheme would be required to point at inclination 0 orbits when the grounded antenna is not on the equator. I think that's still a useful use case that argues in favour of an azimuth/elevation scheme.

I then realised that it could be useful from a pointing down perspective, as well. I do see what you mean about az/el from an inclined orbit, but I don't think it matters. It'd result in the beams rotating around each other as the satellite crosses the poles, but that's no big deal I don't think. Please excuse my poor drawing and handwriting skills:
orbital.pdf

To clarify, I think that the 'North' vector can just be a vector parallel to the surface, pointing towards the northern end of the planet's rotation axis. (I'm going to get right hand rule mixed up here, but stay with me) - Cross 'In' (as you described it) with the planet's rotation axis to get 'East'. Cross 'East' with 'In' to get 'North'. Something like that. This would work regardless of inclination. It just means the 'North' moves rapidly as you pass the pole, as per what I tried to draw above. This is fine, as it's the current game behaviour on the nav-ball when in a polar orbit, so it would all be a consistent experience.

To further clarify, in the az/el situation, I'm imagining the az/el values to be rotations from the 'In' vector, so if you're up in a polar orbit at a latitude of 88°, and set az 0°, el -45°, then the beam would be rotated 45 degrees from the 'down' vector towards the 'north' vector, and end up pointed over the other side of the north pole.

You could point from an orbital coordinate/reference system, but I personally can't think of a situation where I'd want to use that

That's all assuming low eccentricity, which you also brought up. I didn't consider this, because from the perspective of trying to arrange multiple beams to cover an area, I'm only interested in one altitude anyway, as outside that the beamwidth invalidates what you're trying to do. Even a Molniya orbit can be considered just from the part of the orbit where the satellite is at the highest, "working" altitude. If you're talking about trying to maintain coverage of specific points on the ground, then the present behaviour of locking on a station or vessel seems perfectly adequate to me.

I think that making sure that the beams stay covering the angles you want is the user's problem to solve. After all, you're assuming I just want to spread my beams out to cover just the surface, What If I want to spread them wider, to cover orbits up to a certain height, to give coverage to lower satellites as well?

All of that it is to say: I still think that a simple azimuth and elevation scheme would be fine, and avoid unnecessary complexity on the user side. (combined with the current system of locking to vessels and stations).
You'd still need to keep the body mode system, so that you can point to bodies outside the current SOI.

As for refactoring the targeting code, if it was me, I'd just be tacking on a new AimingPoint object, and put an if-else in ToTarget. but you do whatever you want.

I'll add one more thought: When it comes to drawing beams on the map for these newly targeted beams, where will it draw the end-point of the beam? Currently it stops at the target object. This is is why I had the idea of an azimuth/elevation/distance input, with the distance being purely there to set the end-point of where the beam is drawn. (Would need to have some explanation in the UI that the distance input is just for cosmetic /map UI purposes).

[DRVeyl]

I agree Az/El is a valid mode to have. The variations I'm more concerned with is the body-offset modes. I think the spots rotating as you pass around the pole is undesirable - consider what happens when you do not fill all the spot beams, how obvious is the track of any given spot beam? That's why I discussed a setup where the orientation of any beam is constant relative to the spacecraft-to-ground vector, and a variant where that is scaled by orbit eccentricity.

If you wanted to allow the beam centers to point above the horizon in the scaled mode, the value range could be +/- 1.2 instead of +/- 1.

I think that making sure that the beams stay covering the angles you want is the user's problem to solve

Yes, but I have to provide tools that can achieve this, and it's better that they behave in as predictable a manner as possible.

As for refactoring the targeting code, if it was me, I'd just be tacking on a new AimingPoint object, and put an if-else in ToTarget. but you do whatever you want.

Systems built on special cases for handling... show that fact when they try to grow. So if I'm going to open up the concepts for where antennas are allowed to point, I need it to look like a cohesive system that can be maintained. (Ideally, that also becomes practical to do by people other than me.)

When it comes to drawing beams on the map for these newly targeted beams, where will it draw the end-point of the beam?

There is a fixed max distance, capped by the distance to the target object.

[austinjames314]

I agree Az/El is a valid mode to have. The variations I'm more concerned with is the body-offset modes. I think the spots rotating as you pass around the pole is undesirable - consider what happens when you do not fill all the spot beams, how obvious is the track of any given spot beam? That's why I discussed a setup where the orientation of any beam is constant relative to the spacecraft-to-ground vector, and a variant where that is scaled by orbit eccentricity.

Fair enough, I was just trying to say you didn't need to go to that extent if you didn't want to. I'm not going to complain about more features!

Systems built on special cases for handling... show that fact when they try to grow. So if I'm going to open up the concepts for where antennas are allowed to point, I need it to look like a cohesive system that can be maintained. (Ideally, that also becomes practical to do by people other than me.)

Oh I'm well familiar with the concept of technical debt. Again, just trying to suggest an easy out, because I'm greedy and want this feature now, lol.

There is a fixed max distance, capped by the distance to the target object.

Sure, but what is the target object for a beam that's been aimed by coordinates, rather than at an object? Are you saying without a target object it'll go to the default max distance? I'm guessing that'll be really far away? Would that mean all the beams pointed down around a body will appear to stick out the other side?

[DRVeyl]

Sure, but what is the target object for a beam that's been aimed by coordinates, rather than at an object? Are you saying without a target object it'll go to the default max distance? I'm guessing that'll be really far away? Would that mean all the beams pointed down around a body will appear to stick out the other side?

Good questions.
https://github.com/DRVeyl/RealAntennas/blob/master/src/RealAntennasProject/MapUI/RACommNetUI.cs#L125-L126

Az/El mode would probably just draw the max distance, which is 100 Mm currently.
Body-offset would probably draw like it currently does for body target, where the length is from the vessel to body center, less body radius. Yes, I'd need some additional smarts in the drawing code to understand the target mode, and that the "target" itself is just an arbitrary point.

Been about a year since I last worked on the map drawing code. Haven't thought about this part yet.

[DRVeyl]

Mode that hasn't made the list so far is the orbit-relative mode that would also lock to the edge of the parent body (ie the SOI).
Currently looking at:

• Vessel: Point directly at a Vessel, like current behaviour.
• Body Center: Point directly at the center of a Celestial Body, like current.
• Body Lat/Lon/Alt: Point at a fixed point in space (relative to the target body). Negative altitude is below ground.
• Az/El: Treating vessel altitude as if it were on the body surface, point at specified azimuth (000 = North) and elevation angle (90 = radially outward, 0 = tangent to the surface at the current vessel altitude), and an Orbit-Relative mode that is not scaled.
• Orbit Relative: Given the basis set corresponding to KSP's prograde, radial and normal vectors, specify deflection from prograde (+/- 180 degrees) and elevation in the normal plane.