Submission Rules

Each mission is described by a stand-alone text file. One file contains one mission. Each file must be submitted separately. Each member of a team is allowed to submit files on behalf of the whole team.

As soon as a file is submitted two steps will happen in our servers: a) preliminary validation and b) scoring step. During the preliminary validation, the submission is considered as a stand-alone mission and only some constraints are thus checked. If a problem arises at this stage an error code and a description of the problem will appear to help the user debug the problem. If the preliminary validation is passed the submitted file will be stored in our servers and appear in the submission list. This does not mean that the submission is valid: problems may arise during the following scoring step as the mission will be tested against all previously submitted missions that were marked as valid (e.g. for repeating debris, mission overlaps, etc..). If some constraint violation is detected during the scoring step , the submission will be marked as invalid and appear in red in the submission list, but no error will be explicitly signaled to the user. A non valid submission has no consequence to the team score.

File format

Each line of the file contains an event which, essentially, correspond to an impulsive \(\Delta V\) manoeuvre. Impulses can be given at arrival or at departure to/from a given debris, as well as in deep space. Each line thus contains the epoch, the spacecraft state, the Cartesian components of the instantaneous velocity increment \(\Delta \mathbf V\) (assumed to be delivered immediately after the event) and the event id (a deep space manoeuvre is denoted by -1, the arrival and departure to/from a specific debris with the debris id).

Valid submissions are available for inspection in the folder submission_examples/ contained in the downloadable data file gtoc9-data.zip . The file example_submission1.txt, as an example, contains a possibly valid mission able to remove the debris with ids 23, 3 and 51. A direct transfer is made between 23 and 3, while one deep space manoeuvre is made between 3 and 51. The file, thus, has the following structure:

$$
\scriptsize \begin{array}{ccccccccccccc} \hline \mbox{line in file} & t [mjd2000]& x [m]& y [m]& z [m]& v_x [m/s]& v_y [m/s]& v_z [m/s]& m [kg]& \Delta V_x [m/s]& \Delta V_{y} [m/s]& \Delta V_{z} [m/s]& \mbox{event id} \\ \hline 0& float,& float,& float,& float,& float,& float,& float,& float,& 0,& 0,& 0, & 23 \\ 1&float, & float,& float,& float,& float,& float,& float,& float,& float,& float,& float,& 23 \\ 2&float, & float,& float,& float,& float,& float,& float,& float,& float,& float,& float,& 3 \\ 3&float, & float,& float,& float,& float,& float,& float,& float,& float,& float,& float,& 3 \\ 4&float, & float,& float,& float,& float,& float,& float,& float,& float,& float,& float,& -1 \\ 5&float, & float,& float,& float,& float,& float,& float,& float,& float,& float,& float,& 51 \\ 6&float, & float,& float,& float,& float,& float,& float,& float,& 0,& 0,& 0,& 51 \\ \hline \end{array} $$

Preliminary validation

Each file submitted will be validated and scored automatically. A number of validation checks will be made as soon as the file is received, if any fails a the following error codes will be returned:

• 1 - The file size is checked. If exceeding 1MB the submission will be marked as invalid.
• 2 - The file structure is checked. If not a csv file containing 12 values per line, the submission will be marked as invalid.
• 3 - The number of lines is checked. If exceeding 856 or less than 2 the submission will be marked as invalid.

Let us indicate the file content using, as a subscript, the file line so that, for example, \(t_3\) denotes the value of the epoch in the fourth line (the first line has subscript \(0\), the last \(f\)). We also indicate with \(\mathbf r_{\mathcal D_k}(t), \mathbf v_{\mathcal D_k}(t)\) the position and velocity of the debris with \(id=k\) at the epoch \(t\). Finally we use \(\mathbf r_{i} = [x_i, y_i, z_i]\), \(\mathbf v_{i} = [v_{x_i}, v_{y_i}, v_{z_i}]\) to indicate the position and velocity as read from the file at line \(i\) and \(\Delta\mathbf V_i = [\Delta V_{x_i}, \Delta V_{y_i}, \Delta V_{z_i}]\) to indicate the velocity increment vector as read from the file at line \(i\) . Using these conventions, the following further checks will be made, if any fails the submission will be marked as invalid:

• 4 - The event ids are checked: \(-1 \le id_i \le 122\), \(\forall i\)
• 5 - The pericenter is checked: \(a_i(1-e_i) > 6600000\), \(\forall i\), where \(a_i\) and \(e_i\) are the osculating orbital elements computed from \(\mathbf r_i\) and \(\mathbf v_i\).
• 6 - The initial mass is checked: \(m_0 \ge 2030\). The embarked propellant mass is checked \(m_p = m_0 - m_{dry} - 30N\le 5000\) (\(N\) is here assumed to be equal to the number of different debris visited). The final mass is checked: \(m_f \ge 2000\).
• 7 - The epochs are checked (monotonically increasing): \(t_j > t_i\), \(\forall i\), \(\forall j > i\).
• 8 - The initial and final velocity increments are checked: \(|\Delta\mathbf V_0| = |\Delta\mathbf V_f| = 0\).
• 9 - The first and last two events id are checked to be an arrival and a departure to/from the same debris: \(id_0 = id_1 \ne -1\) and \(id_f = id_{f-1} \ne -1\)
• 10 - The event sequence is checked: if \(id_i \ne -1\) then either \(id_{i-1}=id_i\) or \(id_{i+1}=id_i\) \(\forall i \in [2, ..., f-2]\).
• 11 - The event sequence is checked: exactly two events (arrival and departure) must be associated to each \(id \ne -1\)
• 12 - For all arrival events, the rendezvous conditions are checked as: \(|\mathbf r_i - \mathbf r_{\mathcal D_i} (t_i)| < \epsilon_r\), \(|\mathbf v_i - \mathbf v_{\mathcal D_i} (t_i) + \Delta \mathbf V_i| < \epsilon_v\)
• 13 - For all deep space manoeuvre events and arrival events (except the first), the mass update is checked as \(\left|m_i - m_{i-1} \exp\left(-\frac{|\Delta \mathbf V_{i-1}|}{v_{e}}\right)\right| \le \epsilon_m\).
• 14 - For all arrival events, the waiting time constraint is checked as \(t_{i+1} - t_{i} \ge 5\)
• 15 - For all arrival events, except the first one, the time elapsed since the previous debris rendezvous is checked: \(t_i - t_{j} \le 30\), where \(j\) is the line corresponding to the previous arrival event.
• 16 - For all departure events, the rendezvous conditions are checked as: \(|\mathbf r_i - \mathbf r_{\mathcal D_i} (t_i)| < \epsilon_r\), \(|\mathbf v_i - \mathbf v_{\mathcal D_i} (t_i)| < \epsilon_v\)
• 17 - For all departure events the mass update is checked as \(\left|m_i - m_{i-1} \exp\left(-\frac{|\Delta \mathbf V_{i-1}|}{v_{e}}\right) + 30\right| \le \epsilon_m\). (delivery of the de-orbit package is included as well as the mass loss from the \(\Delta V\))
• 18 - For all deep space manoeuvre events and arrival events (except the first) the spacecraft state \(\mathbf r\), \(\mathbf v\) is first computed numerically integrating the equation of motion from initial conditions \(\mathbf r_{i-1}\) and \(\mathbf v_{i-1}\) for a time of \(T = t_i - t_{i-1}\) [days] and then checked as \(|\mathbf r - \mathbf r_i| < \epsilon_r\) and \(|\mathbf v - \mathbf v_i| < \epsilon_v\).
• 19 - All epochs must be in the allowed window. \(t_i \ge 23467\), \(t_i \le 26419\), \(\forall i\).

Scoring

If the file passes the validation step, a scoring step is applied. During this process the submitted file can still be detected as invalid w.r.t. to the previously submitted files as some operational constraints will be now checked (e.g. debris visited only once). In case any is violated the submission will be considered invalid and not scored.

Otherwise the score \(J\) of the team will be updated on the leaderboard as well as the number of debris removed so far.

Testing for preliminary validation

To help the teams figure out the correct file format to submit, any submission with filename containing the string TRIAL will be ignored after the preliminary validation step. Try, for example, to submit the file TRIAL-my_mission.txt which contains a mission that passes the preliminary validation. Then try to submit the same file, changing some numbers it contains.

Undoing submissions

Submissions can be withdrawn by the team, but only in reverse submission order. This may be useful in cases where a mission was submitted early in the competition timeline in the hope to exploit a favorable price, but later the team has found that the submitted mission is no longer of use. To withdraw the last valid submission, (and thus revert to the previous valid one) any team member may submit a dummy file that passes the preliminary validation (e.g. example_submission1.txt) and put in the title field of the submission page the text [delete last valid]. The result of this action will be to mark as invalid the last valid submission. The dummy file will also appear as a dummy invalid submission.

By issuing this command repeatedly all submissions can be undone.