I kind of feel ROS rebuilt a ton of Google tech before it was open sourced. rosbuild is bazel, Ros messages are protobuffers/flatbuffers, orchistration is k8s. I feel we could do a better job these days with the newer tools rather than ROS's less maintained, less interesting to researchers, reimplementation of infra tech.
Robotics Development Environment with ROS in C++ and Python
31–40 of 59 posts
Re: Robotics Development Environment with ROS in C++ and Python
#32Earlier quoted context omitted.
It’s true, the reason for choosing C++ and Python as first class languages is because of their strength in numerical computing and AI capabilities (for python anyway), which erlang mostly lacks. It would definitely be cool to be able to use erlang though.
No offense (I use Python all the time), but Python seems almost like the worst of all worlds, except for ease of use in the first month of using it -- with its only advantage being library inertia (which is a massive advantage in practice though). As eg: here's an excellent talk on the cruft in Python internals by Armin Ronacher: https://www.youtube.com/watch?v=qCGofLIzX6g For more discussion on why Python is slow: h…
Armin's points are true, but PyPy makes the best of the situation, and hopefully the C-API will be deprecated at some point.
Re: Robotics Development Environment with ROS in C++ and Python
#33ROS is really great for getting started with robotics, but from my experience (and from others who I've talked to) tends to buckle under its own weight in larger projects. This isn't to say you shouldn't use it, just be careful with it. It has some really questionable design decisions and implementation details that can bite you later.
Isn't this the case with any Python development in general? Once you start building at scale you'll be forced to use Cython extensions and other non-native python code.
Isn't this the case with most of Python? It did a great job of pretending to be an efficient language by having libraries pawn off the heavy lifting to companion C implementations. I wonder what's so special about Python that it does this much more often than any of the other languages I know.
Re: Robotics Development Environment with ROS in C++ and Python
#34ROS is really great for getting started with robotics, but from my experience (and from others who I've talked to) tends to buckle under its own weight in larger projects. This isn't to say you shouldn't use it, just be careful with it. It has some really questionable design decisions and implementation details that can bite you later.
Examples of poor decisions? I am just interested.
Re: Robotics Development Environment with ROS in C++ and Python
#35ROS is really great for getting started with robotics, but from my experience (and from others who I've talked to) tends to buckle under its own weight in larger projects. This isn't to say you shouldn't use it, just be careful with it. It has some really questionable design decisions and implementation details that can bite you later.
The experience went into ROS2 that is much better designed for larger projects.
Re: Robotics Development Environment with ROS in C++ and Python
#36ROS is really great for getting started with robotics, but from my experience (and from others who I've talked to) tends to buckle under its own weight in larger projects. This isn't to say you shouldn't use it, just be careful with it. It has some really questionable design decisions and implementation details that can bite you later.
Examples of poor decisions? I am just interested.
- Fundamental bug in the way they compute message schema checksums used for compatibility checks, causes buffer overflows and undefined robot behavior when changing array lengths.
Is marked as wontfix because they don't want to recompile existing packages.
- custom build tooling based on cmake is super cumbersome and buggy, and it means that you simply cannot communicate with ROS based stuff, without yourself becoming a ROS module that uses that custom build tooling
- there is no QOS, messages are retained somewhat due to the topic semantic, but you can't tune retention parameters or resends
Re: Robotics Development Environment with ROS in C++ and Python
#37ROS is really great for getting started with robotics, but from my experience (and from others who I've talked to) tends to buckle under its own weight in larger projects. This isn't to say you shouldn't use it, just be careful with it. It has some really questionable design decisions and implementation details that can bite you later.
Examples of poor decisions? I am just interested.
[deleted]
Re: Robotics Development Environment with ROS in C++ and Python
#38ROS is really great for getting started with robotics, but from my experience (and from others who I've talked to) tends to buckle under its own weight in larger projects. This isn't to say you shouldn't use it, just be careful with it. It has some really questionable design decisions and implementation details that can bite you later.
Replace ROS and robotics with and , and this is some solid advice.
Re: Robotics Development Environment with ROS in C++ and Python
#39Well, yes, that's what ROS does. This "Awesome robotic tooling" GitHub repository adds what? A package index?
ROS has already a package index:
https://index.ros.org/packages/
The list is more intendet to find the gems of modules, resources and tools for an professional robotic development.
Re: Robotics Development Environment with ROS in C++ and Python
#40I kind of feel ROS rebuilt a ton of Google tech before it was open sourced. rosbuild is bazel, Ros messages are protobuffers/flatbuffers, orchistration is k8s. I feel we could do a better job these days with the newer tools rather than ROS's less maintained, less interesting to researchers, reimplementation of infra tech.
ROS does not do orchestration. The only valid point you have is that ROS IPC can do with better serde and yes, protocol buffers are indeed more elegant. The rest of it's not relevant to the actual project at all.