Inconsistent translation Labels for pose estimation track

in the problem description you are writing:
" The ground truth data (transformation vectors) for the public set is available in the output.csv on the Data Download page."
however I cannot find any “output.csv” on the Data Download page, only “train_labels.csv”.
If I then take a closer look to these train labels I find the following:
In the problem description you write, that the translational components are like a random walk, I can confirm this in the images

Question 1: Are these random changes in satellite position in the images just there for confusion/robustness? and not represented in any of the labels? I cannot find anything the the train_labels.cxsv that would correlate with this random jitter in the images.

If I take a further look at the labels, esp. the translational components, I would assume that the x,y,z values are the translational changes (in the unit meter? )in 3D of the 2 spacecraft. You also offer a laser range finder dataset with the distance of the chaser spacecraft to the target in meters.
If I now plot these ranges from the laser range finder together with the positions in the train_labels.csv I find no correlation
From your description:
" x, y, z are the translational components that describe changes in the position of the chaser spacecraft in three dimensions (i.e., forward-backward, left-right, up-down)."
I understand therefore that the x-direction would be the forward-backward direction. This would mean the x component should be strongly correlated to the distance in from the laser range finder.
From the train_labels.csv I would expect the distance between the 2 spacecraft to change considerably within the sequence, however the range of the laser range finder shows very little change, and I cannot see the periodicity from the x,y,z components. I also have problems seeing a considerable change in relative distance of the 2 spacecraft in the images of a sequence as the train_labels suggest.
Am I missing something here?

1 Like

Hi @Shadow43,

The ground truth data is indeed the file named train_labels.csv. There is no output.csv file—that was an old name that we missed updating. Apologies for the confusion. We’ve updated the Problem Description page to fix this.

I will address for other questions in the following order:

  • First, how to understand the translation values
  • Then, what the “random walk” refers to

Translation values

Regarding how to understand the translation values in the ground truth, it’s important to understand this idea:

For each subsequent image, you are to calculate the transformation required to get back to that reference image. That is, for each image supply the transformation - the rotation first, then the translation - we would need to apply to the chaser to get the target spacecraft (treated as stationary) to appear exactly as it does in the reference image.

Because of the formulation, the translation values represent position changes defined in the reference frame of the spacecraft’s initial position and orientation. So, the x value does indeed represent a translation in the forward-backward direction, but along the forward-back axis of the chaser’s initial pose in the reference image. It is not a translation along the forward-back axis of the orientation shown by the i-th image of the chain.

To reiterate more specifically: we define the location of the chaser spacecraft in the initial image at the origin of our reference frame, with the x-axis pointing towards the target spacecraft and the y-axis pointing to the left. Then, continuing to use this reference frame, the (x, y, z) values for the i-th labeled image correspond to the location of the chaser spacecraft in this reference frame.

In the example you plotted, the fact that you see the laser rangefinder showing little change indicates that the chaser spacecraft is moving about the target spacecraft approximately on the surface of a sphere of relatively constant radius (~100 meters) centered on the target spacecraft. It means the chaser spacecraft is always ~100 meters from the point (~100,0,0). You can roughly verify this with a calculation like sqrt((x-100)**2 + y**2 + z**2). Note that this a rough approximation for a few additional reasons: (a) the laser rangefinder measurements have some noise added, and (b) the range is the distance to the surface of the target spacecraft and not the distance to its center.

In fact, the pattern you see in the first half of the trajectory where the x,y,z appear nearly periodic can be understood as the chaser moving in an approximate circle around the target. The first peak in x, which is approximately double the range value, coincides with y and z approximately crossing zero, which can be understood as the chaser being on the opposite side of the circle from where it started.

Random walk

The “random walk” refers to the process that produced the trajectory of the chaser spacecraft. It does not refer to noise in the data. (The laser rangefinder measurements do contain some noise, but the ground truth labels do not.)

To understand this, it may be helpful to consider a counterfactual situation. For example, another possible way to produce a trajectory would be to simulate the motion of both spacecraft subject to forces under the physics of Newton’s Laws of Motion, for example if both spacecraft were orbiting a third body due to that body’s gravity. In such a situation, a physics-based model of Newtonian mechanics and gravity would have significant predictive value for the chaser’s motion by itself without consideration of the images. Because the actual data generation process uses a biased random walk, such a physics-based dynamical model is not applicable.

There is a random walk associated with the distance to the target spacecraft (seen with the changes in the laser rangefinder measurement), as well as a biased random walk associated with how we move around the spacecraft. The distortions in the periodicity of the (x, y, z) components is evidence of this. The particular example you plotted is fairly mild, where there is high bias and relatively low randomness. Other chains can have much less obvious of a periodic component. The purpose of this is to discourage competitors from creating solutions that will try to predict the dynamics of the system / periodicity, and encourage solutions that have no reliance on dynamics.

1 Like

@jayqi thank you for the detailed explanation, that helps a lot

1 Like