Knowit 3052e42991 tools/epro2: add ProjectRelations for cross-document resolution
per-doc Relations 在大量 cross-doc 引用前是不够的:PCB 的 PAD_NET 复合
id [PAD_NET, comp, pin, pad] 里的 pad 实际是 FOOTPRINT 文档里的 pad
实例;SCH_PAGE 的 COMPONENT.partId 指向某个 SYMBOL 文档的 PART.id。

ProjectRelations 在 per-doc Relations 之上做项目级聚合,把这些跨文档
引用拼起来。

Probe 阶段(ESP-VoCat)发现的映射规则(已写入 docstring):

1. SCH_PAGE COMPONENT.partId  ===  PART.id in some SYMBOL doc
   - 命名两种风格:'pid<hex>' (anonymous/系统 part) + '<name>.<n>' (具
     名 SKU),但都直接相等 PART.id,**不**是不同 namespace
   - 同一 PART.id 可能出现在多个 SYMBOL 文档里(库快照),
     parts_by_id 保留全部,consumer 通常取第一个

2. PCB COMPONENT.id  →  FOOTPRINT 文档 UUID  via 单独 ATTR op:
       ATTR(parentId=<comp>, key="Footprint", value=<fp_doc_uuid>)
   COMPONENT.attrs 子 dict 只有内务字段(Unique ID / Channel ID / ...),
   **不**含 footprint 引用。这跟 schematic 的 partId 在 COMPONENT 上的
   做法不一样,是 EPRO2 流的一处不对称

3. PCB PAD_NET[comp,pin,pad] 里的 pad 是 FOOTPRINT 文档内部的 pad id;
   解析链: comp → ATTR Footprint → FOOTPRINT relations.pads[pad]

API:
  ProjectRelations.build(project) — 单遍构建
  resolve_symbol_docs(sch_uuid, comp_id) → [SYMBOL doc uuids]
  resolve_footprint_doc(pcb_uuid, comp_id) → FOOTPRINT doc uuid | None
  pad_in_footprint(fp_uuid, pad_id) → PAD payload | None
  resolve_pcb_pad_net(pcb_uuid, comp, pin, pad) → {footprint, pad} | None
  attrs_for_pcb_component(pcb_uuid, comp_id) → {key: value} 折叠

CLI 加 --project-relations,跑 ESP-VoCat:
  documents                                 278
  distinct_parts                             87
  duplicated_parts                            9
  pcb_components_with_footprint             206
  pcb_components_unresolved_footprint         0
  sch_components_with_partid                572
  sch_components_unresolved_part              0

PCB 样本验证:comp=e0 → fp=1069352d81c6 Designator='U8',
PAD_NET pin=1 pad=e7 net=GND 跨文档解到坐标 (-37.4,-45.24)。

测试:6 个新单测覆盖 partId→symbol、comp→footprint、PAD_NET 跨文档、
attrs 折叠、unresolved 计数。parser + relations + project_relations
共 21/21 通过。

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-28 22:22:39 +08:00
2026-04-26 11:54:01 +08:00
2026-04-23 23:42:21 +08:00
2026-04-26 11:54:01 +08:00

FacereDataset

Facere 专有模型训练与硬件设计知识库提供数据支撑的开源硬件设计数据集。

目标

采集、清洗、结构化互联网公开可用的硬件设计资产原理图、PCB、BOM、Gerber、3D 模型、固件、文档),输出:

  1. 训练数据集:可直接喂给 LLM / 多模态模型做预训练、SFT、RAG 的结构化语料。
  2. 检索型知识库:按元器件、拓扑、应用领域可查的设计参考库。
  3. 派生产物元件封装库、常见子电路模板、BOM 成本曲线等。

数据来源(第一批)

站点 URL 覆盖 许可 复杂度 登录态
立创开源平台 oshwhub.com 12 493 公开项目(附件 + 元数据) GPL 3.0 / Public Domain / CC-BY-SA 为主 不需要
立创 EDA 工程源 u.lceda.cn 原理图 + PCB + 组件 JSON 同 oshwhub 项目 需要(合法账号,见 CLAUDE.md
HF bshada/open-schematics huggingface.co 10K+ KiCad 已预处理 schematics CC-BY-4.0 极低(整包镜像) 不需要
GitHub github.com KiCad / EasyEDA repo 各 repo 自定 gh API 不需要
Hackaday.io hackaday.io 项目叙事 + 文件 作者自定 不需要
CERN OHR ohwr.org 高质量工业级 CERN-OHL 不需要
Wikifactory wikifactory.com 社区项目 作者自定 不需要

运行环境:专用云服务器(广州),登录凭据集中在 ~/.secrets/。详情见 docs/infra.md(部署后创建)。

详细爬取计划见 plan.md;当前已入库项目清单见 projects.md

仓库结构

FacereDataset/
├── README.md        项目简介(本文件)
├── CLAUDE.md        Claude Code 项目级指令
├── plan.md          分阶段爬取与处理计划
├── log.md           执行日志(时间倒序)
├── crawlers/        各站点爬虫(一站一子包)
├── schemas/         统一数据 schemaproject.schema.json
├── scripts/         去重、格式转换、完整性校验工具
├── data/            数据产出raw/ processed/,大文件走 LFS 或外部存储)
└── docs/            设计笔记、法律合规、数据字典

合法与伦理

  • 产出结果用于研究,不公开,不再分发
  • 只抓取公开可访问、标注为开源或明确允许再分发的内容。
  • 每条记录保留 source_urlauthorlicensecrawled_at 作溯源。
  • 后续按许可证逐条核对清洗CC-BY 要求署名CC-BY-SA 要求同许可分享,等)。

快速开始

# 克隆
git clone https://git.deepknow.site/Facere/FacereDataset.git
cd FacereDataset

# 安装Python 3.11+uv
uv sync

# 运行某个爬虫
uv run python -m crawlers.oshwhub --limit 10

当前处于骨架初始化阶段,爬虫尚未实现。见 plan.md Phase 1。

维护

  • 主要维护者Charlesgit.deepknow.site/Knowit
  • 远端:git.deepknow.site/Facere/FacereDataset
  • 问题追踪Gitea Issues
Description
爬取立创开源平台等互联网公开硬件设计,作为数据库与专有模型训练数据集,为Facere提供数据支持
Readme 783 MiB
2026-04-30 19:15:55 +08:00
Languages
Python 100%