Can this be easily setup on Windows? Was my biggest obstacle to using ROS in the past.
Robotics Development Environment with ROS in C++ and Python
41–50 of 59 posts
Re: Robotics Development Environment with ROS in C++ and Python
#42ROS 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.
Re: Robotics Development Environment with ROS in C++ and Python
#43ROS 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.
No this isn't generally true for Python, and I'm not sure why you'd be forced to use Cython for things at scale. Unless you have some particular type of software in mind perhaps?
Re: Robotics Development Environment with ROS in C++ and Python
#44Earlier quoted context omitted.
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.
You answered it:
> It did a great job of pretending to be an efficient language by having libraries pawn off the heavy lifting to companion C implementations.
That's a feature.
Re: Robotics Development Environment with ROS in C++ and Python
#45ROS 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.
Dynamic types aren’t exactly great, but Python is generally really good at getting things done. I probably wouldn’t use it if you had millions of concurrent users instead of the thousands we do, but for most projects it will work just fine even when the projects grow in size.
Re: Robotics Development Environment with ROS in C++ and Python
#46Earlier quoted context omitted.
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 becomin…
Please also consider, that this is related mostly to ROS1.
Re: Robotics Development Environment with ROS in C++ and Python
#47ROS 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.
Re: Robotics Development Environment with ROS in C++ and Python
#48I 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.
ROS2 is building on DDS, which is a standardized protocol and has implementations from multiple vendors as well as open source implementations, with QoS built in etc.
Re: Robotics Development Environment with ROS in C++ and Python
#49Earlier quoted context omitted.
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 any Python development in general? No this isn't generally true for Python, and I'm not sure why you'd be forced to use Cython for things at scale. Unless you have some particular type of software in mind perhaps?
Webservices. May be its fine for couple of hundred users, but when there are thousands of concurrent users with heavy I/O I've been forced to replace asyncio with uvloop, replacing coroutine with gevent, implementing pre-fork worker models etc. to get decent performance.
I've since then moved any webservices development to Golang and has been perfect.
I understand there are large scale companies like Instagram which supposedly use Python and I don't detest it. It's just there are better tools for job now, especially for a lean startup and of-course Python has it's advantages like being a good first programming language and large library ecosystem.
Re: Robotics Development Environment with ROS in C++ and Python
#50I 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.