[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] FieldOfView Detector
Le 20/01/2016 16:10, Evan Ward a écrit :
> I've added a detector, similar to ElevationDetector, for using an FoV
> from the ground.
Great, thanks a lot.
>
> Also I think we should keep the CircularFieldOfViewDetector. It is a
> simple common case and I think its implementation of the g function will
> be more accurate and faster the the g function in the FoV detector.
> Since the FoV class builds a spherical region using arcs of great
> circles a small circle must be approximated as a polygon with many
> sides. In one case I tested I had to use 16 vertices to get a decent
> approximation of a small circle. So without having done any performance
> tests I think the CircularFieldOfViewDetector will be simpler for the
> user to configure and faster.
You are right. I have undeprecated it and put it back in
the documentation.
best regards,
Luc
>
> Best Regards,
> Evan
>
>
> On 01/19/2016 03:00 PM, MAISONOBE Luc wrote:
>>
>> Evan Ward <evan.ward@nrl.navy.mil> a écrit :
>>
>>> On 01/19/2016 09:01 AM, MAISONOBE Luc wrote:
>>>>
>>>> Evan Ward <evan.ward@nrl.navy.mil> a écrit :
>>>>
>>>>> On 01/18/2016 09:27 AM, Luc Maisonobe wrote:
>>>>>> Le 18/01/2016 15:16, Luc Maisonobe a écrit :
>>>>>>> Hi Evan,
>>>>>>>
>>>>>>> Le 15/01/2016 09:25, Luc Maisonobe a écrit :
>>>>>>>> Le 14/01/2016 22:11, Evan Ward a écrit :
>>>>>>>>> Hi Luc,
>>>>>>>> Hi Evan,
>>>>>>>>
>>>>>>>>> I noticed your recent work on the new field of view classes. I
>>>>>>>>> think
>>>>>>>>> these are a great addition. Would it be possible to model an
>>>>>>>>> antenna
>>>>>>>>> attached to a ground station? I think the current
>>>>>>>>> implementation of
>>>>>>>>> FieldOfView requires a spacecraft state.
>>>>>>>> You caught me red handed!
>>>>>>>>
>>>>>>>> I am also not really comfortable with the spacecraft state in the
>>>>>>>> offsetFromBoundary method. It induces a dependency that is not
>>>>>>>> right. It is currently used to convert the input position into
>>>>>>>> a line of sigth, and this computation should better be performed
>>>>>>>> at call site, not within the method.
>>>>>>>>
>>>>>>>> I'll fix this in a few minutes.
>>>>>>> I think I will reintroduce a method dedicated to the case the
>>>>>>> Field Of
>>>>>>> View is spacecraft centered. It will be something like:
>>>>>>>
>>>>>>> List<GeodeticPoint> getFootprint(SpacecraftState state,
>>>>>>> OneAxisEllipsoid body);
>>>>>>>
>>>>>>> I think it will be better here than for example in
>>>>>>> FootPrintOverlapDetector because there is no predefined geographic
>>>>>>> zone
>>>>>>> here and the method is expected to be called typically from a
>>>>>>> StepHandler throughout propagation.
>>>>>>>
>>>>>>> Do you agree with this new method?
>>>>>> Also if we add this method, do you think FieldOfView should remain in
>>>>>> the events package? Perhaps it should be moved to utils (but utils
>>>>>> is already quite crowded an unstructured).
>>>>>>
>>>>>> best regards,
>>>>>> Luc
>>>>>
>>>>> I presume the getFootprint method would project a region of the
>>>>> satellite's celestial sphere to the Earth and then return a set of
>>>>> points along that boundary.
>>>>
>>>> Yes.
>>>>
>>>>> I think it would be a very useful method to
>>>>> have and I can see the logic in keeping it where it is. As for the
>>>>> parameters, if you're using the ellipsoidal Earth assumption to
>>>>> make the
>>>>> computation quicker then I think OneAxisEllipsoid is the right
>>>>> type. On
>>>>> the other hand if the algorithm is using ray tracing or some similar
>>>>> algorithm then I think using a BodyShape would add flexibility so
>>>>> users
>>>>> could include the effects of terrain by providing and terrain based
>>>>> BodyShape.
>>>>
>>>> I use ellipsoidal body assumption, and I do take into account its
>>>> flatness. For the parts of the fov boundary that will really hit the
>>>> ground, it is in fact some ray tracing and it calls the general
>>>> getIntersectionPoint method defined in the BodyShape interface.
>>>> However, this cannot be done if parts of the fov skim over horizon,
>>>> as we need here to use the points of the limb to wrap around the
>>>> visible area on ground. This is where the ellipsoidal body assumption
>>>> is used. There is also a special degenerate case if the fov is large
>>>> enough it contains all the Earth and none of the boundary points
>>>> mett the ground. Here, we return the full limb.
>>>>
>>>> As per your previous message about ground antenna pattern,
>>>> I will change the signature to:
>>>>
>>>>
>>>> List<List<GeodeticPoint>> getFootprint(Transform fovToBody,
>>>> OneAxisEllipsoid body,
>>>> double angularStep)
>>>>
>>>> With this javadoc:
>>>>
>>>> /** Get the footprint of the field Of View on ground.
>>>> * <p>
>>>> * This method assumes the Field Of View is centered on some
>>>> carrier,
>>>> * which will typically be a spacecraft or a ground station
>>>> antenna.
>>>> * The points in the footprint boundary loops are all at altitude
>>>> zero
>>>> * with respect to the ellipsoid, they correspond either to
>>>> projection
>>>> * on ground of the edges of the Field Of View, or to points on
>>>> the body
>>>> * limb if the Field Of View goes past horizon. The points on the
>>>> limb
>>>> * see the carrier origin at zero elevation. If the Field Of View
>>>> is so
>>>> * large it contains entirely the body, all points will
>>>> correspond to
>>>> * points at limb. If the Field Of View looks away from body, the
>>>> * boundary loops will be an empty list. The points within
>>>> footprint
>>>> * the loops are sorted in trigonometric order as seen from the
>>>> carrier.
>>>> * This implies that someone traveling on ground from one point to
>>>> the
>>>> * next one will have the points visible from the carrier on his
>>>> left
>>>> * hand side, and the points not visible from the carrier on his
>>>> right
>>>> * hand side.
>>>> * </p>
>>>> * <p>
>>>> * If the carrier is a spacecraft, then the {@code fovToBody}
>>>> transform
>>>> * can be computed from a {@link
>>>> org.orekit.propagation.SpacecraftState}
>>>> * as follows:
>>>> * </p>
>>>> * <pre>
>>>> * Transform inertToBody =
>>>> state.getFrame().getTransformTo(body.getBodyFrame(), state.getDate());
>>>> * Transform fovToBody = new Transform(state.getDate(),
>>>> *
>>>> state.toTransform().getInverse(),
>>>> * inertToBody);
>>>> * </pre>
>>>> * <p>
>>>> * If the carrier is a ground station, located using a topocentric
>>>> frame
>>>> * and managing its pointing direction using a transform between
>>>> the
>>>> * dish frame and the topocentric frame, then the {@code
>>>> fovToBody} transform
>>>> * can be computed as follows:
>>>> * </p>
>>>> * <pre>
>>>> * Transform topoToBody =
>>>> topocentricFrame.getTransformTo(body.getBodyFrame(), date);
>>>> * Transform topoToDish = ...
>>>> * Transform fovToBody = new Transform(date,
>>>> * topoToDish.getInverse(),
>>>> * topoToBody);
>>>> * </pre>
>>>> * <p>
>>>> * Only the raw zone is used, the angular margin is ignored here.
>>>> * </p>
>>>> * @param fovToBody transform between the frame in which the Field
>>>> Of View
>>>> * is defined and body frame.
>>>> * @param body body surface the Field Of View will be projected on
>>>> * @param angularStep step used for boundary loops sampling
>>>> (radians)
>>>> * @return list footprint boundary loops (there may be several
>>>> independent
>>>> * loops if the Field Of View shape is complex)
>>>> * @throws OrekitException if some frame conversion fails or if
>>>> carrier is
>>>> * below body surface
>>>> */
>>>>
>>>> So you will also be able to use this method for your ground station
>>>> (or an airborne antenna, or anything like that).
>>>
>>> Looks good to me. I think supporting an airborne sensor is a good
>>> additional use case, as you point out.
>>
>> The method is available. It still needs some polishing as one
>> test case does not work, but it seems to give very good results
>> apart when the sensor if properly configured.
>>
>> You can update the javadoc if you want.
>>
>> best regards,
>> Luc
>>
>>>
>>> Regards,
>>> Evan
>>>
>>>>
>>>> best regards,
>>>> Luc
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Evan
>>>>>
>>>>>>
>>>>>>> best regards,
>>>>>>> Luc
>>>>>>>
>>>>>>>> I did not foresee using this for ground stations! Once the method
>>>>>>>> signature is fixed, it may be used this way too. Would you mind
>>>>>>>> updating the javadoc to explain this other use? I don't know
>>>>>>>> either if the name FieldOfView is well suited in this case, so
>>>>>>>> maybe it
>>>>>>>> should be renamed at the same time.
>>>>>>>>
>>>>>>>> best regards,
>>>>>>>> Luc
>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Evan
>>>>>>>>>
>>>>
>>>>
>>
>>
>