简介这份资源是面向机器人知识表示与语义建模方向研究者、开发者及学生的 KnowRob 知识库配套数据存储库用于集中存放地图、机器人日志与对象模型等样本数据解决实验数据分散、难以跨项目复用的问题。压缩包共 406 个文件约 52.4MB以 353 个 jpg 图像、35 个 owl 本体文件为主另含 md、xml、sh、Dockerfile 等配置与说明文件图像多为 Kinect 头部 RGB 采集帧owl 文件则承载语义描述。数据按动作、日志、地图、对象四类子文件夹组织动作目录提供带任务描述的 OWL 文件类似 RoboEarth 的动作配方日志记录机器人或人类执行任务的过程地图为语义环境地图对象目录给出描述语义属性、部件组成或 CAD 模型链接的本体文件。将数据与主代码分离存储便于在不同上下文中重复使用与评估。目前已有 207 人学习下载适合需要测试数据、评估数据或通用实验数据集的读者参考。1. 机器人知识库的数据底座knowrob_data 到底在存什么很多做机器人语义推理的团队第一次接触 KnowRob 时都会卡在同一个地方本体文件写好了推理规则也配了可一跑查询就报错——不是找不到地图就是日志时间戳对不上。问题往往不在推理引擎而在数据层。knowrob_data 这类数据存储库解决的正是这件事它把地图、机器人日志、对象模型这些异构资产按 KnowRob 知识库能消费的方式组织起来让本体里的符号真正落到可查询的实例上。它适合已经跑通 KnowRob 基础推理、准备接入真实场景数据的开发者也适合想理解「知识图谱 机器人」如何落地的人。核心矛盾只有一个知识库要的是结构化三元组而机器人产出的原始数据是点云、rosbag、CAD 文件中间这层转换就是 knowrob_data 的价值所在。2. 地图、日志、对象模型三类数据的组织逻辑与选型2.1 为什么不能把原始文件直接丢进知识库KnowRob 的推理建立在 OWL 本体之上查询走的是 SPARQL 或 Prolog 谓词。原始的点云地图是二进制栅格rosbag 是带时间戳的消息流CAD 模型是网格顶点——这些格式本体解析器一个都读不懂。常见做法是在两者之间加一层「语义标注」地图不是存成图片而是存成「某楼层某房间占据栅格 坐标系变换 语义标签」的组合日志不是存成 bag而是抽取成「某时刻某物体在某位置」的事件三元组对象模型不是存 STL而是存「物体类别 尺寸 可抓取面 关联本体类」。这层转换决定了后续查询能不能写。我一般会先问三个问题这个数据要支持什么查询查询里会用到哪些本体类时间维度要不要保留答案不同存储结构完全不一样。2.2 地图数据的存放结构地图在 knowrob_data 里通常不是一个文件而是一个目录加一份描述。以常见的占据栅格地图为例目录结构大致是这样maps/ building_a/ floor_1/ map.pgm # 占据栅格图像 map.yaml # 分辨率、原点、阈值 semantic.ttl # 房间、走廊、门的本体实例 transform.json # 地图坐标系到机器人基座的变换map.yaml是 ROS 地图的标准格式关键参数只有几个image: map.pgm resolution: 0.05 # 米/像素决定地图精度 origin: [-10.0, -10.0, 0.0] # 地图左下角在全局坐标的位置 negate: 0 occupied_thresh: 0.65 free_thresh: 0.196resolution设成 0.05 意味着每个像素代表 5 厘米。这个值不是随便定的设太小地图文件巨大推理时加载慢设太大窄通道会被抹掉导航查询会误判。我一般按机器人底盘宽度来定保证最窄通道至少占 3 个像素。semantic.ttl才是 KnowRob 真正消费的部分它把栅格区域和本体类关联起来prefix knowrob: http://knowrob.org/kb/knowrob.owl# . prefix building: http://example.org/building_a# . building:Room101 a knowrob:Room ; knowrob:hasWidth 4.2^^xsd:double ; knowrob:hasLength 5.8^^xsd:double ; knowrob:containedIn building:Floor1 . building:Floor1 a knowrob:Floor ; knowrob:hasMap building:Map_Floor1 .这段本体里Room101不是凭空写的它的宽长来自对map.pgm中对应区域的像素统计。常见做法是先用标注工具在栅格上框出房间再导出边界像素数乘以resolution得到实际尺寸。坑在于如果origin设错了房间坐标会整体偏移查询「机器人在哪个房间」时永远返回错误结果。2.3 机器人日志的抽取与时间对齐日志数据最麻烦的不是存储是时间对齐。机器人上多个传感器各有各的时钟rosbag 里记录的是接收时间不是采集时间。直接拿接收时间做推理会出现「机器人已经离开房间日志还说它在房间里」的玄学现象。我的做法是分两步先做时间戳归一化再做事件抽取。归一化用 bag 里的 header.stamp 而不是 bag 记录时间import rosbag from datetime import datetime def extract_events(bag_path, topic): events [] with rosbag.Bag(bag_path, r) as bag: for topic_name, msg, t in bag.read_messages(topics[topic]): # 优先用消息头时间戳回退到 bag 记录时间 if hasattr(msg, header): stamp msg.header.stamp.to_sec() else: stamp t.to_sec() events.append({ time: stamp, topic: topic_name, data: msg }) # 按时间排序消除多话题交错导致的乱序 events.sort(keylambda e: e[time]) return events这段代码的关键在msg.header.stamp。很多消息类型如sensor_msgs/Image、geometry_msgs/PoseStamped都带 header但std_msgs/String这类没有。回退逻辑必须有否则遇到无头消息直接崩。排序也不能省多话题同时读取时bag 按记录顺序返回不保证时间单调。抽取成事件后再映射到本体实例。比如一条位姿消息变成building:RobotPose_001 a knowrob:RobotPose ; knowrob:atTime 1710000000.0^^xsd:double ; knowrob:hasPosition building:Position_001 .这里atTime用 Unix 秒和 KnowRob 的时间推理谓词对齐。如果本体里定义的时间区间用的是其他格式查询会静默返回空结果——这是最常见的翻车点之一。2.4 对象模型的语义标注对象模型这块很多人以为存个 CAD 文件就够了。但 KnowRob 要回答的是「这个杯子能不能抓」「它属于哪个类别」不是「它长什么样」。所以对象模型在 knowrob_data 里通常包含三部分几何文件STL/OBJ、语义描述TTL、抓取关联JSON 或 TTL。语义描述里最重要的是类别和属性prefix knowrob: http://knowrob.org/kb/knowrob.owl# . prefix obj: http://example.org/objects# . obj:Cup_001 a knowrob:Cup ; knowrob:hasDiameter 0.08^^xsd:double ; knowrob:hasHeight 0.10^^xsd:double ; knowrob:hasMaterial knowrob:Ceramic ; knowrob:graspableBy knowrob:ParallelGripper .graspableBy这个属性决定了抓取规划能不能查到它。如果本体里没有定义对应的夹爪类或者属性名拼错查询会返回空。我一般会在写入前用 SPARQL 做一次校验SELECT ?obj WHERE { ?obj a knowrob:Cup . FILTER NOT EXISTS { ?obj knowrob:graspableBy ?gripper } }返回非空就说明有杯子没标注抓取方式需要补数据。这个校验放在数据入库流程里比事后排查省事得多。3. 从原始数据到可查询知识库完整落地步骤3.1 环境准备与目录约定KnowRob 本身是 ROS 生态里的包常见做法是放在 catkin 工作空间里。数据存储库不一定要和代码放一起但目录结构要固定否则脚本里的相对路径会到处漂。我一般这样组织knowrob_ws/ src/ knowrob/ # 推理引擎 knowrob_data/ # 数据存储库 maps/ logs/ objects/ ontology/ # 本体文件 scripts/ import_maps.py import_logs.py validate.pyontology/里放的是自定义本体扩展不要直接改 KnowRob 自带的本体文件。升级时自带文件会被覆盖自定义内容放独立文件再 import这是血泪经验。环境变量要设两个export KNOWROB_DATA_PATH/path/to/knowrob_ws/src/knowrob_data export ROS_PACKAGE_PATH$ROS_PACKAGE_PATH:/path/to/knowrob_ws/srcKNOWROB_DATA_PATH不是 KnowRob 官方变量是我在脚本里统一读取的约定。好处是换机器时只改一处不用翻遍代码找硬编码路径。3.2 地图导入脚本与参数说明地图导入的核心是把栅格和语义标注关联起来。下面这个脚本做三件事读 yaml、统计房间像素、生成 TTL。import yaml import numpy as np from PIL import Image import os def import_map(map_dir, output_ttl): # 读取地图配置 with open(os.path.join(map_dir, map.yaml)) as f: config yaml.safe_load(f) resolution config[resolution] origin config[origin] # 加载栅格occupied_thresh 以上算障碍 img np.array(Image.open(os.path.join(map_dir, config[image]))) occupied img (1 - config[occupied_thresh]) * 255 # 统计自由空间像素换算成面积 free_pixels np.sum(~occupied) area free_pixels * resolution * resolution # 生成 TTL 片段 ttl f prefix knowrob: http://knowrob.org/kb/knowrob.owl# . prefix map: http://example.org/map# . map:FloorMap a knowrob:OccupancyGridMap ; knowrob:resolution {resolution}^^xsd:double ; knowrob:originX {origin[0]}^^xsd:double ; knowrob:originY {origin[1]}^^xsd:double ; knowrob:freeArea {area:.2f}^^xsd:double . with open(output_ttl, w) as f: f.write(ttl) return areaoccupied_thresh的判断逻辑要注意ROS 地图里像素值 0 是障碍255 是自由中间是未知。img (1 - occupied_thresh) * 255这个写法对应的是「像素值低于阈值算障碍」。如果地图用了negate: 1黑白反过来这个判断要跟着改否则障碍和自由空间会完全颠倒。origin的第三个值是 z 轴二维地图里通常是 0但有些建图工具会写成高度偏移。导入时如果发现房间坐标整体偏高或偏低先查这个值。3.3 日志抽取与时间戳归一化日志导入比地图多一层时间处理。下面脚本把位姿话题抽成事件三元组import rosbag import os def import_pose_log(bag_path, output_ttl, topic/robot_pose): events [] with rosbag.Bag(bag_path, r) as bag: for _, msg, t in bag.read_messages(topics[topic]): # 位姿消息带 header用采集时间 stamp msg.header.stamp.to_sec() pos msg.pose.position events.append((stamp, pos.x, pos.y, pos.z)) # 按时间排序 events.sort(keylambda e: e[0]) lines [ prefix knowrob: http://knowrob.org/kb/knowrob.owl# ., prefix log: http://example.org/log# ., ] for i, (stamp, x, y, z) in enumerate(events): lines.append(flog:Pose_{i:06d} a knowrob:RobotPose ;) lines.append(f knowrob:atTime {stamp:.3f}^^xsd:double ;) lines.append(f knowrob:x {x:.3f}^^xsd:double ;) lines.append(f knowrob:y {y:.3f}^^xsd:double ;) lines.append(f knowrob:z {z:.3f}^^xsd:double .) lines.append() with open(output_ttl, w) as f: f.write(\n.join(lines)) return len(events)atTime保留三位小数对应毫秒精度。如果机器人控制周期是 10ms 以内这个精度不够要改成六位。但精度越高TTL 文件越大推理时加载越慢。我一般按控制周期来定100Hz 用三位1kHz 用六位。事件数量也要控制。一段十分钟的日志100Hz 采样就是六万条三元组。全量导入后 SPARQL 查询会明显变慢。常见做法是按距离或时间做抽稀机器人移动超过 5 厘米才记一条或者每秒最多记一条。抽稀逻辑放在events.sort之后# 抽稀距离上一条超过 0.05 米才保留 filtered [] last None for e in events: if last is None or ((e[1]-last[1])**2 (e[2]-last[2])**2) ** 0.5 0.05: filtered.append(e) last e这个阈值不是固定的取决于场景。大范围导航用 0.1 米精细操作要 0.01 米。3.4 对象模型入库与本体校验对象模型入库前先确认本体里有没有对应的类。没有的话要么扩展本体要么把对象归到已有类下。扩展本体是更干净的做法但要注意命名空间不要和 KnowRob 自带的重名。from rdflib import Graph, Namespace, URIRef, Literal from rdflib.namespace import RDF, XSD def add_object(ttl_path, obj_id, obj_class, diameter, height): g Graph() g.parse(ttl_path, formatturtle) KNOWROB Namespace(http://knowrob.org/kb/knowrob.owl#) OBJ Namespace(http://example.org/objects#) obj OBJ[obj_id] g.add((obj, RDF.type, KNOWROB[obj_class])) g.add((obj, KNOWROB.hasDiameter, Literal(diameter, datatypeXSD.double))) g.add((obj, KNOWROB.hasHeight, Literal(height, datatypeXSD.double))) g.serialize(ttl_path, formatturtle)obj_class必须是本体里已定义的类比如Cup、Bottle、Box。如果传了一个不存在的类名rdflib 不会报错但后续推理查不到。所以入库后要跑一次校验查询确认新对象能被推理机识别。校验用 SPARQLSELECT ?obj ?class WHERE { ?obj a ?class . FILTER(STRSTARTS(STR(?class), http://knowrob.org/kb/knowrob.owl#)) }返回结果里应该包含刚入库的对象。如果没有检查命名空间和类名拼写。4. 避坑与排查数据入库后查询为空的五个原因4.1 现象SPARQL 查询返回空但 TTL 文件里明明有数据原因通常是命名空间不一致。KnowRob 自带本体用的命名空间是http://knowrob.org/kb/knowrob.owl#如果自定义 TTL 里写成了http://knowrob.org/kb/knowrob.owl少了末尾的#rdflib 会当成两个不同的命名空间查询自然匹配不上。解决统一用常量定义命名空间不要手写字符串。Python 里用Namespace(http://knowrob.org/kb/knowrob.owl#)TTL 里用prefix knowrob: http://knowrob.org/kb/knowrob.owl# .两边保持一致。4.2 现象地图房间坐标整体偏移原因多半是origin和实际建图起点不一致。有些建图工具把 origin 设成地图左下角有些设成机器人起始位置。导入前先确认建图时的配置或者用已知参照物反推在地图上找一个实际坐标已知的点看它的像素坐标换算后和实际值差多少差值就是 origin 的偏移量。解决在map.yaml里修正 origin重新导入。不要试图在 TTL 里加偏移量补偿那样会让后续所有坐标计算都变复杂。4.3 现象日志时间戳和实际事件对不上原因是用了 bag 记录时间而不是消息头时间。rosbag 在录制时如果系统负载高记录时间会比采集时间晚几十毫秒甚至更多。对于慢速移动的机器人这点偏差可能不明显对于快速操作就会导致「机器人已经抓完日志还在说它在靠近」。解决统一用msg.header.stamp。没有 header 的消息类型在录制时就该考虑加时间戳字段而不是事后用记录时间凑合。4.4 现象对象模型入库后推理机不识别原因是类名不在本体里或者属性名拼写和本体定义不一致。KnowRob 的属性命名有固定风格比如hasDiameter而不是diameter。拼错一个字母推理就静默失败。解决入库前用g.parse加载 KnowRob 本体检查目标类是否存在from rdflib import Graph, Namespace g Graph() g.parse(knowrob.owl, formatxml) KNOWROB Namespace(http://knowrob.org/kb/knowrob.owl#) if (None, RDF.type, KNOWROB[Cup]) not in g: raise ValueError(Cup 类不在本体中)这个检查放在入库脚本开头比事后排查省时间。4.5 现象数据量大了之后查询超时原因是三元组数量超过推理机的内存处理能力。KnowRob 默认配置下十万条以内的三元组查询还算流畅超过之后每次 SPARQL 都要几秒甚至更久。解决分两层。第一层是抽稀日志和位姿数据按距离或时间降采样。第二层是分区按楼层或时间段拆成多个 TTL 文件查询时只加载相关分区。KnowRob 支持从多个文件加载本体不需要合并成一个大文件。5. 让数据真正可用的两个进阶技巧5.1 用 SHACL 做入库前校验数据入库后才发现问题排查成本很高。更好的做法是在入库前用 SHACL 做结构校验。SHACL 能定义「一个 Cup 必须有 diameter 和 height」这类约束校验不通过就不让入库。prefix sh: http://www.w3.org/ns/shacl# . prefix knowrob: http://knowrob.org/kb/knowrob.owl# . knowrob:CupShape a sh:NodeShape ; sh:targetClass knowrob:Cup ; sh:property [ sh:path knowrob:hasDiameter ; sh:minCount 1 ; sh:datatype xsd:double ; ] ; sh:property [ sh:path knowrob:hasHeight ; sh:minCount 1 ; sh:datatype xsd:double ; ] .校验脚本用 pyshaclfrom pyshacl import validate from rdflib import Graph data Graph() data.parse(objects.ttl, formatturtle) shapes Graph() shapes.parse(shapes.ttl, formatturtle) conforms, _, report validate(data, shacl_graphshapes) if not conforms: print(report) raise SystemExit(数据校验失败)sh:minCount 1保证属性至少出现一次sh:datatype保证类型正确。这两个约束能拦住大部分低级错误。校验通过再入库比入库后写查询排查高效得多。5.2 用时间区间查询替代时间点查询KnowRob 的时间推理支持区间查询但很多人只用了时间点。比如「机器人在房间 A 的时间段」这种查询用时间点要遍历所有位姿再判断用区间可以直接匹配。本体里定义时间区间log:InRoomA a knowrob:TimeInterval ; knowrob:startTime 1710000000.0^^xsd:double ; knowrob:endTime 1710000300.0^^xsd:double .查询时用knowrob:during谓词SELECT ?pose WHERE { ?pose a knowrob:RobotPose ; knowrob:atTime ?t . log:InRoomA knowrob:startTime ?s ; knowrob:endTime ?e . FILTER(?t ?s ?t ?e) }这个查询比逐点判断快因为时间区间是预先算好的不需要在查询时做范围扫描。区间怎么算常见做法是按房间边界和机器人轨迹做分段机器人进入房间记 start离开记 end。分段逻辑可以离线跑跑完存成 TTL查询时直接用。我自己的习惯是每次导入新数据前先跑一遍 SHACL 校验再跑一遍时间区间生成最后才入库。这三步顺序不能反反了就要返工。数据层的事后悔药最贵。希望帮到你。本文还有配套的精品资源点击获取