Robotics Development Environment with ROS in C++ and Python(github.com)
github.com
Robotics Development Environment with ROS in C++ and Python
https://github.com/Ly0n/awesome-robotic-tooling
58 comments
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?
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.
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.
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.
>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.
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.
The C++ side of ROS is better but still not amazing.
The experience went into ROS2 that is much better designed for larger projects.
Replace ROS and robotics with <Product> and <Field>, and this is some solid advice.
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
- 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.
Please also consider, that this is related mostly to ROS1.
[deleted]
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.
People who would regard farmers as 'simple' don't know any real farmers.
Oooh I’m working on a farming robot right now. I’m gonna have to join that group!
any specific links to these groups??
Website: http://rosagriculture.org/
Slack: http://rosagriculture.slack.com/
GitHub: https://github.com/ros-agriculture
Twitter: @ROSAgriculture
YouTube: https://www.youtube.com/channel/UCnr6AObsHnHSGPge0HVlBpA
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:
1. Nerves seems like a promising platform: https://nerves-project.org/
2. There's also Grisp ("Erlang on bare metal")
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.
1. Nerves seems like a promising platform: https://nerves-project.org/
2. There's also Grisp ("Erlang on bare metal")
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.
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).
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).
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: https://news.ycombinator.com/item?id=12025309
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.
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: https://news.ycombinator.com/item?id=12025309
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.
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
Armin's points are true, but PyPy makes the best of the situation, and hopefully the C-API will be deprecated at some point.
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.
[1] https://www.firstinspires.org/robotics/frc [2] https://www.chiefdelphi.com/t/paper-team-900-presents-zebrav...
[1] https://www.firstinspires.org/robotics/frc [2] https://www.chiefdelphi.com/t/paper-team-900-presents-zebrav...
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.
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
* or perhaps better is flatbuffers see tensorflow-lite
gRPC, ZeroMQ, RabbitMQ, ActiveMQ, there's a whole bunch of them. The decision to use DDS is explained here in https://design.ros2.org/articles/ros_on_dds.html
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.
[1] https://www.fastly.com/blog/why-fastly-loves-quic-http3
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.
[1] https://www.fastly.com/blog/why-fastly-loves-quic-http3
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 :-)
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 :-)
[deleted]
Well, 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.
The list is more intendet to find the gems of modules, resources and tools for an professional robotic development.
Can this be easily setup on Windows?
Was my biggest obstacle to using ROS in the past.
Was my biggest obstacle to using ROS in the past.
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.
https://wiki.ros.org https://index.ros.org/doc/ros2/ https://index.ros.org/doc/ros2/Installation/Crystal/Windows-... https://aws.amazon.com/robomaker/
https://wiki.ros.org https://index.ros.org/doc/ros2/ https://index.ros.org/doc/ros2/Installation/Crystal/Windows-... https://aws.amazon.com/robomaker/
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.
I ended up just installing Ubuntu and dual booting to save me a lot of hassle.
I've never tried it, so I don't know how easy it is, but there has been a lot of work recently to improve ROS on Windows:
https://microsoft.github.io/Win-RoS-Landing-Page/
Why?
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.
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!
I will add some tools that will help you work with ROS under Windows. This is definitely missing.