ROS 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.
The comment above is true of ROS, full stop. Even in C++ without involving Python. Especially if you have any real time requirements. It uses sockets for interprocess communication, which adds massive amounts of overhead. Replacing ROS and using straight function calls sped up a simulation of a system I was running from 10x real time to 1000x, for example. That's fine for certain applications but just didn't work for my particular use case.
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?
>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.
We’ve build a few enterprise sized applications in python and has a much better time of it than we ever did with the C#(that still powers most of our software).
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.
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.
- 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
With roslibpy you can communicate with ROS stuff without being a ROS Node:
https://github.com/gramaziokohler/roslibpy
"Unlike the rospy library, this does not require a local ROS environment, allowing usage from platforms other than Linux."
Please also consider, that this is related mostly to ROS1.
This is interesting, but won't you lose out on a lot of the benefits of using ROS in the first place? None of the tooling (command line tools and roslaunch stuff) that expects nodes will work.
If you want to really enjoy the ingenuity of people that otherwise might be considered "simple", check out the ROS for Agriculture group and slack channels. People converting 70s and 80s era farm equipment to be automated, and it's pure gold.
I was reading up on ROS the other day when the thought occurred that Erlang is, in many ways, similar to some of the core functionality of ROS, and might be a good substitute for [parts of] it.
I was wondering about the same, and have been trying to seek prior work along those lines. Here's what I've come across so far, regarding use of Beam VM (Erlang/Elixir) for robotics:
3. Jean Francois Cloutier's DDD talks on using Elixir for behavioral robots (3 annual updates; I really liked these)
4. A handful of talks on YouTube when searching for "erlang robotics" or "elixir robotics", but I haven't had a chance to check out all of them yet.
The superficial catch is that most ML progress in the recent past has focused on exploiting data parallellism (SIMD; rather than concurrency / task parallellism), and I don't know whether Erlang is as great at that. But supposedly it has a very good FFI, because it was designed to interface nicely with C programs running on network equipment.
ROS "feels" like clunky/heavy scaffolding for what should be simple and transparent plumbing. Instinctively, the Erlang VM seems like the perfect platform for building an agent doing fault tolerant concurrent computations -- but I don't have any Erlang/Elixir experience. I'd love to hear about any other pointers, or discussion along these lines.
Sadly I know very little about about ROS considering I'm personal friends with one of the maintainers. One of the more exciting things about nerves is that they are making it "easy to do the right thing" in terms of using end to end encryption for all of the parts of your nerves network when you deploy.
I would say that ffi on elixir is... Hard. Not impossible. (I'm currently writing a zig ffi library that aims to make it as painless as inlining the ffi code) If you're an abject beginner at both elixir and robotics I don't recommend going beyond what nerves has to offer off the shelf. If you're an expert in one of either the underlying robotics c interfaces or elixir, I think writing your own ffi might be neat and worth giving a go. The documentation on how to do things isn't terrible.
To be honest, ROS came in to offer a good balance between modularity, freedom of design and standardization. What it tries to do is not rocket science: make different package communicate using a pre-agreed packet format, and can be done in many languages.
Right. It started as a DARPA-funded effort to get more of the DARPA-funded robotics research projects to talk to each other in some useful way. It's clunky, like CORBA or OLE, but useful.
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.
Honestly, the language that I'd love get first class support for on ROS2 would be Rust. Robotics really needs type and memory safety while maintaining performance and I personally feel like Rust is the perfect fit.
I'd also love to see a mature linear algebra library in Rust (benchmarked to and as easy to use as Eigen).
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).
There is, after all, a graveyard littered with big-money attempts to speed up (mutually incompatible) subsets of Python.
But lack of inertia not something that should deter someone seriously invested (after all, Google/FB created Tensorflow/Pytorch respectively, and now Google might be getting behind Swift). It's a judgement call on whether one feels that most of the work/innovation still needs to be done, or is already done. If it is yet to be done, building on top of a better platform is almost a no-brainer.
I disagree. I think that the use of Python in ROS is the best of both worlds. ROS makes it easy to do sane-ish IPC even for folks new to programming and enables them to offload heavy numerical processing or real time tasks out to C++ or even other boards on your robot.
Python sits by handling state machines (decision making) and similar logic. It’s also great in experimental code that folks want to change often (opencv prototyping).
I don’t like the lack of a type system and have run into easily preventable bugs with python but in my case the trade off with developer productivity was worth it.
When I say Python is good for numerical computing and AI, what I really mean is that the libraries are there. I share the same reservation as you about the language itself. I wasn't so clear in my comment above
I brought ROS to FIRST robotics back when I was in high school and I still think it continues to change the game for how people work with robots [1, 2] The modularity / plug-n-play nature of the system makes swapping sensors (which often have ROS driver) or algorithms that much easier.
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.
I've seen IPC tools be built from scratch or on top of more popular stuff in several companies I worked in, unfortunately.
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.
yeah that looks cool but DDS is a technology designed for air gapped factories. AFAIK most ROS teams are still using ROS1 due to the lack of cross language tooling in ROS2. Again, bazel + gRPC* could solve this.
* or perhaps better is flatbuffers see tensorflow-lite
yes I read it at the time. However, HTTP3 + QUIC config [1] of gRPC also runs over UDP with more fallbacks to make it work over commodity hardware. DDR is a pain for random labs to work with as you have to have admin control over the network and bridges to make it work. This basically means it can't be used in the cloud or most corporate environments. It has huge deployment friction. Given the bad uptake of ROS2, I think the market agrees with me.
Note QUIC and HTTP3 were not really a thing when ROS2 was conceived, but the problem of head of line blocking was known and ROS2 was just a bit too ahead of the curve.
I think the market is pretty into ROS2 actually, its just the PhDs and grad students that will be on ROS1 for a longer time because they don't have the resources to make any switch.
Amazon and a lot of other companies are big on ROS2.
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.
"roslaunch is a tool for easily launching multiple ROS nodes locally and remotely via SSH, as well as setting parameters on the Parameter Server. "
sounds like a form of orchestration to me
I've been using ROS for some 8+ years now, for university projects, competitions like RoboCup@Home and for work on robots operating in the wild, on water, land and among people in malls etc.
I've seen many RoboCup teams convert from their custom stuff to ROS because it allows to profit for so much other great work.
In my own team, we replaced most custom stuff implemented in the early days of ROS and with ROS with the now de-facto standard ROS stuff for the same task so we can focus more on the stuff that made us win the competition this year :-)
ROS1 is primarily used with linux unless you use a VM. ROS2 can be used on linux, mac or windows. You can also check out AWS robomaker to use ROS in the cloud.
FWIW, I tried using Ros on Windows as recently as the summer but IMO the biggest issue is that 3rd party packages like those listed on the Github repo are predominantly coded for Linux. So I'd have issues with builds failing to compile if they weren't tuned to work on Windows.
I ended up just installing Ubuntu and dual booting to save me a lot of hassle.
Why haven't I tried ROS on Windows? I never really had the need to, I primarily use Linux at home and work.
I did briefly evaluate ROS 2 (ardent) on Windows at my previous job. It seemed to work fairly well, I built it natively, ran the demos and did some latency/throughput comparisons between DDS implementations.
While ROS2 promises windows compatibility I’m not so sure how it will turn out. Most guides, drivers and general support will focus on Linux. We’ll see how wrong I am when ROS2 finally takes off!
