Salem Robotics：让工业巡检机器人更智能
Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
我们是Salem Robotics的创始人，来自UT Austin的机器人研究背景，并在核能领域拥有15年经验，曾在Los Alamos National Laboratory部署自主机器人。我们发现，尽管机器人硬件已非常强大，但要让机器人完成完整的工业流程，仍需要大量人工干预。我们的软件专注于赋予现有移动机器人特定任务的智能，使其能在危险的工业设施中进行测量和物理交互检查。我们采用AI与经典机器人技术结合的方法，在需要语义理解时使用AI，而在需要明确约束和可预测行为时依赖几何规划和控制。我们不制造新硬件，而是为Boston Dynamics等公司的硬件提供专用应用层，实现硬件无关的灵活部署。目前我们专注于核辐射检查，并正在拓展到石油、天然气和危险化学品设施的复杂操作任务。
我们关注的是围绕检查结果形成闭环，而不仅仅是机械臂是否到达了指定姿态。
HN 评论区
31- beckford
关于“与硬件无关”的部分听起来有点像 ROS 2，但可能是在更高层面上。我很想看到一篇关于这方面的文章（顺便给像我这样只是浅尝辄止的机器人爱好者做一些解释）。
不过我也很好奇，“Salem”这个名字是不是先搜过？我第一次看到标题时，以为是在说 Agility Robotics，这家公司位于俄勒冈州的塞勒姆（Salem），目前在 Google 搜索“Salem Robotics”中排在第三位（YouTube 上前 5 个结果中有 4 个也是他们）。
- lesiva
> 我们在需要语义理解和灵活性的地方使用 AI，例如解释非结构化信息，或理解陌生场景中哪些内容与流程相关。一旦系统知道需要执行何种物理交互，我们更倾向于在可能的情况下使用明确的几何、规划、优化和控制……
> 在走廊中导航时，几厘米的误差可能无关紧要，但如果传感器需要保持与曲面垂直，这误差就很重要了。
这是一个非常具体的例子，说明了 AI 的创造力（也就是随机性）在何处会撞墙。随着模型的改进，你认为这种情况会改变吗？还是说，你预期安全关键型/高度特定的任务将始终需要更明确的指令集？
- hic
祝一切顺利！框架非常清晰，而且这确实是一项亟需的服务。我记得 2011 年福岛核事故后不久，离那里不远的地方，当地一家公司面临着极其困难的检测问题，包括在废墟中进行检测。当时有一些机器人能处理部分问题，但它们不在日本，而且无论如何，由于必须迅速行动，最终还是派了人去。据称当时足够安全，但如果有能力更强的机器人，本可以安全得多。
一个技术问题：为了精确扫描表面，我倾向于在传感器旁边给末端执行器装上开关，这样机械臂可以先大致定位到表面上方，然后下压直到开关触发，接着在保持开关触发的状态下进行扫描。基本上就是一种简单的触觉感知。这是传统机器人平滑跟随各种平面和曲面的标准做法。这完全不是反对 AI，整篇讨论似乎都是一种建设性的方法，即针对具体目标混合使用最佳工具。这种方案在你们的场景中不可行吗？
关于你们结尾提出的问题：
> 机器人技术中的抽象边界应该设在哪里？哪些应由机器人制造商提供，哪些属于应用层，哪些不可避免地需要针对特定设施定制？
我非常喜欢“双重 SDK”的做法：一个低层 SDK 用于单独控制执行器和传感器（例如“第 4 条腿的第 2 个电机”），另一个高层 SDK 提供预定义的场景（例如“向前移动”，无论机器人是双足、四旋翼还是类似蛞蝓的形态）。这两种 API 类型通常能让应用层的工作更容易开展……
- a_t48
恭喜发布。我在机器人行业已经待了十年，见过这个边界出现在很多不同的地方。我不确定是否有明确的答案。
自我推广一下：我是 Clipper 的创始人，这是一个面向机器人领域的容器注册表，相比 DockerHub，它的拉取速度快 10 倍，构建速度快 7 倍。我受够了机器人部署要花上一整天，于是自己动手解决了这个问题。如果你对此感兴趣，或者只是想聊聊行内事，欢迎随时交流。
- akshay_akula
恭喜发布。“成功执行轨迹并不意味着检测工作就成功了”这个观点很棒，真正难的是闭环处理测量本身。