| Interface | Description |
|---|---|
| PositionAngleBased |
该接口表示基于所谓的位置角定义的轨道样式轨迹。
|
| Class | Description |
|---|---|
| AbstractFieldOrbitInterpolator<KK extends org.hipparchus.CalculusFieldElement<KK>> |
轨道插值器的抽象类。
|
| AbstractOrbitInterpolator |
轨道插值器的抽象类。
|
| CartesianOrbit |
该类保存笛卡尔轨道参数。
|
| CircularOrbit |
该类处理圆形轨道参数。
|
| CR3BPDifferentialCorrection |
为Halo或Lyapunov轨道实现微分校正方法的类。
|
| EquinoctialOrbit |
该类处理赤道轨道参数，可以支持圆形和赤道轨道。
|
| FieldCartesianOrbit<T extends org.hipparchus.CalculusFieldElement<T>> |
该类保存笛卡尔轨道参数。
|
| FieldCircularOrbit<T extends org.hipparchus.CalculusFieldElement<T>> |
该类处理圆形轨道参数。
|
| FieldEquinoctialOrbit<T extends org.hipparchus.CalculusFieldElement<T>> |
该类处理赤道轨道参数，可以支持圆形和赤道轨道。
|
| FieldKeplerianAnomalyUtility |
用于在不同Kepler异常之间转换的实用方法。
|
| FieldKeplerianOrbit<T extends org.hipparchus.CalculusFieldElement<T>> |
该类处理传统的Kepler轨道参数。
|
| FieldOrbit<T extends org.hipparchus.CalculusFieldElement<T>> |
该类处理轨道参数。
|
| FieldOrbitBlender<KK extends org.hipparchus.CalculusFieldElement<KK>> |
轨道混合器。
|
| FieldOrbitHermiteInterpolator<KK extends org.hipparchus.CalculusFieldElement<KK>> |
使用Hermite插值器插值轨道的类。
|
| HaloOrbit |
计算Halo轨道的不同参数的类。
|
| KeplerianAnomalyUtility |
用于在不同Kepler异常之间转换的实用方法。
|
| KeplerianOrbit |
该类处理传统的Kepler轨道参数。
|
| LibrationOrbit |
libration轨道的基类。
|
| LyapunovOrbit |
计算Lyapunov轨道的不同参数的类。
|
| Orbit |
该类处理轨道参数。
|
| OrbitBlender |
轨道混合器。
|
| OrbitHermiteInterpolator |
使用Hermite插值器插值轨道的类。
|
| RichardsonExpansion |
实现第三阶Richardson展开的类。
|
| Enum | Description |
|---|---|
| LibrationOrbitFamily |
Libration Orbit系列的枚举。
|
| LibrationOrbitType |
Libration Orbit类型的枚举。
|
| OrbitType |
Orbit和FieldOrbit参数类型的枚举。
|
| PositionAngleType |
真、偏心和平均位置角的枚举。
|
它构建了所有其他空间力学工具的基础。它提供了一个抽象类Orbit，以四种不同方式扩展，对应于轨道参数的不同可能表示。截至版本3.0，支持Keplerian、圆形、赤道和笛卡尔表示。
轨道包的早期设计比当前设计复杂得多。回顾这些设计，它们试图在单个类中做太多的事情，导致庞大的系统，难以理解、难以使用、难以维护和难以重用。它们混合了几个不同的概念：
它们也经常忽略了所有的参考框问题。
当前设计是通过逐渐删除多余的层并将它们放在专用包中达到的。现在所有这些概念仍然被处理，但都在不同的类中，这些类之间有清晰的链接。毫不知情地，我们遵循了安托万·德·圣埃克苏佩里的说法：
完美似乎不是指没有可以添加的东西，而是指没有可以拿走的东西。
当前设计当然不是完美的，但易于理解、易于使用、易于维护和可重用。
从早期设计中，各种轨道类仅保留了单个时间点的运动概念。它们基本上代表当前状态，并用作数据持有者。这些轨道类提供的大多数方法都是getter。其中一些（非模棱两可的方法，必须始终可用）在顶层Orbit抽象类中定义（Orbit.getA()、Orbit.getDate()、Orbit.getPVCoordinates() ...）。根据表示类型的特定方法仅在相应类中定义（例如，CircularOrbit.getCircularEx()）。
重要的是要注意，即使某些参数与表示不符，它们仍然可用。例如，即使在笛卡尔表示中，半长轴也是可用的，而位置/速度即使在非笛卡尔表示中也是可用的。这是一种务实的选择。这些参数在许多算法中真正被使用，用于与周期相关的计算（设置收敛阈值或搜索间隔）或几何（计算扫描带或照明）。这种选择的一个副作用是，所有轨道都包括一个μ值，即中心天体的加速系数。这个值仅用于参数的表示和转换目的，它并不总是与用于传播的值相同（但当然，使用不同的值应该谨慎进行）。
轨道还包括对定义框的引用。这允许在不必外部保留轨道及其框之间的映射的情况下透明地转换到其他框：这已经完成。例如，获取由地面站框架中的圆形轨道给出的卫星的位置和速度只是简单地调用orbit.getPVCoordinates(stationFrame)，无论轨道定义在哪个框架中（GCRF、EME2000等）。
由于轨道在空间动力学应用程序中随处可见，并且我们选择将其限制为简单的状态持有者，因此所有轨道类都保证是不可变的。它们是小对象，并且被许多部分共享。这一变化是在2006年进行的，极大地简化了库和用户应用程序，以前不得不复制轨道作为防御性编程的应用，并且在忘记复制时受到困扰时，这些应用程序充斥着难以找到的错误。
对于轨道演化计算，该包是不够的。需要包括动力学概念、力模型、传播算法等。这方面的入口点是Propagator接口。
所有表示都可以转换为所有其他表示。如果某些转换是模棱两可的（例如将完全圆形轨道从笛卡尔表示转换为Kepler表示，对近地点参数存在歧义），则不会触发错误。这种设计选择是许多不同尝试和务实考虑的结果。理由是从物理角度来看，没有奇点。奇点只是由表示的选择引入的。即使考虑到这一点，似乎与其有一个没有现实值的参数，不如有一个无限可能的值，所有这些值都代表相同的物理轨道。Orekit只是做了一个任意选择，通常简单地选择值0。在我们的示例中，我们将得到一个带有0近地点参数的转换轨道。这个选择是有效的，就像任何其他选择（π/2、π等...）一样有效，因为它确实正确地表示了轨道，并且当转换回原始的非模棱两可表示时，它确实给出了正确的结果。
因此，我们认为用户有责任了解不同表示的正确定义以及与每种表示相关的奇点。如果用户确实需要进行一些转换（例如为了稍后将轨道提供为两行元素，记住TLE确实使用类似Kepler的参数），那么他可以这样做。
OREKIT中处理转换的方式非常简单，允许轻松和透明地处理。所有四种参数类型都扩展自抽象类Orbit，每个传播算法，无论是分析的还是数值的，都使用这个抽象类作为参数，即使在内部它依赖于特定表示。例如，Eckstein-Hechler propagator仅以圆形轨道定义。因此，在传播器初始化时会隐式进行转换。
Copyright © 2002-2023 CS GROUP. All rights reserved.