There's usually a clear use case and a motivation, like you were building an AR passthrough goggles and existing cameras were too big or you didn't want a USB3 camera for it. It's not clear what those were for the author, and the article is rather information sparse relative to the complexity of the project.
You can assume that the motivation is for the author to build something and share it with like-minded hackers. If he picked something OTS, that wouldn't be a story on HN.
But one does not simply design a 4-layer PCB and put a couple image sensors on it. It makes even less sense that the author doesn't even bother to get the camera intrinsics/extrinsics on top of that.
It's like, idk, someone is publishing a toy OS source code, yet they're completely skipping over quote-unquote-basic things like UEFI boot entry registration. It just feels...not necessarily fakey but odd.
Touchscreens didn't make physical controls lose their value.
Their widespread use is just a result of a tradeoff for many product designers, where a satisfying experience just didn't outweigh the dominating factors.
Some car manufacturers are in fact reintroducing physical user control elements. After reevaluating the tradeoff decision so it seems.
It's really a fascinating book and topic. And i too enjoy appreciating it. I guess it's appreciating the beauty of nature and as you said, AI will not be able to threaten that.
One horrifying facts I've read about it is that ROS1 is completely non-realtime and non-deterministic, so much so that its ROSBAG data logs aren't time or sequence accurate. So you can collect the sensor inputs and simulate programmatic behavior, but it's acucrate only if you were lucky. And everyone has to either use it or devote massive amount of resource recreating it right way because there's just immense amount of useful packages available for ROS.
Because ROS sucks. If you have ever had the chance to work with it, you will know, here’s a heads-up/recap on why:
- multiple configs all over: xml, cmake, yaml, “””launch file”””, urdf, and others, im not joking, those are all configs!
- you might have a node running but it’s technically not? The mystery mostly that the node isn’t publishing, why? Well, there are gazillions of reasons, maybe qos mismatch, wrong topic name space, timestamp issues, frame ID, etc etc
- the debugging is distributed, so a failure you see (assuming you found it anyway), it could be actually from another process, interface, driver, you name it.
- so many dependencies, you have ros itself, then ubuntu, then gazebo, python, other libraries needed to build, so you could spend a whole week troubleshooting just because one of these mismatch something else.
- ros1 sucked, look it up, realtime limitation, security, discovery, tooling etc, so they made ros2, supposedly better, but the unnecessary complexity added is abysmal, dds, qos profile, call back groups, lifecycle nodes, and other cluster fuck of stuff.
- you have also with implied status, so different terminals can and will behave differently, you got sourced workspaces, environment variables, automatic discovery, overlay order and others, can work in one terminal setup but not in another.
- a lot of packages were done for specific robot or by a student who was doing some school work, that package will not just work on the same set up you have, I have seen robots of the same model and the package won’t work because the motor driver is slightly different. Also, that package is mostly abandoned anyway.
And you have all the security concerns with all that stuff above, that’s why it never gets added to the same network where serious automation things are happening, in fact, I have never ever seen ROS used in real commercial products, for good.
First time I got to work with it I thought it’s just me, so I ended up building the drone platform from scratch in much easier and simpler way, only to find most of the industry share the same idea.
I can rant more but my take away, if you can do something without it, do it, don’t try to rely on it, it’s like 100x worse than kubernetes, once you are fully invested in it and building everything around it, it will be hard to replace.
Not much to say, really; it controls my house in Home Assistant using an LLM, and a STT/TTS server. It acts as the Home Assistant Voice Preview Edition, with a trigger word and whatnot.
It's basically like giving an Alexa, Siri, or Gemini a body. It moves, show "emotions", comments when someone enter the room, uses the camera to see who entered the room and comment on that, make comments when my 3D printer finishes, things like that.
I can also turn on lights, the TV, the AC, ask about the weather, and other basic assistant stuff, ofc.
> It moves, show "emotions", comments when someone enter the room, uses the camera to see who entered the room and comment on that, make comments when my 3D printer finishes, things like that.
So basically you're using it as an AI mother in law, nice.
There is an application for Reachy that makes it so you can connect to Home Assistant, but it's broken and seems abandoned, so I forked it, fixed it, and customized it. That gets you 80% of the way. The rest is based on automations built inside Home Assistant.
And since Reachy's software and SDK are pretty open, it's trivial for a coding agent to learn how to communicate with the robot to achieve your desired outcome.
I actively do it in a way, where i steer and understand the important bits. Because otherwise the cognitive and technical debt would annoy me to a point, where i would want to do software at all.
Do you ask that question on every Open Source / Open Hardware project you encounter?
reply