启动 HN：Salem Robotics（YC S26）——工业检测机器人的软件
嗨，HN，我们是Salem Robotics的创始人（[salemroboticsinc.com](https://salemroboticsinc.com)）。我们为现有的移动机器人赋予任务特定的智能，使其能够在危险的工业设施中进行调查和物理互动检查。
这里有一个视频，展示了我们在真实机器人硬件上运行的情况，以及我们的一些话：[视频链接](https://youtu.be/U_228h3NE7c)。
我们通过在德克萨斯大学奥斯汀分校的机器人研究进入Salem，并在核领域有着15年的工作经验，其中约10年是在洛斯阿拉莫斯国家实验室开发和部署自主机器人。在过去五年中，我们不断发现同一个问题：虽然机器人硬件变得非常强大，但要让机器人完成一个完整的工业流程仍然需要大量的机器人工作和人工干预。
我们最感兴趣的部分是操控。例如，核污染调查可能需要进行“涂抹”：在表面上擦拭一个定义的区域，以检查可去除的放射性污染。在石油、天然气或化工设施中，LDAR（泄漏检测与修复）检查可能需要在特定的阀门、法兰或连接处移动探测器。其他检查则需要将仪器定位在相对于管道或设备的精确位置和方向。
这些任务可以简单地用“擦拭”、“测量”或“检查”等动词来概括，但要让机器人可靠地完成这些任务则要困难得多。探头可能需要在整个路径中保持与表面垂直，保持与管道的狭窄偏移，或者在保持特定末端执行器方向的同时描绘一个区域。规划者必须在遵循任务几何形状、操控器运动学、关节限制、碰撞和周围环境的情况下找到可行的运动。
我们在这些交互中深入到关节级控制。我们花了很多时间解决的一个问题是，如何快速生成受约束的操控计划，使其能够基于机器人实际观察到的几何形状，而不是要求有人为每个单独的表面、阀门或法兰仔细编写轨迹。
物理世界使这一过程变得复杂。当在走廊中导航时，几厘米的误差可能并不重要，但如果传感器需要保持与曲面垂直，这就变得至关重要。而成功执行轨迹并不一定意味着检查成功。探测器可能会失去对准，接触可能不正确，几何形状可能与模型不同，或者测量本身可能无效。我们关心的是围绕检查结果闭合这个循环，而不仅仅是手臂是否达到了指令姿态。
我们的方法结合了人工智能和经典机器人技术。目前，许多机器人研究和行业关注点正朝着越来越多的端到端学习系统发展，尤其是在类人机器人方面。在安全关键的环境中工作使我们更加意识到，当你想要明确的约束、可预测的行为以及关于机器人能做和不能做的理论保证时，经典方法仍然是多么相关。
我们在语义理解和灵活性有用的地方使用人工智能，例如解释不太结构化的信息或理解在不熟悉场景中与程序相关的内容。一旦系统知道需要执行什么物理交互，我们更倾向于在可能的情况下使用明确的几何形状、规划、优化和控制。我们对这两者的结合感兴趣，而不是试图让机器人技术栈的每个部分都通过学习来实现。
Salem的另一个理念是，我们认为并非每个有用的机器人应用都需要构建一个新的机器人。像波士顿动力这样的公司在构建越来越强大的硬件平台方面表现得非常出色。我们认为在这些硬件之上还有一个特定领域的应用层。相同的基础机器人可能在一个设施中执行核辐射调查，而在另一个设施中进行LDAR检查，但程序、传感器、操控约束、成功条件和输出都是不同的。
这也是我们为何对硬件不特定的原因。我们不期望某一款机器人永远是最佳平台，设施已经拥有不同的硬件。我们更愿意描述检查需要发生的事情，然后将其映射到适合该工作的机器人的能力上。
在与设施接触的过程中，有一件事让我们感到惊讶，那就是许多检查工作流程仍然是手动的。在复杂的核和工业现场，人们仍然需要亲自走访调查路线，一次测量一个，目视检查设备，手动记录结果，有时还根据组件的声音等因素做出判断。一些基本的工作流程对于几十年前从事这项工作的人来说仍然是可以识别的，尽管今天可用的传感器、计算能力和机器人已经截然不同。
我们从核领域的辐射检查开始，因为这是我们最熟悉的行业，同时我们也在石油、天然气和危险化学设施中研究以操控为主的检查问题。技术人员和检查员仍然定义程序、解释结果并做出重要判断。我们试图自动化更多当前需要人工进入环境或手动操作机器人的重复性物理执行。
我们直接向工业设施销售，通常从付费技术验证开始，然后转向持续部署。定价因工作流程而异：验证费用从数万美元到超过10万美元不等，而较大的部署费用则从数十万美元到每台机器人大约50万美元不等。
我们特别想听听HN对机器人技术中抽象边界应该在哪里的看法。什么应该来自机器人制造商，什么属于应用层，什么不可避免地仍然特定于设施？我们也对听到其他行业的看法感兴趣，您是否见过看似对人类微不足道但却出乎意料地难以自动化的物理检查任务。
查看原文
Hi HN, we're the founders of Salem Robotics (<a href="https://salemroboticsinc.com">https://salemroboticsinc.com</a>). We give existing mobile robots the task-specific intelligence to carry out surveys and physically interactive inspections in hazardous industrial facilities.<p>Here's a video of it running on real robot hardware with a few words from us:
<a href="https://youtu.be/U_228h3NE7c" rel="nofollow">https://youtu.be/U_228h3NE7c</a><p>We came to Salem through robotics research at UT Austin and a combined 15 years working in nuclear, including about 10 years developing and deploying autonomous robots at Los Alamos National Laboratory. Over the last five years, we kept running into the same gap: robot hardware had become very capable, but making a robot carry out a complete industrial procedure still required a surprising amount of robotics work and manual intervention.<p>The part that interested us most was manipulation. A nuclear contamination survey, for example, can require taking a "smear": wiping a defined area of a surface so it can be checked for removable radioactive contamination. In an oil, gas, or chemical facility, an LDAR (leak detection and repair) inspection can require moving a detector around a particular valve, flange, or connection. Other inspections require positioning an instrument at a precise location and orientation relative to a pipe or piece of equipment.<p>These are easy tasks to compress into verbs like "wipe", "measure", or "inspect", but considerably harder to make a robot do reliably. A probe might need to remain normal to a surface throughout a path, stay within a narrow offset from a pipe, or trace a region while maintaining a particular end-effector orientation. The planner has to find a feasible motion while respecting the task geometry, manipulator kinematics, joint limits, collisions, and the environment around it.<p>We work down to joint-level control for those interactions. One problem we've spent a lot of time on is generating constrained manipulation plans quickly enough that they can be based on the geometry the robot actually observes instead of requiring someone to carefully author a trajectory for every individual surface, valve, or flange.<p>The physical world makes this annoying. A few centimeters of error may not matter much when navigating down a hallway, but it matters if a sensor is supposed to remain normal to a curved surface. And successfully executing a trajectory doesn't necessarily mean the inspection worked. The detector could be misaligned, contact could be wrong, the geometry could differ from the model, or the measurement itself could be invalid. We care about closing that loop around the inspection result, not just whether the arm reached the commanded pose.<p>Our approach is a combination of AI and classical robotics. A lot of robotics research and industry attention right now is going toward increasingly end-to-end learned systems, particularly around humanoids. Working in safety-critical environments has made us appreciate how relevant classical approaches still are when you want explicit constraints, predictable behavior, and theoretical guarantees about what a robot can and cannot do.<p>We use AI where semantic understanding and flexibility are useful, such as interpreting less structured information or understanding what in an unfamiliar scene is relevant to a procedure. Once the system knows what physical interaction it needs to perform, we prefer explicit geometry, planning, optimization, and control where possible. We're interested in the marriage between the two rather than trying to make every part of the robotics stack learned.<p>The other idea behind Salem is that we don't think every useful robot application should require building a new robot. Companies like Boston Dynamics are getting very good at building increasingly capable hardware platforms. We think there is room for a domain-specific application layer on top of that hardware. The same underlying robot might perform nuclear radiological surveys in one facility and LDAR inspections in another, but the procedures, sensors, manipulation constraints, success conditions, and outputs are different.<p>That's also why we're hardware agnostic. We don't expect one robot to be the best platform forever, and facilities already own different hardware. We'd rather describe an inspection in terms of what needs to happen and then map that onto the capabilities of the right robot for the job.<p>One thing that surprised us after spending more time with facilities is how manual many inspection workflows still are. In sophisticated nuclear and industrial sites, people still physically walk survey routes, take measurements one at a time, visually inspect equipment, record results manually, and sometimes make judgments based on things like how a component sounds. Some of the basic workflows would be recognizable to someone doing the job decades ago, even though the sensors, computation, and robots available today are radically different.<p>We're starting with radiological inspection in nuclear because it's the industry we know best, and we're also working on manipulation-heavy inspection problems in oil, gas, and hazardous chemical facilities. The technicians and inspectors still define the procedure, interpret results, and make the consequential judgments. We're trying to automate more of the repetitive physical execution that currently requires someone to enter the environment or manually operate a robot.<p>We sell directly to industrial facilities, usually starting with a paid technical validation and then moving to an ongoing deployment. Pricing varies substantially with the workflow: validations range from tens of thousands to over $100k, and larger deployments can range from the low hundreds of thousands to roughly $500k per robot.<p>One thing we're especially curious to hear HN's thoughts on is where the abstraction boundary in robotics should sit. What should come from the robot manufacturer, what belongs in an application layer, and what will inevitably remain specific to the facility? We'd also be interested in hearing about other industries where you've seen physical inspection tasks that look trivial to a person but are surprisingly difficult to automate.