Astrometry / FPGA 调研
Research Report · 2026-06-22

Astrometry.net 与同类星图识别算法的 FPGA 实现调研

详细拆解三个已发表实现，并扩展检索星敏感器、全天区星图识别、质心提取、神经网络识别与容错前端。报告重点回答：哪些环节适合硬化、已达到什么性能、资源花在哪里、瓶颈何在，以及完整 Astrometry.net 硬化的现实上限。

核心结论：未检索到公开的完整 Astrometry.net FPGA 移植推荐架构：PL 前端 + CPU 索引/验证/WCS证据：论文全文、官方文档与资源表
Executive summary

执行摘要

3
重点完整拆解的 FPGA / SoC FPGA 实现
9+
扩展检索的相关硬件实现与论文
≈339.1 MiB
仅 Astrometry.net 4107–4119 宽视场索引总量
≈1330×
上述索引相对 261 KB 片上星库的容量倍数
检索结论：截至本次检索，没有发现 Astrometry.net 官方仓库或公开论文给出的“完整、可综合、可复现”的 FPGA/HLS/HDL 后端。存在大量同类 lost-in-space 星识别与星敏感器 FPGA 实现，但它们通常假设固定相机、固定视场、已标定焦距和较小导航星表，能力边界与“任意来源、未知尺度、未知旋转、可能带畸变”的 Astrometry.net 不同。

案例一：匹配核最硬

Wu 等把已提取星点到恒星身份识别基本全部放入 Kintex-7。多分辨率径向模式适合流水和 BRAM，但不含原始图像预处理，也不输出通用 WCS。

案例二：链路最完整

Marin & Bang 从像素、ROI、质心、亮星排序、特征到数据库匹配都在 Zynq PL 中运行；最终姿态浮点计算留给处理器。真正瓶颈已从计算转向图像搬运。

案例三：最可复用

Panousopoulos 等明确把占计算量 >95% 的预处理与质心放入 PL，把低维匹配留在 ARM。该分工与 Astrometry.net 的最优工程切分高度一致。

Scope and terminology

边界与术语：不要把三类任务混为一谈

任务典型输入先验典型输出与 Astrometry.net 的关系
星点检测 / 质心提取原始像素流阈值、PSF/光斑尺寸等(x,y)、亮度、窗口只是前端；非常适合 FPGA
星敏感器 Lost-in-Space 识别星点向量固定焦距、固定 FOV、已标定畸变、有限导航星表恒星 ID、姿态算法思想相近，但问题规模更受限
Plate solving / Astrometry.net任意天文照片或 XYLS可无初值，甚至未知尺度指向、尺度、旋转、WCS/SIP更通用、更依赖多尺度索引和假设验证
“全天区”不等于“任意照片”。星敏感器文献中的 all-sky / lost-in-space 通常表示事先不知道姿态，但相机模型、焦距、视场和星表仍然固定。Astrometry.net 还要容忍未知比例尺、不同成像系统、裁剪、翻转、历史底片与更复杂畸变。
Astrometry.net mapping

Astrometry.net 算法链与 FPGA 适配度

官方论文和代码结构显示，求解器先进行稳健源检测，再从亮星中构造四星/五星 asterism，利用几何哈希与预构建索引生成候选解，随后通过贝叶斯模型比较验证，并拟合 TAN/WCS 与 SIP 畸变。官方代码包含紧凑 k-d tree 库，索引按角尺度和 HEALPix 天区切分。

源检测背景、阈值、连通域、质心
→
亮星筛选排序、均匀化、去线条
→
Quad 生成A/B backbone + C/D 组合
→
索引查询k-d tree、随机访存、多尺度
→
候选验证星表投影、Bayes 假设检验
→
WCS / SIP浮点拟合、畸变与输出

各阶段的硬化价值

像素预处理
适合度：高
流式、局部窗口、固定吞吐
星点质心
适合度：高
乘加、累加、定点化
Top-N / Quad
适合度：中高
可流水，但组合数会增长
索引查询
适合度：中低
不规则树遍历、外存随机访问
验证
适合度：低
分支多、候选数动态
WCS/SIP
适合度：低
低频浮点与控制主导
最强落地点：Astrometry.net 原生接受 FITS XYLS/AXY 星点列表。这意味着 FPGA 可以只负责传感器到星点坐标的高速前端，然后把结果直接交给未修改或轻量修改的 CPU 求解器，避免在第一版中硬化最复杂的 k-d tree、验证与 WCS 拟合。
Case 1 · Wu, Zhu & Zheng, 2019

案例一：多分辨率径向特征星识别

XC7K325T
Xilinx Kintex-7，100 MHz
1,843 slices
占器件约 3.61%
58 BRAM36
约 261 KB，器件约 13%
0.14–1.4 ms
单次匹配 / 最坏多主星尝试

算法核心

以靠近光轴的一颗“主星”为中心，计算邻星相对主星的角距离，并量化为长度 512 的二值径向模式。随后通过 Haar 小波只保留低频部分，得到 256 和 128 维模式，以低分辨率粗筛 → 中分辨率缩小候选 → 高分辨率确认的方式匹配。若失败，则换下一颗靠近光轴的星作为主星。

星点坐标已完成检测与质心
→
按光轴距离排序选择主星
→
角距计算生成 N=512 径向向量
→
Haar 多分辨率512 → 256 → 128
→
三级匹配阈值 120 / 240 / 480
→
星表输出ID、RA/Dec

数据与测试条件

  • SAO J2000，剔除双星和变星后 3,610 颗导航星，极限星等约 +6Mv。
  • 相机视场 14°，模式半径 7°，图像 1024×1024。
  • 11,000 张电子星模拟器图像；加入 0–3 像素位置误差或 1–3 颗假星。
  • 3 像素误差时识别率 98.5%；3 颗假星时 98.9%。

资源如何花费

  • 导航星表约 28 KB；多分辨率特征表约 225 KB。
  • 论文同时报告 BRAM 总量约 261 KB；28+225=253 KB，约 8 KB 差值可理解为对齐、控制表或取整。
  • 主要资源是片上数据库；逻辑只占约 3.61%，说明该算法本质上是“存储 + 大量并行比较”。

性能、瓶颈与能力上限

维度分析
性能优势二值模式、not-XOR/计数式评分和三级筛选适合深流水；星库全部在 BRAM 时延确定。
真正瓶颈不是算术，而是多候选模式的 BRAM 带宽、比较并行度与换主星重试次数。
未计入工作原始图像背景估计、阈值、连通域、质心，以及最终三轴姿态/WCS 拟合。
能力上限固定 14° 相机与有限明亮星表；输出星 ID/RA/Dec。不能直接处理未知比例尺、任意焦距、复杂畸变的普通天文照片。
对 Astrometry.net 的启示“先低分辨率过滤、后精匹配”值得借鉴；但其 261 KB 星库与 Astrometry.net 多尺度索引不是同一量级。
Case 2 · Marin & Bang, 2020

案例二：Zynq-7020 高速星敏感器完整流水线

2,281 slices
约 17.2% XC7Z020
4,341 LUT logic
另有 1,184 LUTRAM
5 / 4
BRAM / DSP
14.7 ms
含 13.1 ms 图像传输

架构与软硬件分工

1280×1024 像素8-bit，100 MHz
→
extract_ROI3×3 最大值窗口，II=1
→
FIFO + star_detector质心/星等，174 周期阻塞
→
亮星在线排序bubble-sort shift register
→
特征提取CORDIC hypot/atan2，192-bit
→
数据库流匹配21 个特征各保留最近候选
→
姿态计算处理器浮点运算

该方案是三个案例中从原始像素到星识别最完整的。PL 负责高吞吐部分，最终姿态计算由于调用频率低、浮点和控制复杂，被明确留在微处理器上。

详细资源表

IPSlice逻辑 LUTLUTRAMBRAMDSP资源热点
AXI FIFO51276800解耦阻塞质心核
extract_ROI25815864000窗口移位寄存器/LUTRAM
feature extractor1,0012,49713023hypot / atan2 CORDIC
feature matcher8021,38333430数据库流与评分逻辑
star detector1872761201质心与星等
总计2,2814,3411,18454逻辑约 17%，BRAM/DSP 很低

为什么会看到 1.59、14.7、21 和 34.1 ms 四种数字？

固定数据库核心延迟

图像传输
13.1 ms
FPGA 核
1.59 ms

对 2,176 元素数据库，端到端约 14.7 ms；此处 I/O 占主导。

数据库规模/覆盖率权衡

k=1
15.0 ms
k=5
21.0 ms
k=21
34.1 ms

数据库从 83 KB 增至 1,018 KB，10,000 次测试的高置信结果由 9,004 增至 9,998。

能力、动态性能与上限

项目结果与解释
设计目标约 50° FOV、星等 ≤5、25–50 Hz，固定相机模型的 lost-in-space 姿态估计。
准确度/覆盖论文在无噪声仿真中报告约 0.001° RMSE 与接近 99% 的天空覆盖；最终 FPGA 特定实现的旋转测试约 97.7% 覆盖。
高速机动15°/s 时可保持约 99% 量级覆盖；30°/s 时仅较大检测窗配置仍约 94.2%，说明运动拖影成为能力边界。
瓶颈图像搬运支配固定数据库延迟；扩大数据库后匹配延迟近线性增长。特征提取中的 CORDIC 是逻辑热点。
能力上限固定宽视场与明亮星表；最终姿态仍在 CPU。它比案例一完整，但仍不是能处理任意天文图像的 WCS plate solver。
Case 3 · Panousopoulos et al., 2024

案例三：4 MP 星图预处理与质心提取的 SoC FPGA 协同实现

2048²
12-bit，约 4.19 MP/帧
24.4 FPS
约 100 MPixel/s
8.9×
整机 HW/SW 加速
14K / 55
LUT / DSP（FGF 集成）

架构：把像素域放进 PL，把低维控制留在 PS

PS/相机像素流AXI4-Stream，1 pixel/cycle
→
Binning行 FIFO + 加法树 + 移位除法
→
Threshold + Clustering条带/重叠块、状态机、循环缓冲
→
CentroidHDL-CG / HLS-CG / HLS-FGF
→
Star matchingARM 上的低维模式识别
→
姿态/控制任务相关逻辑

作者的关键判断是：预处理与质心在 lost-in-space 模式中处理整帧像素，占总计算量超过 95%；匹配只处理低维向量，放在 ARM 更容易维护和迭代。这是本报告最推荐的 Astrometry.net 分工依据。

预处理与质心核资源

预处理模块LUTLUTRAMFFBRAM
Binning2.7K2103.8K4.5
Clustering5K2216K8
集成预处理5.2K2226.5K10
质心核LUTFFDSPBRAM吞吐
HDL-CG2554663218 Mcluster/s
HLS-CG1.4K1.5K2012 Mcluster/s
HLS-FGF8.7K13.8K5501 Mcluster/s
资源理解：截图中的“14K LUT、20K FF、55 DSP、10 BRAM”是集成 FGF 方案的总量级：约等于 5.2K LUT 预处理 + 8.7K LUT FGF。55 DSP 几乎全部由浮点 FGF 消耗；若采用定点 CG，资源可显著下降，但噪声与 S-curve 精度更敏感。

时间分解与瓶颈迁移

全软件 ARM

预处理
344 ms
质心
6 ms
后续匹配等
15 ms

合计约 365 ms/帧。

HW/SW 协同

PL 预处理
26 ms
其余链路
≈15 ms

整机约 41 ms/帧，8.9×；首个质心约 0.5 ms，后续质心间隔约 1 μs。

瓶颈证据与影响改进方向
PS–PL DMAPL 预处理可闭合到 232 MHz，但整机 DMA 稳定在 167 MHz；26 ms 中大部分是搬运与在线 binning。直接接相机、拓宽 AXI、双端口/多通道、减少往返。
HLS 除法器HLS-CG 临界路径位于自动推断的除法核，频率不如手写 HDL。定点倒数、查表/牛顿迭代、RTL 化。
FGF 浮点网络55 DSP、13.8K FF；关键路径包含浮点减法且约 82% 为布线延迟。混合精度、定点 Cholesky、资源复用或只对困难光斑调用。
能力上限论文只硬化检测/质心，匹配仍在 ARM；因此无法从其 26 ms 推断完整 Astrometry.net 求解延迟。把输出改为 XYLS，直接接 Astrometry.net backend。
Cross comparison

三个重点案例的可比性与差异

不能只比较“毫秒数”。案例一的 0.14/1.4 ms 从星点坐标开始；案例二的 1.59 ms 是 FPGA 核而 14.7 ms 含图像传输；案例三的 26 ms 只覆盖预处理，完整 HW/SW 链约 41 ms。准确度指标也分别是识别率、姿态 RMSE 与质心像素误差，不能横向当作同一指标。
维度Wu 2019Marin 2020Panousopoulos 2024Astrometry.net
输入起点已提取星点原始 8-bit 像素原始 12-bit 像素图像或 XYLS
硬化范围特征+匹配+ID检测+质心+特征+匹配预处理+质心无官方硬化
相机先验固定 14°固定约 50°固定 15.5°可未知尺度
数据库3,610 星，约 261 KB约 83–1,018 KB 特征库匹配在 ARM，未给硬件库多尺度 FITS index，宽视场即约 339.1 MiB
输出星 ID / RA-Dec候选匹配；CPU 姿态质心；CPU 匹配/姿态WCS、尺度、旋转、SIP
主要瓶颈BRAM 带宽与候选比较图像传输、CORDIC、库规模DMA、浮点 FGF 布线组合生成、随机索引访存、验证/WCS
最适场景紧凑专用星敏感器高更新率宽视场星敏感器高分辨率可复用前端任意来源图像 plate solving
Bottlenecks and ceilings

瓶颈与能力上限：从 BRAM 到外存随机访问

1. 数据库容量决定架构

案例一用约 261 KB 把导航星表和模式表装入 BRAM。Astrometry.net 仅 4107–4119 宽视场索引就有 355,536,000 bytes（约 339.1 MiB），约是前者的 1330 倍；窄视场 5200 系列还会按天区拆成更多文件。完整索引只能放 DDR/eMMC/NVMe。

2. 随机访问破坏理想流水

星敏感器特征表通常可以顺序扫或并行比较；Astrometry.net 的 code k-d tree、quadfile、star k-d tree 和候选验证会产生不规则访问。即使把计算逻辑放进 PL，性能也可能被 DDR 随机延迟和缓存命中率限制。

3. Quad 组合数是动态的

Astrometry.net 会逐步加入亮星并枚举 A/B/C/D 的合法排列，候选数随星点数量、噪声和尺度变化。硬件需要队列、回压、溢出策略与超时，不能按固定每帧工作量估算。

4. 验证比初匹配更难硬化

命中一个 quad 只是生成假设；还要投影星表、统计对应关系、进行模型比较并拟合 WCS/SIP。这部分分支多、调用频率低，CPU 的灵活性通常胜过专用流水。

5. I/O 很快成为主瓶颈

案例二的 14.7 ms 中约 13.1 ms 是图像传输；案例三在加速计算后又受 167 MHz DMA 限制。最优系统应让传感器直接流入 PL，避免 PS→PL→PS 的整帧往返。

6. 辐射与可验证性

空间应用还需配置存储擦洗、BRAM ECC、TMR/DMR、看门狗和可重配置。将复杂动态软件全部改写成 RTL 会显著增加验证成本和故障面。

Proposed architecture

针对 Astrometry.net 的四级硬化方案

方案 V1：FPGA 源提取器 + 原生 CPU solver（推荐起点）

相机 / 图像流式或 DMA
→
校正与背景坏点、平场、局部背景
→
检测与质心连通域、亮度、Top-N
→
XYLS / AXY坐标、亮度、图像尺寸
→
Astrometry backend索引、验证、WCS/SIP

优势是接口天然兼容、风险低、能立即用官方索引和验证逻辑。FPGA 的价值集中在高分辨率图像、低功耗连续处理、去除 CPU 上最重的像素域计算。

方案 V2：在 PL 增加 Top-N 和 Quad 描述子生成

在 V1 基础上把亮星排序、空间均匀化和部分 quad code 生成放进 PL，CPU 只做索引查询与后处理。可减少 CPU 组合枚举，但要解决动态队列、尺度假设和码空间定点精度。

方案 V3：固定相机的“专用 Astrometry”

若视场、焦距、畸变和目录固定，可舍弃通用多尺度索引，改用径向模式、K-vector、Pyramid 或紧凑 tetra hash。此时数据库可从数百 MB/GB 降到 KB/MB，完整 PL 匹配可行，性能接近案例一/二；但产品已经不再是通用 Astrometry.net。

方案 V4：完整 Astrometry.net 纯 PL

技术上可以用 DDR 控制器、硬件队列、树搜索、浮点核和软核 CPU 拼出功能等价系统，但会形成“在 FPGA 里重造一台复杂计算机”。除极端确定性/辐射/功耗约束外，开发、验证和维护成本通常不合理。

工程资源预算（估算，不是论文综合结果）

子系统保守预算外存依据/说明
V1 像素前端8–20K LUT，10–30K FF，5–40 DSP，10–40 BRAM可只需行缓冲；大图可配 DDR由案例二、三和质心文献外推
Top-N + 均匀化2–8K LUT，若干 BRAM/LUTRAM通常无需整帧在线排序、分区桶与优先队列
Quad 描述子5–25K LUT，5–20 DSP，10–80 BRAM建议 DDR 队列依并行组合数、定点除法和背压而变
索引与验证 CPU四核以上 ARM/x86 更稳妥1–4 GB DDR；eMMC/NVMe 存索引宽视场索引已约 339.1 MiB，窄视场更大
完整纯 PL难以给出可信固定值必须高带宽外部 DDR + 大容量非易失存储资源取决于缓存、并发候选和浮点验证策略
Feasibility assessment

技术可行性判断

方案
技术可行性
开发风险
通用性
结论
V1 FPGA 源提取 + CPU Astrometry
9/10
低—中
高
首选；最快形成可验证原型
V2 + Quad 生成
7/10
中—高
高
有明确吞吐需求时再做
V3 固定相机专用全硬件识别
8/10
中
低
星敏感器/航天载荷最划算
V4 完整 Astrometry.net 纯 PL
3/10
极高
高
理论可行，经济性和维护性差

对“用户上传任意照片”的建议

采用 Linux/Docker + Astrometry.net CPU worker + NVMe 索引；若吞吐或功耗有压力，再引入 FPGA source extractor。由于上传、解码、索引 I/O 和任务调度占比高，完整 FPGA 通常不能带来与开发成本匹配的收益。

对“固定相机实时星敏感器”的建议

采用 Zynq/MPSoC：PL 处理相机流、检测、质心和可选特征；ARM 处理匹配、姿态、标定与异常恢复。若要求几十至数百 Hz，可进一步把紧凑星库匹配放入 PL。

Implementation roadmap

建议的实施路线与验收指标

阶段 0：建立 CPU 黄金模型

固定 Astrometry.net 版本、索引集和图像集；记录 source extraction、quad search、verification、WCS 的分段耗时与失败原因。

阶段 1：只替换 source extraction

FPGA 输出 XYLS；逐图比较星点位置、亮度排序、召回率和最终 solve 成功率。目标不是质心误差最小，而是求解成功率不下降。

阶段 2：消除整帧往返

相机直接进入 PL；只回传 Top-N 星点。验证 AXI 带宽、背压、曝光切换、饱和星和星云背景。

阶段 3：硬化候选生成

统计真实数据上的 quad 数量分布，设计有界队列与溢出降级；CPU 保留回退路径。

阶段 4：面向部署优化

索引裁剪、HEALPix 分区、DDR 缓存、eMMC/NVMe 预取；空间应用再加入 ECC、scrubbing、TMR/DMR 和故障注入。

建议验收指标

类别指标为什么重要
功能最终 WCS 成功率、假阳性率、重投影残差比单独质心误差更接近产品目标
前端星点召回、假星率、Top-N 顺序一致性、动态范围Astrometry 依赖最亮源和组合质量
实时P50/P95/P99 延迟、最坏候选数、超时比例盲解算工作量高度动态
资源LUT/FF/BRAM/DSP、DDR 带宽、索引缓存命中片上资源并非唯一瓶颈
鲁棒性拖影、热像素、云层/星云、裁剪、镜像、尺度误差普通天文照片比仿真星敏感器复杂
空间可靠性SEU 注入、恢复时间、错误检测覆盖决定 COTS FPGA 能否上星
References and evidence

参考资料与证据来源

A1
Astrometry.net: Blind astrometric calibration of arbitrary astronomical images
Lang et al., Astronomical Journal, 2010。算法总览：源检测、四/五星几何哈希、预索引、贝叶斯验证与 WCS。
A2
Astrometry.net 官方代码仓库；代码结构；README/索引说明
官方 C/Python 代码、libkd、XYLS/AXY 接口与求解阶段。
A3
Astrometry.net index files；4100 系列目录
索引尺度、HEALPix 分片及 4107–4119 文件容量。
P1
P2
P3
HW/SW co-design on embedded SoC FPGA for star tracking optimization in space applications
Panousopoulos et al., JRTIP 2024, DOI 10.1007/s11554-023-01391-8。A
R1
R2
A Star Identification Algorithm for All-Sky Regions in Star Radiation Mode and Its FPGA Implementation
Liu et al., Semiconductor Optoelectronics 44(1), 2023, DOI 10.16818/j.issn1001-5868.2022112801。B
R3
Algorithm and FPGA Realization of Fast All-Sky Region Star Identification Based on K-vector
Liu et al., ICMCCE 2024, DOI 10.1109/ICMCCE63640.2024.11163511。C
R4
AI-Based Real-Time Star Tracker
Carmeli & Ben-Moshe, Electronics 2023, DOI 10.3390/electronics12092084。A
R5
R6
R7
Toward a Fault-Tolerant Star Tracker for Small Satellite Applications
Aranda, Reviriego, Maestro, IEEE TAES 2020, DOI 10.1109/TAES.2020.2971289。A
R8
A Survey of Lost-in-Space Star Identification Algorithms Since 2009
Rijlaarsdam et al., Sensors 2020。用于算法分类与“不同论文指标不可直接比较”的方法论。A
方法说明：本报告只把公开论文明确给出的数字列为“论文结果”；由多个实现外推的资源范围均标为“工程估算”。访问日期为 2026-06-22。
Appendix

附录：用户提供的三个实现摘要截图

用户提供的三个FPGA实现摘要截图
图 A-1：原始截图。正文已逐项追溯到论文并补充算法边界、时间口径与资源构成。
本报告为技术调研与架构评估，不代表 Astrometry.net 官方 FPGA 路线图。对未公开全文的论文，资源数字保持空缺而不作猜测。