Visibility/obstruction charts

[tomaszmrugalski]

We have very nice pass plots. However, they assume that there's 100% horizon visibility without any obstructions. We could implement some sort of visibility information. Trickle planner for GPS planning had a cool feature like that. We could come up with something similar.

For now, this could be for information purposes only. But in the future, we could use that for observation planning. No need to listen to a sat if it's behind a building.

[fivitti]

I think that we can also implement obstacle map in planning process. Now we have a possibility for set minimal AOS elevation. But more powerful will be 360 degrees mask.

For example as you know our antenna is covered by wall from one side. It will allow us to avoid recording when satellites are hidden when flight from that side.

[fivitti]

We can inherit the LocationPredictor class and overload the iter_passes function. It will call the original implementation to get the pass iterator. Next, we will crop the passes in these places where obstacles occur.

The new class will accept the obstacle mask in the constructor. This mask will be a CSV file with azimuth degree and obstacle elevation at a specific angle. Users will be able to provide as accurate data as they want. The elevations for missing angles will be interpolated (we can implement linear or polynomial interpolation to choose by user).

The predictor will accept the standard parameters as aos_at, los_at, max_elevation_degrees. Additionally, it may accept maximal duration of signal override to avoid unnecessary reception interruption.

[tomaszmrugalski]

The LocationPredictor inheritance makes sense.

I'm not sure if the CSV format will be enough. I think there are several aspects here:

• some obstructions are soft, i.e. there's a building that blocks path, but we can point antenna there. If there's no better path, antenna can pass through this, just the reception will be poor.
• some obstructions are hard, i.e. there's a wall, roof, or whatever that physically prevents antenna from moving in that direction. If we try to move it there, equipment damage will occur and we should never do this.
• for some antenna/rotor configuration, I had a conflict with a roof over my balcony. For directions az=0-40 degrees, antenna could move horizontally when it was pointing relatively low (el=0-30 degrees), it would hit the roof for mid-elevations (el=30-60 degreees) and was moving ok if way pointed up (el=60-90 degrees).
• ultimately we should address several use cases:
  1. fixed omni antenna that is obscured in some directions
  2. fixed directional antenna that is pointed in some specific direction. It has some selectivity and there's no point in listening when sat is outside of its primary beam.
  3. moving directional antenna that can move freely everywhere, but is obscured in some directions
  4. moving directional antenna that has its movements restricted in some directions

It's complicated. We can support all of them, but it's fine if choose to focus on some of them for now,

[fivitti]

I think that there are two separate use cases:

• Rotor controlling
• Pass planning

The "obstacle" meaning is different in both cases.

In rotor controlling, you need to define a path to avoid collision with obstacles. We need to analyze only blocks near the antenna (in rotation radius). These obstacles sometimes have a small height and width - it means that in some cases, you can move below or above the obstruction. Additionally, an object that is an "obstacle" for the rotor may be "transparent" for receiving the signal.

The obstacles can be far from the antenna (e.g., buildings). In this case, you can assume that the obstacles are filled - you cannot receive the signal only above the block.

In summary - I think that we should have separate obstacle models for controlling and for planning. My above proposal was about pass planning. I agree with you that we need the elevation range for controlling the rotor, but in pass planning, we can use only the maximum elevation on a specific azimuth.

I will try to implement the obstacle model generic to re-use this component in the rotor controller. But rotor-related design should be discussed in the svarog-ctl repository.

[tomaszmrugalski]

That's a fair assessment with the planning and rotor control. It more or less maps to my concept of soft and hard limits.

Reusing the code for obstacle model sounds great!