Ommo Technologies 最近拿下了数千万美元 A 轮融资核心卖点是给机器人装上“空间直觉”。如果只看新闻标题可能觉得这是又一家做算法的创业公司但拆开看这条赛道正好踩在具身智能和空间 AI 的共同节点上机器人要先知道自己在哪里、周围有什么、接下来能不能走过去后面所有动作才有意义。这篇文章不从融资 PPT 出发而是从工程视角拆解“空间直觉”到底是什么然后给出一套可以快速上手的仿真验证流程。你会看到在 ROS2 环境下如何搭建一个最小可用的建图、定位、导航和避障系统如何用批量场景测试它的稳定性以及资源受限平台上该怎么做减法。无论你是做工业搬运机器人、扫地机器人还是刚接触 ROS2 机器人开发这条路径都能提供一个相对完整的参照。1. 核心能力速览“空间直觉”不是一个可以被直接安装的功能包它通常是感知、建图、定位、规划多个模块的组合。下面这张表把这类系统的常见能力、计算平台和接口方式做了一个速览信息来自公开技术实践具体参数以 Ommo 官方发布为准。能力项说明技术方向机器人空间感知、自主定位、地图构建、路径规划典型功能空间理解、SLAM 建图、重定位、动态避障、目标可达性判断常见传感器RGB/RGB-D 相机、LiDAR、IMU、轮式里程计计算平台x86 工控机、ARM 边缘板、MCU资源受限场景是否需要 GPU基础 SLAM / 导航不需要语义感知、场景理解可选 GPU常用开发框架ROS2、Nav2、SLAM Toolbox、Cartographer、自定义深度学习模型对外接口ROS2 话题 / 服务 / 动作rosbridge 可转 HTTP / WebSocket批量任务多场景仿真、批量导航测试、日志回放和指标统计硬件门槛仿真环境普通 PC 即可真机需要传感器和电机控制单元适合读者机器人算法工程师、ROS 开发者、具身智能研究者从实际部署来看这类系统往往不是一个模型或者一个软件包而是一条流水线传感器数据进来先做预处理再进入 SLAM 或空间感知模块输出结果交给规划模块去执行。这也是为什么“空间直觉”听起来很概念但落地时要照顾的点非常多。2. 机器人“空间直觉”是什么为什么重要“空间直觉”可以拆成四个层次空间感知、空间记忆、自我定位、运动预测与规划。空间感知解决的是“我周围有什么”。最基础的是激光雷达或深度相机提供的几何信息更进一步是语义信息比如把环境中的物体识别成墙壁、货架、行人、车辆的轮廓。空间记忆解决的是“环境长什么样”。系统需要把多次观测拼成一张一致的地图常见表示有栅格地图、点云地图、拓扑地图和语义地图。自我定位解决的是“我现在在哪”这也是 SLAM 的核心任务。运动预测与规划解决的是“我接下来怎么走”包括全局路径搜索、局部速度规划以及动态障碍避让。这四个层次合在一起才让机器人表现出“空间直觉”。没有这套能力机器人只能沿着预设轨迹走有了这套能力它才能对环境变化做出实时反应。比如一个仓储搬运机器人如果只知道走固定路径地面上多了一个纸箱就可能卡住但如果它能感知障碍、重新规划路径就能绕过去继续执行任务。这正是“空间直觉”在工业场景中最直接的工程价值。从 Ommo Technologies 获得融资这件事来看资本对空间 AI 和具身智能的关注还在升温。机器人的“大脑”不能只停在语言理解和任务规划上还要有对物理空间的基本判断能力。之后无论是人形机器人还是工业机械臂空间感知和导航都会成为基础模块。对开发者来说现在开始积累相关技术栈是一条比较稳的路径。2.1 空间感知与语义理解空间感知是数据入口。几何感知可以通过 2D 激光雷达、3D LiDAR、双目相机、RGB-D 相机实现语义感知则需要深度模型参与。常见的做法是把目标检测或语义分割模型挂在感知前级输出物体类别和位置再把这些信息融合到地图中。这样做的好处是机器人在路径规划时不仅“看到障碍物”还“知道障碍物是什么”比如“人”和“箱子”会导致不同避障策略。从实际经验看先不要急着上语义模型。第一步应该把几何 SLAM 和导航跑通确认基础定位精度和地图质量。语义信息可以等到基础系统稳定后再逐步叠加否则你很难定位到是视觉模型的问题还是 SLAM 漂移的问题。2.2 空间记忆与地图表示地图是空间记忆的载体。2D 栅格地图适合室内轮式机器人计算量小Nav2 原生支持3D 点云地图适合复杂地形或人形机器人但占用资源高语义地图则适合需要与环境对象交互的任务。选择地图表示时要考虑控制器的算力。如果目标是资源受限机器人比如用 ARM 开发板跑导航2D 栅格地图通常是更稳妥的选择。地图构建不是一次性工作。真实环境会变化机器人还要具备重定位和地图更新能力。工程上常用多地图切换或者动态代价地图来处理环境变化。比如在 Nav2 中全局代价地图和局部代价地图是分离的局部地图可以实时更新全局地图则定期重建或切换。3. 适用场景与使用边界“空间直觉”适合的应用场景有几个共同点环境有一定结构性、机器人需要移动、任务需要应对未知障碍。这类系统的典型场景包括仓储物流场景搬运机器人需要在货架、通道、操作台之间规划路径并避开临时出现的障碍物。工业搬运场景AGV/AMR 在车间里运输物料对定位精度和重复作业稳定性要求较高。巡检场景机器人在变电站、数据中心、机房等环境中按路线巡检需要识别仪表、设备状态和异常物体。家庭服务场景扫地机器人、陪伴机器人需要理解家庭布局并进行区域划分。人形机器人研发空间感知是人形机器人运动控制的基础尤其是避障和步态规划。使用边界也要提前想清楚。高动态、人车混杂的开放环境比如繁忙街道上的配送机器人对感知和决策要求非常高目前用通用空间感知模块很难达到安全级别。涉及高速运动的场景机器人需要功能安全认证不能只靠一个 SLAM 节点。另外如果设备装有摄像头采集到人脸、车牌、室内布局等信息必须做隐私保护不能随意留存或上传地图数据。合规方面要强调涉及摄像头采集时要有明确授权涉及人脸等敏感生物信息时要脱敏地图数据可能包含客户场所的结构信息对外输出前要经过合规评估。测试尽量先在高仿真的虚拟环境里完成再逐步过渡到真实受限环境。4. 环境准备与前置条件如果你想快速验证“空间直觉”的基础流程最合适的方式是先搭一套仿真环境。仿真环境的好处是可控、可重复、不需要担心硬件损坏。这里给出一个常见的组合Ubuntu 22.04 ROS2 Humble Gazebo TurtleBot3 Nav2。前置条件包括64 位操作系统推荐 Ubuntu 22.04 LTS。至少 8GB 内存建议 16GB 以上。硬盘空间至少 20GB仿真模型、日志和地图文件都会占用空间。如果后续要跑语义感知模型建议配备 NVIDIA GPU但基础 SLAM 和导航并不需要。首先安装 ROS2 Humble。下面命令给出的是基础桌面版并附带 Gazebo、Nav2、Cartographer 和 TurtleBot3 仿真包sudo apt update sudo apt install -y \ ros-humble-desktop \ ros-humble-gazebo-ros-pkgs \ ros-humble-nav2-bringup \ ros-humble-cartographer \ ros-humble-turtlebot3-gazebo \ ros-humble-turtlebot3-cartographer \ ros-humble-turtlebot3-navigation2安装完成后添加环境变量echo source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc如果你用的是 Ubuntu 20.04 和 ROS Noetic也可以按对应版本替换包名核心思路一样。需要特别注意的是ROS1 和 ROS2 命令、launch 文件格式都有差异别混用。5. 从零搭建最小“空间直觉”验证环境这里用 TurtleBot3 仿真环境搭建一套最小可用的空间感知系统。整体流程是启动仿真世界启动 SLAM 建图遥控机器人走一圈保存地图最后启动导航。首先设置机器人模型export TURTLEBOT3_MODELburger打开终端启动 Gazebo 仿真世界ros2 launch turtlebot3_gazebo turtlebot3_world.launch.py再打开第二个终端启动 Cartographer SLAMexport TURTLEBOT3_MODELburger ros2 launch turtlebot3_cartographer cartographer.launch.py打开第三个终端启动键盘遥控让机器人缓慢走遍地图边界。这一步是在给系统建“空间记忆”export TURTLEBOT3_MODELburger ros2 run turtlebot3_teleop teleop_keyboard建图过程中可以在 RViz 界面里看到激光点云和地图逐渐展开。判断地图是否可用主要看墙体线条是否连续、边界是否闭合、有没有明显重影。地图构建完成后保存地图mkdir -p ~/map ros2 run nav2_map_server map_saver_cli -f ~/map/turtlebot3_map最后启动导航export TURTLEBOT3_MODELburger ros2 launch turtlebot3_navigation2 navigation2.launch.py map:/home/你的用户名/map/turtlebot3_map.yaml这里要注意map 参数路径必须写成绝对路径建议按下 TAB 键补全。导航启动后在 RViz 中点击“2D Goal Pose”在地图上指定一个目标点机器人就会规划路径并移动过去。整个过程就是一次最小化的“空间直觉”验证它能知道自己在哪、能读地图、能算路径、能避开障碍。6. 功能测试与效果验证仿真跑通后还需要做系统化的功能测试。单独点一个目标点不能说明系统稳定应该用多组测试用例覆盖常见问题。测试维度测试目的操作步骤判断标准建图质量验证空间感知和地图一致性遥控机器人走两圈观察地图是否有重影墙体连续、边界闭合、无明显错位重定位验证机器人在地图中的定位能力停止机器人原地旋转参考粒子滤波是否收敛机器人位置与地图对齐全局导航验证路径规划能力设置不同距离目标点重复 10 次每次都能生成可行路径并到达动态避障验证局部规划能力在路径中间放一个临时障碍物机器人停下并绕行里程计漂移验证传感器融合稳定性长时间运行观察 /odom 与 /map 偏差漂移在可接受范围内除了手工测试也可以写一个简单的 Python 脚本通过 Nav2 的 Action 接口自动向机器人发布多个导航目标。下面是一个通用模板import rclpy from rclpy.node import Node from geometry_msgs.msg import PoseStamped from nav2_msgs.action import NavigateToPose from rclpy.action import ActionClient class NavClient(Node): def __init__(self): super().__init__(nav_client) self.client ActionClient(self, NavigateToPose, /navigate_to_pose) def send_goal(self, x, y): goal_msg NavigateToPose.Goal() goal_msg.pose.header.frame_id map goal_msg.pose.pose.position.x x goal_msg.pose.pose.position.y y goal_msg.pose.pose.orientation.w 1.0 self.client.wait_for_server() self.client.send_goal_async(goal_msg) self.get_logger().info(fSend goal: x{x}, y{y}) def main(): rclpy.init() node NavClient() node.send_goal(1.0, 0.5) rclpy.spin(node) if __name__ __main__: main()如果要批量测试可以写一个 Shell 循环每个场景跑一次导航把日志记录下来for scene in scene1 scene2 scene3; do echo Start $scene ros2 launch your_nav_launch scene:$scene ros2 bag record /odom /scan /map /goal_pose -o ${scene}.bag sleep 5 done批量测试的价值是能暴露偶发问题比如十分钟稳定半小时后开始漂移这类问题只靠单次演示不容易发现。7. 接口 API 与批量任务机器人“空间直觉”能力如果只停留在仿真界面里价值有限。实际产品中它需要把状态暴露给上层业务系统比如调度平台、监控后台或人机界面。ROS2 的接口机制天然适合做这件事。最基本的接口是话题Topic用于持续的数据流比如激光数据/scan、里程计/odom、地图/map。命令和服务Service用于一次性请求比如调整地图参数。动作Action适合需要跟踪进度的长期任务比如导航。查看当前所有接口ros2 topic list ros2 service list ros2 action list查看某个话题的频率ros2 topic hz /scan如果你想快速验证底盘控制接口可以通过命令行发送运动指令ros2 topic pub /cmd_vel geometry_msgs/msg/Twist \ {linear: {x: 0.2, y: 0.0, z: 0.0}, angular: {z: 0.1}}如果上层系统不是 ROS 生态可以通过 rosbridge_server 把 ROS2 接口转成 WebSocket 协议再用 HTTP/JSON 与 Web 端或者其他语言通信sudo apt install ros-humble-rosbridge-server ros2 launch rosbridge_server rosbridge_websocket_launch.xml这样前端可以实时拿到机器人位置、地图状态也可以发送导航指令。接口设计的具体 JSON 格式需要参考 rosbridge 官方协议一般都会遵循{op: call_service, service: /navigate_to_pose, args: {...}}这类结构建议在自己环境里先抓包验证。批量任务方面建议把“单点导航验证”升级成“场景回归集”。具体做法是把不同地图、不同起点、不同目标点组织成配置目录用一个脚本统一跑并记录每次的导航时间、路径长度、是否碰撞、是否超时。这样做的好处是在改动 SLAM 参数、导航参数或感知模型后能快速对比前后效果。8. 资源占用与性能观察“空间直觉”系统跑起来之后最需要关注的是资源占用和实时性。机器人平台不像服务器CPU、内存、磁盘都有限尤其资源受限机器人上更要精细管理。观察 CPU 和内存占用htop观察 GPU 和显存占用如果跑了语义感知模型nvidia-smi观察关键话题的发布频率是否正常ros2 topic hz /odom ros2 topic hz /scan ros2 topic hz /map如果频率明显低于预期比如激光雷达数据只有 2Hz 而传感器支持 10Hz说明链路中有某个环节处理不过来。最常见的瓶颈出现在建图节点 CPU 过高、深度学习模型推理耗时、磁盘写入日志占满 IO。降低资源占用的通用思路降采样降低激光雷达或深度相机的点云分辨率。降频率降低地图更新频率和里程计发布频率。减模块先关闭 RViz 可视化只保留必要节点。选轻量算法在低算力设备上用 gmapping 替代部分重负载 SLAM或使用轻量级视觉里程计。模型压缩如果使用深度学习模型尝试 TensorRT、ONNX Runtime 或更小的网络结构。实际资源占用数值会因传感器、算法、CPU/GPU 型号差异很大不能照搬别人的数字。正确做法是固定测试场景记录当前占用基线再在优化后对比同一组数据。没有基线的优化容易越调越偏。9. 常见问题与排查方法下面列出“空间直觉”系统测试中比较容易踩的坑。问题现象可能原因排查方式解决方案启动后 RViz 没有地图SLAM 节点未启动或 TF 缺失ros2 topic list、ros2 run tf2_tools view_frames确认 Cartographer 启动成功检查 TF 树地图墙体重影里程计误差大或传感器外参不准查看 /odom 与 /map 偏差标定里程计、校正激光雷达安装角度导航目标无法到达全局地图有问题或代价地图膨胀过大查看全局代价地图和局部代价地图调整膨胀半径重建地图机器人原地旋转局部规划参数不合理或全局路径卡死观察 /local_plan 和 /global_plan调整 Nav2 的 TebLocalPlanner 或 DWB 参数启动启动多次后端口冲突ROS_DOMAIN_ID 未隔离检查两个场景是否复用同一域 ID设置不同的ROS_DOMAIN_ID线程 CPU 占用率过高算法复杂度高或缺少硬件加速用top定位进程降低话题频率、减少点云分辨率、启用 GPU深度学习模型显存不足输入分辨率或 batch 过大nvidia-smi查看显存降低推理分辨率、减小 batch、改用 TensorRT批量任务中途卡死目标点不可达或导航超时未处理查看导航日志和 TF 状态增加超时重试逻辑跳过不可达目标这些坑之间往往是关联的。地图质量差会导致导航失败导航失败又会被误判成规划参数问题。排查时先从传感器数据和 TF 树入手确认定位没问题再去看规划相关参数。10. 最佳实践与使用建议从开发到部署下面几条建议比较关键。第一先仿真后真机。仿真环境没有传感器磨损和安全隐患可以快速验证算法逻辑。但仿真算法参数不能直接搬去真机传感器噪声、底盘响应差异很大真机调试要重新标定。第二保留最小可运行配置。每次做复杂功能迭代前确认仓库里有一套已知可用的启动命令和参数文件。一旦新改动导致系统异常能快速回退到稳定版本。第三数据和日志分目录管理。把地图文件、传感器 bag、日志、模型文件分开存放批量测试时按时间戳命名。这能避免后期分析问题时定位不到数据来源。第四批量任务必须有日志和失败重试。机器人长时间运行时网络抖动、目标点不可达、导航超时都会发生。批量脚本要记录每一步状态失败时按照设定策略重试或跳过不能因为一个点失败就中断整个任务。第五接口服务要限制访问范围。如果通过 rosbridge 或 HTTP 网关暴露机器人接口必须做权限校验避免未授权指令直接下发到底盘。物理设备控制接口尤其要做好安全护栏。第六涉及人脸、声音、版权素材、场景地图时必须确认授权。机器人感知系统可能记录大量环境信息这些数据可能涉及隐私和商业秘密。不管开发阶段还是商用阶段合规问题都不能忽略。第七模型和算法选型要兼顾部署边界。如果目标是资源受限机器人采用高精度大模型之前先估算推理耗时和内存占用。宁可把模型剪小也要保证实时性。11. 总结与下一步Ommo Technologies 获数千万美元 A 轮融资说明“空间直觉”这个方向已经被资本市场认可。但从工程落地角度看机器人空间感知并不是一个开箱即用的功能它需要把感知、建图、定位、规划、接口和批量验证串起来。如果你只是刚接触这个方向下一步可以先把 ROS2 TurtleBot3 仿真环境搭起来跑通建图和导航理解 SLAM 和 Nav2 的基本数据流。这是成本最低、见效最快的第一步。之后再根据你的实际场景替换传感器、引入语义感知模型、调整导航策略最终把空间直觉模块接入自己的机器人产品。这篇文章里的所有命令和代码都可以作为基础模板实际操作时按你的环境版本、地图路径和机器人模型调整。建议收藏备用之后做机器人导航、空间感知或具身智能相关项目时会经常需要回来翻这组流程和排查清单。