[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Users] how to calculate iss passes



I thank you again for your clear answer.
I'm trying to understand Orekit using and playing with it, I think it's a great and well documented software! Very good!


Il domenica 26 febbraio 2017, MAISONOBE Luc <luc.maisonobe@c-s.fr> ha scritto:
>
> MAISONOBE Luc <luc.maisonobe@c-s.fr> a écrit :
>
>> Matteo <appdeveloper80@gmail.com> a écrit :
>>
>>> I thank you again for your answer, I'm trying to use formula in this post (
>>> http://stackoverflow.com/questions/19739831/is-there-any-way-to-calculate-the-visual-magnitude-of-a-satellite-iss)
>>> for reflection model.
>>>
>>> When I use ElevationExtremumDetector, I'm actually filtering for positive
>>> elevation: in this case regarding number 2) (the fact ISS is illuminated by
>>> Sun or in Earth shadow) is ISS always illuminated by Sun?
>>
>> No. ISS is in Low Earth Orbit (very low, indeed) so Earth as seen from ISS fills
>> a very big part of the visible space. ISS is in eclipse roughly half of the time.
>> Basically, if local time at the ground point is such that it is the middle of the
>> night and if ISS flies directly at the zenith, it will also be in the night.
>>
>>
>>> Is
>>> ElevationExtremumDetector filtering for eclipsed transit?
>>
>> No, because for classical operations, we need to be able to get satellite
>> telemetry and send telecommands even at night. We don't really "look" at
>> the satellite, we connect to it using ground stations antennas. So this
>> detector finds by default all passes.
>>
>> Also rather than ElevationExtremumDetector (which will give you only one
>> point, the max of the pass), you can use ElevationDetector which will
>> give you the raising and setting times, and can take into account
>> atmospheric refraction, which distorts rays near horizon. Another
>> reason to use ElevationDetector is that if your ground point is slightly
>> after sunset (or before dawn) and therefore is in night, the max pass
>> will also be in night and you will miss it, despite near the horizon, the
>> ISS may be out of shadow and be visible (despite the observer is in the
>> night part of the Earth, near the terminator).
>>
>>> If not, how can I know if ISS is eclipsed in the "eventOccurred" of an
>>> ElevationExtremumHandler since I'm out of a EclipseDetector event?
>>
>> You can wrap your ElevationDetector within an EventEnablingPredicateFilter
>> object, together with your own implementation of EnablingPredicate based
>> on the g method of an EclipseDetector (not the eventOccurred method, which you
>> don't need here). Something along these lines:
>
> If you are using the development version of Orekit (not released yet), you
> can also use BooleanDetector and the NegateDetector to combine an
> ElevationDetector and an EclipseDetector (you want to be visible AND (NOT
> in eclipse)). The advantages of BooleanDetector over EventEnablingPredicateFilter
> are that
>
>  1) it is simpler
>  2) it will detect for example the end of visibility due to entering eclipse
>     while still being at positive elevation.
>
> The second case mean an observer on ground would see ISS go dark in the
> middle of the sky.
>
> best regards,
> Luc
>
>>
>>  public class Illuminated implements EnablingPredicate<ElevationDetector> {
>>
>>     private final EclipseDetector eclipseDetector;
>>
>>     public Illuminated() throws OrekitException {
>>         this.eclipseDetector = new EclipseDetector(CelectialBody.getSun(),
>>                                                    696000000.,
>>                                                    CelestialBodyFactory.getEarth(),
>>                                                    Constants.WGS84_EARTH_EQUATORIAL_RADIUS);
>>     }
>>
>>     public boolean eventIsEnabled(SpacecraftState state, S eventDetector, double g)
>>         throws OrekitException {
>>         // we are in direct Sun light when the g function of the eclipse detector is positive
>>         return eclipseDetector.g(state) >= 0;
>>     }
>>
>>  }
>>
>> Then, instead of using the ElevationDetector itself, you would use the EventEnablingPredicateFilter
>> that wraps it, and it will perform the filtering logic for you, so you are not bothered
>> with the passes over your ground point that happen when ISS is not illuminated at all.
>>
>> Beware, I just wrote this code quickly in the mail, I did not even try to compile it,
>> so it may well contain errors.
>>
>> bes
>>
>>>
>>> Thanks again!
>>>
>>> Il venerdì 24 febbraio 2017, MAISONOBE Luc <luc.maisonobe@c-s.fr> ha
>>> scritto:
>>>>
>>>> MAISONOBE Luc <luc.maisonobe@c-s.fr> a écrit :
>>>>
>>>>> Matteo <appdeveloper80@gmail.com> a écrit :
>>>>>
>>>>>> Hi Luc,
>>>>>
>>>>> Hi Matteo,
>>>>>
>>>>>> thanks for your fast reply. I've used TLEPropagator and now it's all
>>>
>>> right!
>>>>>>
>>>>>> I'd want to ask if there is a way to calculate also brightness
>>>>>> (magnitude) of ISS.
>>>>>
>>>>> Orekit will help you to compute
>>>>>
>>>>> 1) the distance between ISS and your ground point,
>>>>> 2) the fact ISS is illuminated by Sun or in Earth shadow
>>>>> 3) the Sun-ISS-ground point angle
>>>>>
>>>>> From these, you will have to set up by yourself a reflection
>>>>> model.
>>>>>
>>>>> For item 1, as I assume you already have a TopocentricFrame
>>>>> object associated to your ground point. So at any date, you
>>>>> get the ISS SpacecraftState and just have to compute:
>>>>>
>>>>> distance = state.getPVCoordinates(topoFrame).getPosition().getNorm();
>>>>>
>>>>> For item 2, you can set up an EclipseDetector and call its g function
>>>>> directly with your SpacecraftState, the function will be positive
>>>>> when spacecraft is illuminated and negative if shadowed.
>>>>>
>>>>> For item 3, you have to compute:
>>>>>
>>>>>  CelestialBody sun = CelestialBodyFactory.getSun();
>>>>>  Vector3D sunPos   = sun.getPVCoordinates(topoFrame).getPosition();
>>>>>  Vector3D issPos   = state.getPVCoordinates(topoFrame).getPosition();
>>>>>  double angle      = Vector3D.angle(sunPos.subtract(issPos), issPos);
>>>>
>>>> in fact last line should be:
>>>>
>>>>   double angle = FastMath.PI - Vector3D.angle(sunPos.subtract(issPos),
>>>
>>> issPos);
>>>>
>>>> Luc
>>>>
>>>>>
>>>>> You may also take into account the directions of lines-of-sight in ISS
>>>>> frame for both the incoming and reflected rays, taking ISS attitude (can
>>>>> be assumed to be a LOFOffset attitude with LOFType.VNC local orbital
>>>>> frame and all offset angles set to 0), if you want a reflection model
>>>>> more realistic than something simply based on the Sun-Iss-ground point
>>>>> angle.
>>>>>
>>>>> best regards,
>>>>> Luc
>>>>>
>>>>>> Thanks again!
>>>>>>
>>>>>> Matteo
>>>>>>
>>>>>> 2017-02-23 13:23 GMT+01:00 MAISONOBE Luc <luc.maisonobe@c-s.fr>:
>>>>>>>
>>>>>>> appdeveloper80@gmail.com a écrit :
>>>>>>>
>>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> Hi Matteo,
>>>>>>>
>>>>>>>> I'm trying to calculate iss passes over Rome and I start from
>>>
>>> propagation
>>>>>>>>
>>>>>>>> tutorial and I write this code
>>>>>>>> (https://gist.github.com/anonymous/fb939c0df8e6a72282eb27cc76840ac9).
>>>>>>>> But if I compare the rise and set date with the Heavens Above
>>>
>>> prevision
>>>>>>>>
>>>>>>>> (http://heavens-above.com/PassSummary.aspx?satid=25544&
>>>
>>> lat=41.9028&lng=12.4964&loc=Roma&alt=53&tz=CET)
>>>>>>>>
>>>>>>>> I don't find a match:
>>>>>>>>
>>>>>>>> My code finds:
>>>>>>>>
>>>>>>>> Visibility on station1 begins at 2017-02-23T14:06:33.974
>>>>>>>> Visibility on station1 ends at 2017-02-23T14:12:28.528
>>>>>>>>
>>>>>>>> Heavens Above calculates:
>>>>>>>>
>>>>>>>> 23 Feb  -       12:48:03        10°     NNW     12:50:12        16°
>>>
>>>   N
>>>>>>>>
>>>>>>>> 12:52:20        10°     NE      daylight
>>>>>>>> 23 Feb  -       14:24:14        10°     NW      14:27:21        37°
>>>>>>>> NNE
>>>>>>>> 14:30:26        10°     E       daylight
>>>>>>>> 23 Feb  -       16:00:50        10°     WNW     16:03:44        29°
>>>
>>>   SW
>>>>>>>>
>>>>>>>> 16:06:36        10°     SSE     daylight
>>>>>>>>
>>>>>>>> Note that Heavens Above times are in CET timezone.
>>>>>>>>
>>>>>>>> Can you help me where my error is?
>>>>>>>
>>>>>>>
>>>>>>> From a quick check, I see two things.
>>>>>>>
>>>>>>> First is that you created a Keplerian orbit from mean orbital elements
>>>
>>> and
>>>>>>>
>>>>>>> propagated them as if they were osculating elements. You will get tens
>>>
>>> or
>>>>>>>
>>>>>>> perhaps hundreds of kilometer differences after some propagation time.
>>>>>>> As Heavens Above used TLE, you should use TLE too for propagation, so
>>>
>>> you
>>>>>>>
>>>>>>> use the same semantic on parameters and the same model.
>>>>>>>
>>>>>>> Second, when copying the mean anomaly (131.4349), it seems you forgot
>>>
>>> to
>>>>>>>
>>>>>>> convert from degrees to radians.
>>>>>>>
>>>>>>> Hope thi_s helps,
>>>>>>> Luc
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Matteo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>>
>
>
>