轨道

设计历史

早期的轨道包设计比当前的设计复杂得多。回顾这些设计，它们试图在一个类中做太多的事情，导致了庞大的系统，难以理解、难以使用、难以维护和难以重用。它们混合了几个不同的概念：

• 表示（开普勒、笛卡尔等）
• 运动学（参数）和动力学（传播）
• 物理模型（完整或简化的力模型，通常是隐含的，没有真正的参考）
• 滤波（瞬时和中心或平均参数，与某些模型相关）

它们也经常忽略了所有的参考系问题。

当前的设计是通过逐步删除多余的层并将它们放在专用的包中来实现的。所有这些概念现在仍然被处理，但是都在不同的类中，这些类之间有清晰的链接。不知不觉中，我们遵循了安托万·德·圣·埃克苏佩里的说法：

看起来完美不是在没有东西可添加时达到的，而是在没有东西可拿走时达到的。

当前的设计当然不是完美的，但是它易于理解、易于使用、易于维护和可重用。

当前状态与演化状态

从早期的设计开始，各种轨道类仅保留了单个时间点上的运动概念。它们基本上代表当前状态，并用作数据持有者。这些轨道类提供的大多数方法都是获取器。其中一些（非模糊的必须始终可用的方法）在顶级轨道抽象类（Orbit.getA()，Orbit.getDate()，Orbit.getPVCoordinates()）中定义。根据表示类型的不同，更具体的方法仅在相应的类中定义（例如，CircularOrbit.getCircularEx()）。

需要注意的是，即使这些参数与表示方式不符，某些参数仍然可用。例如，即使在笛卡尔表示中，也可以获得半长轴，而在非笛卡尔表示中，也可以获得位置/速度。这是一种实用主义的选择。这些参数在算法的许多地方真正被使用，用于与周期相关的计算（设置收敛阈值或搜索区间）或几何计算（计算幅宽或照明）。这种选择的一个副作用是，所有轨道都包含一个µ值，即中心天体的加速系数。该值仅用于参数的表示和转换目的，它并不总是与传播中使用的值相同（但是当然，使用不同的值应该小心处理）。

轨道还包括对日期和定义框架的引用。只能使用伪惯性框架来定义轨道，因为牛顿力学应该适用于框架的上下文中。包含框架允许在给定日期时透明地转换到任何其他框架，而无需外部保留轨道与其框架之间的映射：这已经完成了。例如，获取在地面站框架中给定的圆形轨道表示的卫星的位置和速度只需调用orbit.getPVCoordinates(stationFrame)，而不管轨道定义的伪惯性框架是什么（EME2000，GCRF等）。

由于轨道在空间动力学应用中无处不在，并且我们选择将其限制为简单的状态持有者，因此所有轨道类都保证是不可变的。它们是小对象，并且被许多部分共享。这个改变是在2006年进行的，极大地简化了库和用户应用程序，之前用户应用程序被迫将轨道复制为防御性编程的应用，并且当他们忘记复制时，会遇到难以找到的错误。

对于轨道演化计算，这个包是不够的。需要包括动力学概念、力模型、传播算法等。这个的入口点是Propagator接口。

现有的轨道表示

可用的轨道表示有：

• 经典的椭圆开普勒轨道，其参数为：

  • a：半长轴（米）
  • e：离心率（支持任意值的e，即可以使用椭圆轨道和双曲线轨道）
  • i：倾角（弧度）
  • ω：近地点幅角（弧度）
  • Ω：升交点赤经（弧度）
  • v、M或E（弧度）：分别为真近点角、平近点角或偏心近点角

• 圆形轨道，用于表示几乎圆形的轨道，即具有较低离心率的轨道。其参数为：

  • a：半长轴（米）
  • ex：离心率矢量的X分量：e × cos(ω)
  • ey：离心率矢量的Y分量：e × sin(ω)
  • i：倾角（弧度）
  • Ω：升交点赤经（弧度）
  • αv、αM或αE（弧度）：分别为(ω + v)、(ω + M)或(ω + E)

• 赤道轨道，用于表示赤道轨道（几乎圆形轨道，几乎无倾角）。其参数为：

  • a：半长轴（米）
  • ex = e × cos(ω + Ω)
  • ey = e × sin(ω + Ω)
  • hx = tan(i/2) cos(Ω)
  • hy = tan(i/2) sin(Ω)
  • λv、λM或λE（弧度）：分别为真经度参数（ω + Ω + v）、平经度参数（ω + Ω + M）或偏心经度参数（ω + Ω + E）

• 笛卡尔轨道，与其参考系定义相关联，其参数为：

  • (X, Y, Z)（米）：给定参考系中点的位置矢量
  • (Vx, Vy, Vz)（米/秒）：给定参考系中点的速度矢量

请注意，这里不考虑两行根数元素（TLE）作为轨道表示。这是因为TLE实际上是轨道状态和传播模型的合并。该状态仅在与相关的SGP4/SDP4传播模型相关时才有意义，并且不能在任何其他模型中使用。

表示和转换

所有的表示都可以相互转换。如果某些转换是模糊的（例如将完全圆形的轨道从笛卡尔表示转换为开普勒表示，存在近地点参数的模糊性），不会触发错误。这个设计选择是基于许多不同的尝试和实用考虑的结果。理论基础是从物理角度来看，不存在奇点。奇点只是通过选择不同的表示引入的。即使考虑到这一点，似乎与其有一个没有现实值的参数，不如有无限多个值都代表相同的物理轨道。Orekit只是做了一个任意的选择，通常只选择值为0。在我们的示例中，我们将得到一个具有0近地点参数的转换轨道。这个选择是有效的，就像任何其他选择（π/2，π，等等...）一样有效，因为它正确地表示了轨道，并且当转换回原始的非模糊表示时，它确实给出了正确的结果。

因此，我们认为用户有责任了解不同表示的正确定义以及与每个表示相关的奇点。如果用户确实需要进行一些转换（例如以后提供一个类似于开普勒参数的轨道作为两行元素，记住TLE确实使用类似于开普勒的参数），那么他可以这样做。

Orekit中处理转换的方式非常简单，可以轻松透明地进行处理，同时避免在原始轨道已经是适当类型时盲目创建新对象。因此，转换轨道的适当方式如下所示，以CircularOrbit为例：

OrbitType     type     = OrbitType.CIRCULAR;
CircularOrbit circular = (CircularOrbit) type.convertType(orbit);

在这个例子中，将类型枚举转换为CircularOrbit的强制转换是可以成功的。如果轨道已经是正确的类型，则不会创建任何对象。例如，Eckstein-Hechler传播器仅以圆形轨道定义。因此，在传播器初始化或重置状态时间时，隐式进行转换，内部使用类似上面示例的代码。

包组织