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.
ryanisnan 5 hours ago [-]
What about container registries do robotics companies need that are different from other industries?
a_t48 5 hours ago [-]
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 libraries.
- Robots pull over 3G/Starlink/slow customer WiFi
- Robots are edge devices! They have previous related images, they aren't pulling onto a fresh disk like on web.
It's super common to have a layer in your Dockerfile that has several GB worth of dependencies. If you touch one of the dependencies, it thrashes that layer and anything below it. To quote the CPO from a company I left "Anytime anyone looks at the container the wrong way its a 13g dl over a shit cell connection or starlink". It's extra shit because most of the data the robot is pulling, the robot already has in another layer!
Clipper solves this by breaking apart Docker layers and indexing the files within. When you pull an image it will reuse related files in images you already have on your device. This has other side benefits as well, like being able to mount layers as networked filesystems and much more easily being able to run P2P updates.
It's less that robotics needs a different container registry and more that robotics needs a better container transport, and I've built the infrastructure around it for my registry.
chfritz 48 minutes ago [-]
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.
lesiva 6 hours ago [-]
> 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?
Salem_robotics 6 hours ago [-]
That creativity/randomness presents itself in different ways depending on the application of the AI. In robotics, that randomness means variance in the motion of the robots physical body and arm(s). I think over time as labs get better at understanding and quantifying the uncertainty of model outputs there could absolutely be a place for full end-to-end AI in safety-critical environments. But today, we believe that is not the best approach for these applications.
akshay_akula 6 hours ago [-]
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.
akshay_akula 3 hours ago [-]
Makes sense, catching a bad measurement in the moment beats finding out after the robot has left the site.
Salem_robotics 6 hours ago [-]
Thanks, analyzing the data collection in real time plays a major part in assuring we actually collect the data we set out to.
sidcool 5 hours ago [-]
Congrats on launching. This should get more attention
janakpanthi 5 hours ago [-]
Thanks, YC launches have helped quite a bit with drawing attention. We're hoping HN will pronounce it more.
droidjj 6 hours ago [-]
Is "Salem" a tongue-in-cheek nod to being a small, quirky competitor to Boston Dynamics (Salem, MA : Boston, MA :: Salem Robotics : Boston Dynamics)?
If so, as someone who lives close to Salem, I like it :)
Good luck to you guys.
Salem_robotics 6 hours ago [-]
Haha it wasn't, but we might steal that for our story going forward.
vegnus 6 hours ago [-]
is this based in Salem MA? If so, nice
janakpanthi 5 hours ago [-]
Cofounder here. we're based in Austin, TX, but yes, the name alludes to Salem MA. We're bringing inanimate objects to life through robotics, haha.
alexchantavy 6 hours ago [-]
First thing I thought of too, I love it
sidcool 5 hours ago [-]
Salem Statics
janakpanthi 5 hours ago [-]
Boston Dynamics vs Salem Statics, haha. Seriously though, we are very complimentary to BD, since Spot is one of the platforms we deploy on.
martythemaniak 3 hours ago [-]
> 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.
Congrats on the launch. I love this part, because it is also the working theory behind my robot clearing robot project (http://www.frost-e.com). I'm new to robotics, but it seems to me there's a gap between classic robotics tools and approaches (ROS2-based navigation, local YOLO-based object detection etc) and the video-input-to-actuator-output VLA models that robot labs are showcasing. In fact, I kinda think the big labs are trying to boil the ocean - long horizons, 6DoF actuator control, cross embodiment, generalization, etc etc.
Seems to me is that if you restrict the problem space, have well defined tasks, then marry the semantic understanding and reasoning of VLMs with the geometric tools of classical approaches, then you could have something practical and economical.
Salem_robotics 35 minutes ago [-]
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)
hnwkbmrkv2 5 hours ago [-]
[dead]
Rendered at 22:25:37 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
Clipper solves this by breaking apart Docker layers and indexing the files within. When you pull an image it will reuse related files in images you already have on your device. This has other side benefits as well, like being able to mount layers as networked filesystems and much more easily being able to run P2P updates.
It's less that robotics needs a different container registry and more that robotics needs a better container transport, and I've built the infrastructure around it for my registry.
> 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?
If so, as someone who lives close to Salem, I like it :)
Good luck to you guys.
Seems to me is that if you restrict the problem space, have well defined tasks, then marry the semantic understanding and reasoning of VLMs with the geometric tools of classical approaches, then you could have something practical and economical.
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)