Truth Data Issue

I’m seeing 7 different cases in the phase_1_v2 truth data where an object starts with NS SS node NK and then the only other node is an ID. My understanding is that an ID node should only follow a period of station-keeping, so there appear to be missing IK nodes. The objects are 1012, 1383, 1385, 1386, 1471, 1473, and 1474. I’m assuming you would want issues like this to be reported since one of the objectives is to create a useful dataset for ongoing work.

Regards,
Jeff

Thank you for bringing this to our attention. I believe this stems from a glitch in our data formatting scripts since our original data files do include NS IK nodes for those objects. We’ll fix this and update the affected files shortly.

1 Like

On a similar note, I have noticed that some Objects (namely [221:250]) have their True Anomaly and Longitude values in different value ranges than the other Objects ([-180,180] instead of [0,360] & vice versa). Right now I am checking for this when loading the data, but it would probably make sense if this was unified (in the online test set as well)

Any updates on these fixes? I believe the problem may be more widespread.

Another truth case to look at: object 30 has only node 0 as NK NS but is clearly stationkeeping NS throughout the study period.

Regards,
Jeff

Adding another truth error: object 100 has NS SS node with type CK, but there are no NS SK maneuvers in the data. It’s drifting the entire study period.

Hi @beckja,

Thank you for bringing this to our attention. We released a fix on March 2nd and sent out an email the same day to inform participants of the fixes. Here is a snippet from the email:

Please note that we have made updates to the training dataset and you can access the updated dataset under the ‘phase_1_v3’ folder here. There were glitches in our data formatting scripts that caused missing IK nodes for objects 1012, 1383, 1385, 1386, 1471, 1473, and 1474, incorrect variable bounds for the true anomaly and longitude for objects 221-250, and an error in the training label for object 100.

We will investigate object 30 and provide an update shortly.

Best,
Peng

1 Like

Thanks for following up and my apologies for missing the prior email notice.

Regards,
Jeff

Found another one: object 113 is another case where the NS nodes contain only NK at 0 but the object is clearly NS station-keeping throughout the study period.

Regards,
Jeff

1 Like

Also, Objects 1385 and 1383 look like the nodes are positioned too early, esp. when plotting the eccentricity/longitude together with the labels.

1 Like

@beckja Thank you for bringing this to our attention! We will update object 113 with the correct label as soon as possible.

@DavidB Thank you for bringing this to our attention! 1383 and 1385 appear to have been assigned labels belonging to the wrong file, so you are right that the nodes do not match the behaviors. We will ensure that the proper labels are added in our next update.

Thank you! Will you take a look if this is an issue in more objects? I don’t have the time right now to check, but given that I found these 2 relatively coincidentally I would suspect so.
Best
David

Edit: Object 1474 also seems a bit off

Agreed on 1474: the EW ID node should be the IK node.

Update: it’s not that simple. These nodes are just wrong. The AD/IK pair should slide to about 1471 and there is no ID.

It appears that the issues stem from the recently updated labels in phase_1_v3, where we updated the labels for objects: 1012, 1383, 1385, 1386, 1471, 1473, and 1474. We are currently examining our data to ensure that the issue is isolated to these objects.

1 Like

You may also want to look at object 10. The NS IK node appears to be too early.

Update: Objects 9, 10, 13, and 19 all have incorrect NS IK nodes that are too early.