Congrats on the launch! At Transitive Robotics we make full-stack modules so robotics companies like you can build their operational systems faster and with greater quality. We have a number of modules you might be interested in, e.g., for remote video-streaming and tele-op/-assist: https://transitiverobotics.com/caps/.
Let me know if you want to chat.
Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
21–30 of 34 posts
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#22> 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 eve…
Yeah, you hit some great points! From a broader perspective not only are we seeing the sort of ai vs classical approaches camps at different conferences and companies, but industry wide we wonder about another shift.
A shift from a single company handling all software and hardware inhouse, to a sort of divergence of the two. Kind of cool to think about, given how that sort of divergence seems to have happened in a few other areas (a dell computer runs windows, an LG TV runs apple TV, your iphone runs airbnb, spotify, instagram)
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#23Earlier quoted context omitted.
What about container registries do robotics companies need that are different from other industries?
Docker is built for web. The mental model is that the internet speed is relatively fast, the image is relatively small, and the device you're pulling onto is starting with essentially no data. All three of these assumptions are wrong for robotics: - I've had someone in the Docker discord tell me at length that my container shouldn't be bigger than 1GB, which is impossible the moment you pull in CUDA or any ML librari…
layered rsync, in a sense
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#24Congrats on the launch! At Transitive Robotics we make full-stack modules so robotics companies like you can build their operational systems faster and with greater quality. We have a number of modules you might be interested in, e.g., for remote video-streaming and tele-op/-assist: https://transitiverobotics.com/caps/ . Let me know if you want to chat.
Remote video streaming is relevant. Please free to send us an email.
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#25Congrats 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.
[deleted]
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#26Earlier quoted context omitted.
What about container registries do robotics companies need that are different from other industries?
Docker is built for web. The mental model is that the internet speed is relatively fast, the image is relatively small, and the device you're pulling onto is starting with essentially no data. All three of these assumptions are wrong for robotics: - I've had someone in the Docker discord tell me at length that my container shouldn't be bigger than 1GB, which is impossible the moment you pull in CUDA or any ML librari…
Very interesting. We’ve for sure felt the pain of large robotics images and slow deployments, especially when CUDA and ML dependencies are involved, or when adding a seemingly small ROS package pulls a long chain of transitive dependencies. The file-level deduplication approach is clever. Curious how transparent it is to existing Docker/OCI workflows. Does it require any changes to the client, or it mostly sits underneath the existing tooling?
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#27Earlier quoted context omitted.
Docker is built for web. The mental model is that the internet speed is relatively fast, the image is relatively small, and the device you're pulling onto is starting with essentially no data. All three of these assumptions are wrong for robotics: - I've had someone in the Docker discord tell me at length that my container shouldn't be bigger than 1GB, which is impossible the moment you pull in CUDA or any ML librari…
layered rsync, in a sense
In some sense, yes.
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#28Earlier quoted context omitted.
Docker is built for web. The mental model is that the internet speed is relatively fast, the image is relatively small, and the device you're pulling onto is starting with essentially no data. All three of these assumptions are wrong for robotics: - I've had someone in the Docker discord tell me at length that my container shouldn't be bigger than 1GB, which is impossible the moment you pull in CUDA or any ML librari…
Very interesting. We’ve for sure felt the pain of large robotics images and slow deployments, especially when CUDA and ML dependencies are involved, or when adding a seemingly small ROS package pulls a long chain of transitive dependencies. The file-level deduplication approach is clever. Curious how transparent it is to existing Docker/OCI workflows. Does it require any changes to the client, or it mostly sits under…
It mostly sits underneath existing tooling. I replace the push/pull client (run `clipper pull` instead of `docker pull`, and optionally the BuildKit driver (to get build outputs natively in my format). That pull command ingests the image into your chosen runtime, meaning your docker/podman/k8s run commands remain the same. If you're interested I can set up a demo/call/coffee.
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#29> 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 eve…
Great point and realisation on many realities of robotics. Most successful and scaling projects have been traditionally in controlled environments. This always reminds me of William Shatner in "The Future is Now" ad in 1984: https://www.youtube.com/watch?v=pb_-BWHMQlc
When we can control the environment precisely, we should as it simplifies so much---we can clip the world to platonic geometries and apply common tricks and trigonometry.
But when we cannot control the environment, really really much harder. Self-driving cars are a good example how hard it is, and still mainly focusing on relatively structured environments like cities.
Arbitrary environment is really where many expect AI/ML/probabilistic robotics to bring some necessary flexibility. And still out of reach today, except some astonishing use cases like Roombas (well, more like a best effort approach, still).
Re: Launch HN: Salem Robotics (YC S26) – Software for industrial inspection robots
#30All 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 application layer. The SDK is also the main specific software that remains with the maker (facility?)
> industries where you've seen physical inspection tasks that look trivial to a person but are surprisingly difficult to automate
Too often a problem I have seen is... elevators. More generally unstructured environment, and environments explicitly tailored for humans. Proposals range from wireless interfaces (and so HW infrastructure dependent and hard to scale), to adding a manipulator to, say, push buttons on an elevator (and this means extra software to manipulate, recognise buttons, etc).