跳转至

Challenges of Computational Nanosatellites

Computational nanosatellite architects face three key challenges. First, physical constraints on nanosatellite design (e.g. orbit altitude or volume limitations imposed by the cubesat standard) bound the achievable fidelity of visual data. Second, orbit characteristics determine data collection rate because satellite position and velocity dictate when and how often to capture data. Third, the relationship between orbit characteristics, Earth rotation, and ground station locations determines downlink availability, duration, and bitrate.

Data Quality is Physically Constrained

The physical design of a nanosatellite limits visual sensor data quality. Satellite image quality is measured by ground sample distance (GSD), i.e. the geographic distance represented between centers of adjacent pixels. As GSD decreases, image quality increases. Commercial, monolithic systems have GSD as low as 0.3 m/px [21], while commercial nanosatellite systems have GSD around 3.0 m/px [74].

Three parameters govern GSD: orbit altitude, camera focal length, and pixel sensor size. Merit is proportional to focal length and inversely proportional to altitude and sensor size.

Sensor size. We assume a COTS image sensor of at least 4096 × 3072 pixel sensors (i.e. 4K), each 1.1 µm [73] in size.

Orbit altitude. Orbit altitude is often between 325 km and 825 km for LEO. Higher altitudes support longer missions (years instead of weeks), but suffer worse image quality.

Focal length. The cubesat standard bounds camera focal length because components compete for limited volume. Earth-observation cubesats must include radios, energy storage, computing systems, and an attitude determination and control system (ADACS) to point the camera.

Designing for Low GSD. An Earth-observing satellite should optimize for low GSD. Figure 2 plots a cubesat design space, assuming a 3U volume (like existing, commercial systems [20]) and calculating GSDs with the pinhole camera model [35]. Each curve represents a different camera focal length. The data show that a 20 cm focal length provides a GSD of 2.26 m/px, which is 7.5× worse than a monolithic satellite but comparable to existing cubesats. Low GSD requires a long focal length, limiting non-camera components to a 1U volume. Figure 3 charts contributions of state-of-the-art nanosatellite subsystems [1, 4, 25, 27, 46–49, 52, 84] toward volume, mass, power, and cost, revealing that volume and power limit cubesat design while mass and cost do not.

纳米卫星的物理设计限制了视觉传感器的数据质量。卫星图像质量通过地面采样距离（Ground Sample Distance, GSD）来衡量，即相邻像素中心所代表的地理距离。GSD越小，图像质量越高。商业化的单体式卫星系统的GSD可低至0.3米/像素[21]，而商业化的纳米卫星系统的GSD约为3.0米/像素[74]。

三个参数决定了GSD：轨道高度、相机焦距和像素传感器尺寸。图像质量与焦距成正比，与轨道高度和传感器尺寸成反比。

  • 传感器尺寸。我们假设采用商用现成品（COTS）图像传感器，其像素至少为4096×3072（即4K），每个像素尺寸为1.1µm[73]
  • 轨道高度。对于低地球轨道（LEO），轨道高度通常在325公里到825公里之间。更高的轨道支持更长的任务寿命（数年而非数周），但图像质量会变差
  • 焦距。立方体卫星标准限制了相机的焦距，因为各组件在有限的体积内相互竞争。地球观测立方体卫星必须包含无线电、储能设备、计算系统以及一个用于指向相机的姿态确定与控制系统（ADACS）

为低GSD而设计。一颗地球观测卫星应为实现低GSD而优化。图2展示了一个立方体卫星的设计空间，假设其体积为3U（与现有商业系统类似[20]），并使用针孔相机模型[35]计算GSD。每条曲线代表一种不同的相机焦距。数据显示，20厘米的焦距可提供2.26米/像素的GSD，这比单体式卫星差7.5倍，但与现有的立方体卫星相当。实现低GSD需要长焦距，这使得非相机组件的体积被限制在1U以内。图3展示了最先进的纳米卫星子系统[1, 4, 25, 27, 46–49, 52, 84]在体积、质量、功率和成本方面的贡献分布，揭示了 体积和功率是限制立方体卫星设计的关键因素，而质量和成本则不是。

Data Rate Depends on Orbit Parameters

The astrodynamics of a nanosatellite determine the optimal rate at which to collect images. This rate must be both frequent enough to cover the entire ground track, and infrequent enough to avoid redundant data. A satellite avoids collecting redundant images by making observations at the ground track frame rate (GTFR). The GTFR is the rate at which an entirely new geographic scene fills the camera view with no pixel overlapping a previous frame. The ground track frame period (GTFP) is the inverse of GTFR, i.e. the time a nanosatellite takes to pass over one ground track frame. To minimize data volume, camera sensors need not capture frames at rates higher than the GTFR. In order to achieve sufficient coverage of a ground track, a satellite or constellation must capture images individually or in aggregate at the GTFR. We discuss distributing sensing across a constellation in Section 4.2.

纳米卫星的天体动力学特性决定了其收集图像的最佳速率。这个速率必须足够频繁以覆盖整个星下点轨迹，同时也要足够稀疏以避免数据冗余。卫星通过以星下点轨迹帧率（Ground Track Frame Rate, GTFR）进行观测来避免收集冗余图像。GTFR是指一个全新的地理场景完全填满相机视场且与前一帧无任何像素重叠的速率。星下点轨迹帧周期（GTFP）是GTFR的倒数，即纳米卫星飞越一个星下点轨迹帧所需的时间。为了最小化数据量，相机传感器的捕获帧率无需高于GTFR。为了实现对星下点轨迹的充分覆盖，一颗卫星或一个星座必须以GTFR单独或聚合地捕获图像。我们将在第4.2节讨论如何在星座中分配感知任务。

专业术语太多, 梳理一下

  • 星下点轨迹 (Ground Track): This is just the "road" on the Earth's surface directly beneath the satellite.

  • 帧 (Frame): This is one of your photo "tiles." It's a single picture taken by the camera.

  • 星下点轨迹帧率 (GTFR): This is the rate of taking pictures (e.g., "take 1 picture every 0.8 seconds"). It's the perfect rhythm for laying down the photo tiles.

  • 星下点轨迹帧周期 (GTFP): This is the time it takes for the satellite to travel the length of one photo tile (e.g., "it takes 0.8 seconds to cross one frame"). It's just the inverse of the rate.

For a satellite, every bit of data and every watt of energy is precious. By taking pictures at the GTFR, the satellite captures everything it needs to see on its path with the absolute minimum amount of data. It's the ultimate in efficiency.

Bitrate Bottlenecks Constrain Constellations

Bent pipes break as nanosatellite constellation population increases due to limitations on downlink availability and bitrate. Under a bent-pipe architecture, each nanosatellite stores data (generally for minutes or hours) until it nears a ground station. During a downlink session, which lasts between a few seconds and ten minutes, the satellite transmits its unprocessed data. Under this model, existing systems [20] experience a 5.5 h delay before data reach customers. Reconfiguring a constellation via uplink takes longer; initial configuration lasts months [12].

Bent-pipe architectures require many ground stations to support a large constellation. We evaluate existing, bent-pipe constellations with cote-sim in Section 7.1 and provide a simple motivating example here. A satellite in a polar orbit has access to all latitudes and, with a sun-synchronous orbit, ensures consistent pass times. Such a satellite at a 410 km altitude has an orbit period of 92.9 min and revisits the same point on Earth every two days [11]. Existing ground stations with a 200 Mbit/s downlink datarate [20] retrieve up to 15 GB of data per 10 min session. With these parameters, a ground station optimistically and ideally positioned to observe every pass (e.g. a polar station for a polar orbit) supports only 9 satellites per revolution. Supporting a future 1000-satellite constellation requires 112 of these ideally positioned stations.

Provisioning this costly ground station network may be pointless, because a large fraction of downlinked images contain no features of interest. And, as cote-sim reveals in Section 7.1, this estimate is overly ideal. It assumes that satellites are positioned in orbit such that all 112 ground stations are constantly in use, and it assumes that all satellites receive a full 10 min of downlink time. cote-sim reveals that neither of these assumptions hold true in realistic systems.

OEC Eliminates the Bent-Pipe Bottleneck. OEC reduces the need for a large number of ground stations by processing images on orbit, downlinking only interesting images, and discarding or logging the rest. For example, assuming that machine inference identifies 0.75 GB of interesting data out of 15 GB of raw data, all data downlink in only 30 s at 200 Mbit/s. Instead of servicing just 9 satellites per revolution, each ground station supports 185 satellites, and a constellation of 1000 OEC satellites requires only 6 ground stations.

由于下行链路可用性和比特率的限制，随着纳米卫星星座规模的增加，“弯管”架构会逐渐失效。在“弯管”架构下，每颗纳米卫星存储数据（通常持续数分钟或数小时），直到接近一个地面站。在持续几秒到十分钟的下行链路会话期间，卫星传输其未经处理的数据。在此模型下，现有系统[20]在数据到达客户前会经历5.5小时的延迟。通过上行链路重新配置星座则需要更长时间；初始配置可持续数月[12]。

“弯管”架构需要许多地面站来支持一个大型星座。我们在第7.1节中使用cote-sim评估了现有的“弯管”星座，并在此提供一个简单的启发性示例。一颗在极地轨道上的卫星可以访问所有纬度，并且通过太阳同步轨道，可以确保一致的过境时间。这样一颗在410公里高度的卫星，其轨道周期为92.9分钟，每两天重访地球上的同一点[11]。现有的地面站拥有200 Mbit/s的下行数据率[20]，每次10分钟的会话最多可接收15 GB的数据。在这些参数下，一个位置理想（例如，对于极地轨道的极地站）且能观测到每次过境的地面站，在每个轨道周期内仅能支持9颗卫星。要支持未来一个拥有1000颗卫星的星座，将需要112个这样位置理想的站点。

配置这个昂贵的地面站网络可能毫无意义，因为下传的图像中有很大部分不包含任何感兴趣的特征。而且，正如cote-sim在第7.1节所揭示的，这种估计过于理想化了。它假设卫星在轨道中的位置使得所有112个地面站都持续被使用，并且假设所有卫星都能获得完整的10分钟下行时间。cote-sim揭示了在现实系统中，这两个假设都不成立。

OEC消除了“弯管”瓶颈。 OEC通过在轨处理图像，只下传感兴趣的图像，并丢弃或记录其余图像，从而减少了对大量地面站的需求。 例如，假设机器推断从15 GB的原始数据中识别出0.75 GB的感兴趣数据，那么在200 Mbit/s的速率下，所有数据只需30秒即可完成下传。每个地面站不再是每个轨道周期服务9颗卫星，而是可以支持185颗卫星。一个拥有1000颗OEC卫星的星座，仅需6个地面站即可。