Salem Robotics (YC S26) gives industrial robots the skills to perform hazardous inspections
Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
Salem Robotics, a YC S26 startup founded by robotics researchers from UT Austin and Los Alamos National Laboratory, provides software that enables existing mobile robots to carry out complex inspection tasks in hazardous facilities like nuclear plants and oil refineries. Their system combines AI for semantic understanding with classical robotics for precise, constrained manipulation, allowing robots to perform procedures such as nuclear contamination smears and LDAR leak detection. They are hardware-agnostic, aiming to add a domain-specific application layer on top of capable platforms like those from Boston Dynamics. Starting with radiological inspections, they sell directly to industrial facilities, with deployments ranging from $100k to $500k per robot.
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.
- beckford
The part about being hardware-agnostic sounds something like ROS 2, but maybe at a higher level. I would love to see a post about that (with a bit of explainers for people like me who only lightly dabble with robotics).
But I'm also curious to know if the "Salem" name was searched first. When I first saw the title I thought it was talking about Agility Robotics, which is based in Salem, Oregon and is currently 3rd spot on Google search for "Salem Robotics" (and 4 of the top 5 results on YouTube).
- lesiva
> 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...
> 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.
This is a great specific example of where the creativity (read: randomness) of AI runs into a wall. Do you see this changing over time as models improve, or do you expect that safety-critical / highly specific tasks will always require a more explicit set of instructions?
- hic
All the best! Very clear framing and definitely needed service. I remember in 2011 not too far from Fukushima after the problems with nuclear reactors. The company here faced very difficult inspection problems, including through rubbles. There were robots able to deal with some problems, but not in Japan, and anyway they had to act fast and so sent people. It apparently was safe enough, but able robots would have been so much safer.
A technical question: To scan a surface precisely, I'd rather put switches on the end effector aside the sensor, such that the arm places itself roughly above the surface to scan, pushes until the switches trigger, and scan keeping the switches on. A simple touch sense, basically. All trad robotics that smoothly follows many flat and curved surfaces. Not at all against AI here, it seems the whole thread is a constructive approach mixing the best tools to concrete targets. Not viable approach in your scenarios?
Thoughts on your concluding questions:
> 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?
I really like when there is a "double SDK", with a low level one to target actuators and sensors individually (motor 2 of leg 4), and a higher level one with pre-defined scenarios (move forward, whatever the bot is a bipede, a quadcopter or a slug). These two API types often allow for easier work at the appl […]
- a_t48
Congrats on the launch. I've been in the robotics industry for a decade now, I've seen that boundary lie at many different places. I'm not sure there's a clear cut answer.
Self plug: I'm the founder of Clipper, a container registry that has 10x faster pulls and 7x faster builds over DockerHub, targeted at robotics. I got tired of robotics deploys taking all day and fixed it myself. If you're interested in that or just want to talk shop, let's chat.
- akshay_akula
Congrats on the launch. "Successfully executing a trajectory doesn't mean the inspection worked" is a great frame, closing the loop on the measurement itself is the hard part.