---
# System prepended metadata

title: 5/6/2021 Tudat Estimation Meeting

---

# 5/6/2021 Tudat Estimation Meeting 


## Agenda 📋

- 


## Minutes 🕙

- perfect opportunity to refactor the estimation interfaces (currently really messy)
- Issues with how link ends & observations are declared.
- need to define a clear road map to refactor the above (quite invasive modifications!)

- Link ends:
    - interface for the user is currently "not ideal" (already better in Python, can still be shorter)
    - suggestion (Dominic): add some utility functions to create the link ends "automatically" (see slide 7). no need to specify linkEndTypes anymore (done automatically within those utility functions)
    - (Joao) keep the old version as an ption (possible to define linkEnds manually and not via utility functions)
    - include some kind of ground stations database. suggestion (Dominic): make each ground station knows what type of observation it can collect (e.g. DSN would not perform any optical observations). Make it easy to modify so that each user can add an extra GS. maybe use a json file for this (even if some people would be deeply hurt by this ;) 
    - Add reference points on spacecraft. more flexible way to specify those reference points and include time-flexibility (e.g. moving antenna in the body-fixed frame, so on top of the attitude model basically)

- Observation settings:
    - link ends are not yet included in the observation settings. suggestion (Dominic): add this to the observation settings. could be renamed to ObservationModelSettings
    - Observation simulation input is extremely cumbersome (and painful!) now (type of the observable, link ends, list of times, reference link end).
    - Suggestion: class ObservationSimulationSettings that would take care of the above (which defines the observation settings for several observations)
    - (Marie) create object ObservationSimulationSettings from ObservationModelSettings + list of observation times
    - add noise / viability calculators as inputs to ObservationModelSettings
    - to specify when observations should be simulated: create dedicated class with a very generic base class taking baseTimeLists as input (working in a very similar way as current version)

    - Observation simulation output: create a new class Observable
    - downside: each observation needs its own separate object - memory issue
        Suggestions: avoid storing linkEnds directly by mapping them
                     keep current map structure but add top-level class that manages it for the user and return Observable objects
                     Observable object could store all observations with same link ends / observable type (so vector of observations instead of single observation value)
                     Observable object should have pointers to - common metadata
                                                               - not common metadata
                    

## Action Items ✔️

- Geoffrey: Add details/ workflow/ tools on preliminary visual API design in developer documentation.
- Marie: Detailed flowchart for observations simulation: baseTimeLists / viability calculators. 
- Joao: Make a preliminary list of the different types/formats of metadata we might need to include 📡
- Dominic: take lead on making most of the modifications
- Michael: testing new functionalities (within MSc thesis scope)


## Parking Lot 🚗

- 