HackerNews中文版

各位 HN 的朋友，我们是 Salem Robotics 的创始人（<a href="https://salemroboticsinc.com">https://salemroboticsinc.com</a>）。我们为现有的移动机器人赋予了特定任务的智能，使其能够在危险的工业设施中执行勘测和物理交互式检查。以下是一段在真实机器人硬件上运行的视频，其中包含我们的一些介绍： <a href="https://youtu.be/U_228h3NE7c" rel="nofollow">https://youtu.be/U_228h3NE7c</a> 我们创立 Salem 源于在 UT Austin 的机器人研究以及在核工业领域积累的共计 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.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>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.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.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.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.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.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.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.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.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.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.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.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.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.

Launch HN：Salem Robotics (YC S26) – 工业检测机器人软件