# Nanosatellite Autonomous Navigation via Extreme Learning Machine Using Magnetometer Measurements
## 7 Conclusions and Future Works  
This work proposes an algorithm combining a magnetometer-based EKF with an ELM-trained SLFN to improve the accuracy of the EKF state estimate during GPS outages. A GPS-based EKF is used to provide ground truth values for the SLFN when GPS data are available, while the magnetometer-based EKF state estimate is used as the input of the SLFN. During GPS outages, the output of the SLFN is used to perform navigation. Magnetometer measurements are simulated using the CHAOS-7 geomagnetic field model. The SLFN was trained on GPS data with a five day-long availability window and tested on the following 51 days of GPS absence. Results for a simulated Sun-synchronous orbit showed an improvement of a factor of 2.4 in the spacecraft's state estimate after the application of the SLFN, with the mean RSSE error decreasing from 16.51 km to 6.90 km for the position and from \(2.07\times 10^{-2}\) km/s to \(8.76\times 10^{-3}\) km/s for the velocity. Future steps in this direction involve the feasibility study of a direct onboard application of the presented algorithm. The main aspect to be considered is the memory required to store the training data that can exceed the capabilities small satellites. For this purpose, many subsequent trainings with small batches of data can be performed instead of a single, more demanding tuning of the output weights at the end of the GPS availability window. The Online Sequential Extreme Learning Machine (OS-ELM) [26; 27] is a variant of the ELM specifically designed to update the output weights when a new batch of data is available in a sequential fashion. By performing so, the information relative to the previous batches can be deleted once the data are processed, significantly easing the computational stress on the algorithm. However, the optimal dimension of the batch must be determined empirically and meet the requirements in terms of both accuracy and computational burden. This issue can be tackled if the communication between the satellite and the ground station is available. The necessary data can be, in fact, transmitted to the ground station with a fixed frequency and \begin{table}
\begin{tabular}{l c c c c} \hline \hline
**Satellite** & **Inclination** & **Altitude** & **Avg. Position RSSE** & **Avg. Velocity RSSE** \\ \hline RXTE & 23\({}^{\circ}\) & 580 km & 15 km & 15 m/s \\ ERBS & 57\({}^{\circ}\) & 614 km & 25 km & 30 m/s \\ CGRO & 28.5\({}^{\circ}\) & 340 km & 20 km & 20 m/s \\ TOMS & 97\({}^{\circ}\) & 483 km & 20 km & 25 m/s \\
**EKF (this work)** & **96.6\({}^{\circ}\)** & **567 km** & **17 km** & **21 m/s** \\
**SLFN (this work)** & **96.6\({}^{\circ}\)** & **567 km** & **6.90 km** & **8.76 m/s** \\ \hline \hline \end{tabular}
\end{table} 
Table 6: A comparison of the results between the EKF and SLFN in this work and the four case studies in [25] relative to the RXTE, ERBS, CGRO, and TOMS satellites. then deleted from the satellite. The training of the network can be performed offline and the weights can be transmitted back to the satellite to be used if needed. Finally, this procedure permits the sequential updating of the weights if more GPS and EKF data are available, which could eventually solve the issue of a prediction losing precision and stability over time as a consequence of a single training performed on a small percentage of data at the beginning of the run. Another aspect to be taken into consideration is the required level of precision in the state estimate. Despite the improvement, the prediction may not be accurate enough for the requirements of the mission. This is mainly due to the baseline provided by the EKF estimate that has a mean RSSE of approximately 17 km and 21 m/s. A better baseline can be achieved by improving the geomagnetic model embedded in the EKF or, vice versa, simplifying the model used to simulate the magnetometer measurements. However, the former would inevitably increase the computational effort of the algorithm while the latter would not represent a realistic application in a real case.