org.orekit.estimation包提供了管理轨道确定的类。
Orekit中的轨道确定支持类似于其他空间飞行动力学主题的支持：该库提供了顶层接口和经典实现（例如距离和角度测量等）。还提供了一些钩子，供需要使用任务特定功能和实现（例如特定延迟模型）的专家用户补充框架。提供的对象足以进行经典轨道确定，并且可以轻松扩展以满足更多操作需求。
有四个主要的子包：org.orekit.estimation.measurements，org.orekit.estimation.leastsquares，org.orekit.estimation.sequential和org.orekit.estimation.iod。
measurements包定义了与测量本身相关的所有内容，包括理论值和可以应用于它们的修改。所有测量都必须实现ObservedMeasurement接口，这是引擎用来处理所有测量的公共API。该接口的最重要的方法允许：
估计的测量可以通过注册一个或多个EstimationModifier对象进行修改。这些对象将管理诸如电离层或对流层延迟、偏差、地面天线位置偏移、天线相位中心等概念。一个特定的修饰器OutlierFilter可以在运行时拒绝异常值，如果当前残差超过了理论标准差的某个用户定义因子。
来自地面站网络的典型操作案例将创建距离和角度测量，为距离测量创建一个偏差修饰器，为每个地面站创建几个修饰器（位置偏移、延迟），为对流层和电离层延迟创建修饰器，并将它们添加到相应的测量中（即所有距离测量将共享同一个航天器上的延迟对象，但由两个不同地面站执行的距离测量将引用不同的地面站位置偏移集合，例如）。
Orekit已经在同一个包中提供了经典的测量和修饰器，但是对于更高级的需求，用户需要添加自己的实现。这确保了该设计的可扩展性。
measurements.generation包提供了一个可以生成真实测量的模拟功能。这在验证阶段和任务分析（例如地面站网络设计或任务可达精度评估）中非常有用。
对于每种需要生成的测量类型，都会配置一个Scheduler以匹配任务或地面段特定的测量计划，并包括一个考虑到的测量类型的MeasurementBuilder。一个特别重要的预定义调度器是EventBaseScheduler。该调度器使用常规事件检测器来识别测量可行性时间段。与此调度器一起使用的一些可能有用的事件检测器有地面可见性（ElevationDetector），夜间地面（GrondAtNightDetector）用于卫星激光测距，太阳照射的卫星（EclipseDetector）用于光学跟踪，卫星间直接视图（InterSatDirectViewDetector）用于GNSS，以及多个检测器的布尔组合（BooleanDetector）用于复杂设置。这个调度器以及更简单的ContinuousScheduler都依赖于DatesSelector来在时间范围内选择单个测量日期。 FixedStepSelector生成一个连续的测量流，每个测量之间间隔固定的步长（例如在允许的时间范围内每60秒进行一次测量），而BurstSelector生成高速测量的突发，每个突发包含256个测量，每个测量之间间隔100毫秒，每300秒生成一个新的突发。这两个选择器都可以确保日期与时间刻度对齐（例如在前面的示例中，每个突发中的第一个测量在精确的UTC分钟5、10、15...）。
如果可用的测量类型不同（范围、范围速率、星空背景上的光学跟踪...）或者使用了几个独立的计划（例如如果有几个地面站可用），则可以同时配置多个调度器。所有调度器都注册到一个单一的Generator，当运行时，它将在指定的时间范围内生成模拟测量。
为了在生成测量时即时处理它们，用户可以使用GeneratedMeasurementSubscriber的自定义实现。这在需要生成大量测量时非常有用，因为将所有内容存储在内存中是不切实际的。另一方面，如果测量数量保持有限（几百或几千个），则可以使用GatheringSubscriber实现，它将所有内容存储在一个排序集合中，可以在生成后检索。在这两种情况下（即时处理或检索SortedSet），测量结果根据调用Generator.generate时使用的startDate和endDate参数按时间顺序或逆时间顺序排序。
leastsquares包提供了一个批量最小二乘估计器引擎的实现，用于执行轨道确定。用户通常会创建一个该对象的实例，将所有观测数据注册为带有其包含的修饰符的测量，并运行最小二乘滤波器。在过程结束时，将返回一个完全配置的传播器，其中包括估计的轨道作为初始状态和估计的传播器参数。也可以单独检索估计的测量和传播器参数。
BatchLSEstimator类创建了一个内部实现Hipparchus LeastSquaresProblem接口的对象，用于表示轨道确定问题，并将其传递给LeastSquaresOptimizer实现之一来解决它。有几种选择，其中包括LevenbergMarquardtOptimizer和GaussNewtonOptimizer。前者被认为更健壮，并且可以从比后者更远的初始猜测开始。如果仍然选择GaussNewtonOptimizer，则应配置为使用QR分解而不是LU分解，以增加在可观测性差的情况下的稳定性。在解决过程中，所选的Hipparchus算法将在每个算法测试点调用本地LeastSquaresProblem模型的evaluate方法。这将触发使用轨道状态和参数（例如来自测量修饰器参数的偏差或来自力模型参数的阻力系数）的一些测试值进行轨道传播。在传播过程中，Orekit步处理机制用于在测量日期收集状态及其雅可比矩阵。一个MeasurementHandler类执行通用步处理机制与轨道确定框架之间的绑定。在每个测量日期，它从传播器侧获取状态和雅可比矩阵，调用测量方法获取残差和测量侧的偏导数，并获取带有组合值的最小二乘估计器，以提供给Hipparchus最小二乘求解器，从而闭合循环。
SequentialBatchLSEstimator类创建了一个基于现有最小二乘结果（即状态和协方差）的顺序批量最小二乘估计器引擎的实现，用于执行轨道确定。当已经估计了一个轨道，并给出了新的测量时，重新优化整个问题是不高效的。仅考虑新的测量而进行优化也不会得到好的结果，因为旧的测量不会被考虑在内。因此，使用顺序估计器来估计轨道，它使用估计的旧结果和新的测量。当运营商希望使用前一天执行的轨道确定的估计协方差和状态向量来改进每日轨道确定的结果时，也可以使用SequentialBatchLSEstimator类。
Orekit中的两个批量最小二乘估计器实现与NumericalPropagator、DSSTPropagator、TLEPropagator、EcksteinHechlerPropagator、BrouwerLyddanePropagator或KeplerianPropagator兼容。
sequential包提供了一个卡尔曼估计器引擎的实现，用于执行轨道确定。用户通常会创建一个此对象的实例（使用构建器），并逐个测量地输入滤波器，每次都会得到一个校正后的状态。
与批量最小二乘估计器的一个重要区别是，卡尔曼滤波器需要一个初始协方差矩阵（可以从先前的轨道确定计算得出，可能是从批量最小二乘法得出的第一个估计）和一个过程噪声矩阵，它表示由传播本身引起的预期噪声在先前测量和当前测量之间。
在简单的情况下，或者如果用户不知道该使用什么，Orekit中提供了一个简单的提供者，它只使用常数矩阵。然而，对于过程噪声来说，这并不适用，因为它取决于先前和当前状态以及它们之间的时间间隔。如果两个测量之间只相隔几秒钟，那么估计步骤引入的噪声应该远小于在几小时之间的测量步骤引入的噪声。
预计库中将包含一个简化模型，该模型通过在沿轨道、横轨道和法向方向上扩展一个具有多项式长度的误差椭球，并使用多项式的正确系数。找到多项式的正确系数的方法仍然由用户负责。为了为一组轨道正确调整它，可以在任务分析阶段使用Taylor代数的第一次运行来监测高阶不确定性的演变，并在此演变上拟合一个椭球。然后，使用具有此多项式椭球模型的协方差矩阵提供者的卡尔曼滤波器将比基本常数矩阵更加逼真。
为了获得更准确的表示，用户可以自由设置自己的模型，这可以涵盖评估每个力模型的效果。这是通过提供CovarianceMatrixProvider的自定义实现来完成的。
由于DSST轨道推算器使用大步长来执行平均赤道元素的运动方程的数值积分（例如，GEO卫星的半天），因此它不适用于经典的扩展卡尔曼滤波器轨道确定。经典的卡尔曼滤波器算法需要在每个观测时刻重新初始化轨道状态。然而，两个观测之间的时间差通常远小于DSST步长。为了在递归滤波器轨道确定中利用DSST理论，Orekit实现了扩展半解析卡尔曼滤波器。
还可以使用无香卡尔曼滤波器进行轨道确定。当误差分布为非高斯分布时，无香卡尔曼滤波器应该能够生成更好的状态误差和测量误差分布函数描述。它使用一组样本点，也称为sigma点，来表示状态的不确定性分布。因此，无香卡尔曼滤波器是解决非线性系统的一种有趣算法。
与扩展卡尔曼滤波器一样，Orekit实现了无香卡尔曼滤波器的半解析版本，称为无香卡尔曼滤波器。
用户可以决定他们想要估计的参数。通常情况下，6个轨道参数始终被估计，并且默认情况下被选中，但也可以固定其中一些或全部参数。用户还可以估计一些传播器参数（如阻力系数或辐射压力系数）和测量参数（如偏差、站点位置偏移或地球定向参数）。只估计轨道参数的子集的一个用例是当观测数据非常稀缺时（比如对新发现的碎片或小行星的前几次测量）。根本不估计任何轨道参数的一个用例是从被认为是完美的参考轨道校准测量偏差。选择应该估计哪些参数和哪些参数应该保持固定是通过ParameterDriver类来完成的。在设置过程中，用户可以从BatchLSEstimator中检索到三个不同的ParametersDriversList：
然后，循环遍历这些列表的元素，用户可以根据自己的需求更改默认设置，例如固定一些轨道参数，同时估计一些传播和测量参数。
自Orekit 11.3版本以来，可以进行基于星历的估计。基于星历的估计的目的是仅估计测量参数，而不估计动力学参数（即轨道和传播器参数）。一个典型的应用是使用分析中心计算的精确GNSS星历来校准望远镜时钟偏差。
要执行基于星历的估计，用户必须向估计器提供包含星历的EphemerisPropagatorBuilder。Orekit会自动禁用动力学参数的估计。
一切准备就绪后，调用BatchLSEstimator的estimate方法。最小二乘求解器将修改被标记为选定的参数的值（因此应该被估计）。估计器不知道任何参数的含义，对于它来说，它们都是一样的。在底层，每个参数实际上是由一个对象创建的，该对象知道参数的含义，例如参与阻力计算的对象。该对象使用观察者设计模式来监视优化算法尝试的每个更改，并根据最后一次更改来调整其计算。这种设计改进了批量最小二乘估计管理的上层与力模型或偏差所属的下层之间的解耦。因此，它允许用户在创建特定的力模型、特定的测量或特定的测量修正器时添加自己的参数。他们只需要提供一些ParameterDriver实例，并实现ParameterObserver接口以监视估计器何时更改这些新参数。
上面的类图描述了地面站位置偏移的参数更新机制。Range和RangeRate测量类引用一个GroundStation实例（所有使用该站的测量共享一个实例），该实例向上层提供代表东、北和天顶偏移的3个参数。如果某个地面站位置偏移被标记为要估计的，BatchLSEstimator将在每次新评估时更改其值，而不知道这个变化在底层实际上涉及什么。随着参数值的变化，地面站将通过其注册到参数的ParameterObserver被通知变化，并根据更新的偏移移动其关联的TopocentricFrame。因此，将自然地使用更新的站点位置计算Range和RangeRate测量的理论值。轨道参数、传播参数和测量参数都以相同的方式处理。
参数归一化用于向最小二乘算法提供一个更平衡的向量。如果不进行归一化，与半长轴对应的向量分量的数量级可能达到几百万，而与离心率对应的向量分量的数量级可能小10个数量级（假设用户决定在开普勒参数集中估计轨道）。如果估计了中心引力系数，最大和最小分量之间的差异甚至可能达到20个数量级。最小二乘优化器无法正确处理这样的向量。为了解决这个问题，数学最小二乘算法只看到参数的归一化值，而物理模型看到的是相同参数的实际值。归一化值的计算公式始终为：
normalized = (physical - reference) / scale
参考值和比例尺是固定的。比例尺与围绕参考值的预期偏差有关，这在典型问题中是可以预期的。精确计算比例尺并不重要，因为目标只是避免数量级巨大的差异。只要比例尺允许归一化值在1/1000和1000之间，就足够好。因此，比例尺对于每个参数都是硬编码的。为了增加数值稳定性，硬编码的值是2的幂次方，因此在归一化值和物理值之间进行转换时，乘法和除法的序列不会引入计算误差。例如，阻力系数的比例因子被设置为2⁻³，而中心引力系数的比例因子被设置为2⁺³²。
某些参数值是禁止的，最小二乘估计器不应使用它们。不幸的是，截至2017年中期，Hipparchus库不支持这些算法的简单边界约束。然而，可以通过参数验证器来解决这个问题。Orekit使用这个解决方法，并为完整的参数集设置了一个验证器。该验证器检查最小二乘求解器提供的测试值是否在参数边界内，如果不在，则将其强制限制在边界上，从而将值截断。与比例因子一样，最小和最大边界目前在库中是硬编码的。这些限制已经设置为相当宽松的值，因为它们只是为了防止计算失败（如负离心率或半长轴）。如果最小二乘算法尝试这样极端的值，那么可能是测量值或传播器配置存在问题。