Using ClockOffsetDriver with Bistatic measurements

Orekit Python Wrapper usage
1

Hello everyone,
First post here in the forum.
I am trying to generate bistatic (laser) ranges with BistaticRange objects and feeding them into a BatchLSEstimator to estimate the orbit. As both groundstations’ clocks might not be synchronized, a clock offset delta_t would add to the measured signal time of flight. To model and estimate this clock offset I tried using the ClockOffsetDriver of the Groundstation used to generate the bistatic ranges (I am using the Python wrapper):

...
delta_t = 10E-9

lon_zwd = radians(7.4652)
lat_zwd  = radians(46.8772)
alt_zwd  = 951.2
point_zwd = GeodeticPoint(lon_zwd, lat_zwd, alt_zwd)
frame_zwd = TopocentricFrame(earth, point_zwd, "Zimmerwald")
station_zwd = GroundStation(frame_zwd)
station_zwd.getClockOffsetDriver().setValue(delta_t)
station_zwd.getClockOffsetDriver().setSelected(True)

lon_grz = 15.493
lat_grz = 47.0671
alt_grz = 539.4
point_grz = GeodeticPoint(lon_grz, lat_grz, alt_grz)
frame_grz = TopocentricFrame(earth, point_grz, "Graz")
station_grz = GroundStation(frame_grz)

start_time = AbsoluteDate(2023, 7, 14, 0, 0, 0., UTC)
end_time = AbsoluteDate(2023, 7, 14, 3, 0, 0., UTC)
dt = 10.
bistatic_error = 10.
bistatic_weight = 0.8
sigma_range = 10.
seed = 42

noise_covariance_matrix = MatrixUtils.createRealDiagonalMatrix([sigma_range**2])
corr_noise = CorrelatedRandomVectorGenerator(noise_covariance_matrix, 1e-10,
                                             GaussianRandomGenerator(MersenneTwister(seed)))

obs_sat_b = ObservableSatellite(0)
bs_generator = Generator()
bs_generator.addPropagator(propagator)
bs_range_builder = BistaticRangeBuilder(corr_noise, station_zwd, station_grz, bistatic_error, bistatic_weight, obs_sat_b)
bool_detector = BooleanDetector.andCombine([zwd_ele_detector, grz_ele_detector])
bs_scheduler = EventBasedScheduler(bs_range_builder,
                                   FixedStepSelector(dt, UTC),
                                   propagator, bool_detector,
                                   SignSemantic.FEASIBLE_MEASUREMENT_WHEN_POSITIVE)
bs_generator.addScheduler(bs_scheduler)
...

For a time offset of 10 ns I would expect a shift in range of about 3 m. In practice, the measurements generated with and without the clock offset are identical.
Am I using the ClockOffsetDriver correctly? How could I model the station clock offset in Orekit in such a way it could also be estimated?
Cheers,
Pascal

2

Hello @pascal.sauer,

Welcome to the forum !!

Comparing the computation of signal time of flight in two-way Range and BiStaticRange, it looks like the ClockOffsetDriver is not used in BiStaticRange…

You found a bug, thank you !! Could you please open an issue on the forge?

Cheers,
Maxime

3

Hello @MaximeJ,
Thank you for the warm welcome and the fast reply. I have opened an issue on the forge, as you advised.
Cheers,
Pascal

1 Like
4

Hello @MaximeJ,
despite my very basic Java-skills, I have tried my hand at a fix for this issue:
BistaticRange.java (10.9 KB) (lines 148-153 and 210-215).
I have implemented it analogous to the way it is done in Range-measurement.
Testing it in Python shows that the value gets modified as expected and my BatchLSEstimator is able to estimate the ClockOffset. Are there any more tests I need to run or things I need to do before I open a merge request?
Cheers,
Pascal

5

Hello @pascal.sauer,

It’s great that you could fix it! Thanks a lot! It’s always nice to welcome new contributors.
For your contribution, I invite you to read the contribution guide if you haven’t done it already.
There you will find information on:

  • The overall contribution process in the section “improve-source-code”,
  • Tutorials for configuring the tools for code quality (checkstyle and spotbugs) and how to connect to SonarQube (the online code analyzer)

Your contribution is a bug fix so it is eligible for a patch release (we try to release patches monthly if we can). So please start your branch “issue-1418” from the branch patch-12.2.1, this will also be your target branch for the merge request.

For testing, we have a target of 95% of coverage on the new code. Since your fix changes a few lines I think it should be easy to cover. You can add a method “testIssue1418” in class BistaticRangeRateTest where you check that the clock value is correctly taken into account in both methods “theoreticalEvaluation…”

Last thing, when you’re done, don’t forget to add your name in the contributors section of the pom.xml :wink:

If this is too much info to process at once you can just open a merge request with the prefix “Draft” on the forge and we will guide you step by step from there.

Cheers, and thanks again for your upcoming contribution!
Maxime

2 Likes
6

Hello @MaximeJ,
Over the last week I tried to follow all of your suggestions (read the contribute section, configured checkstyle, wrote testIssue1418 and added my name) on my local fork (draft_issue-1418) to prepare for a merge request. I have however encountered some problems.

  • Following the SonarQube pipeline tutorial in the contribution guide it always failed, as I need a runner. Is it possible to get access to the shared GitLab runners? Is there documentation, how I could configure my own runner?
  • When I tried developing my fix on the patch-12.2.1 or the develop branch, I encountered problems compiling Orekit, as hipparchus version “4.0-SNAPSHOT” was missing, which I could not find on the hipparchus git. Therefore I tested my code on last stable version 12.2. Is this a problem?

Should I just submit my merge request, or wait until I managed to run the pipeline?
Thank you very much for the help,
Pascal

7

Hi Pascal,

my bad, I had created the patch-12.2.1 branch from develop instead of release-12.2. It’s fixed now so you can change the target of your MR.

Cheers,
Romain.

8

Hi @pascal.sauer,

No there is no documentation because you need admin rights to activate a runner on a fork.
I just added your fork to one of the runner so you should be able to run a pipeline now.
Sorry about that, I think this point will be smoother when we will be able to analyse merge requests directly.

You can open the MR, thanks!

Maxime

9

Thank you very much for your guidance. I have opened a merge request.

Pascal

1 Like