Earlier quoted context omitted.
Who says you can’t have a swarm
Certainly not OpenAI, the swarm is evolving under their roof as we speak
I just open-sourced a brain for the Microduck (GitHub stars appreciated): https://github.com/rokbenko/quackd
Microduck
411–415 of 415 posts
Re: Microduck
#412Earlier quoted context omitted.
> 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.
[dead]
Cool, nice name also!
Re: Microduck
#413I hope it’s not built on ROS or rely on it in any way! Also kudos for bringing the joy of robotics back, since now most companies are riding the “defense” bandwagon and all robot companies I know suddenly are defense companies and visiting their sites is like the most dystopian thing ever, making it harder to find contract/jobs for people who want to make robotics for good not killing machines.
What would be so bad about relying on ROS in any way?
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.
Re: Microduck
#414Earlier quoted context omitted.
What would be so bad about relying on ROS in any way?
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 topi…
Oh wow thanks, you might have saved me a lot of time and anger.