Robotics Development Environment with ROS in C++ and Python

https://github.com/Ly0n/awesome-robotic-tooling

by protontypes • 7 years ago

150 54 7 years ago

carapace• 7 years ago

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.

jefft2554• 7 years ago

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.

ssivark2• 7 years ago

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.

isatty3• 7 years ago

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).

ssivark2• 7 years ago

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.

dnautics• 7 years ago

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.

Iv• 7 years ago

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.

Animats2• 7 years ago

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.

WhatNewSoftware• 7 years ago

Can this be easily setup on Windows?

Was my biggest obstacle to using ROS in the past.

imraj96• 7 years ago

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/

jefft2554• 7 years ago

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!

rmattes2• 7 years ago

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/

danbmil99• 7 years ago

Why?

colmvp• 7 years ago

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.

0wl3x• 7 years ago

Are you using WSL? It's usually good enough to make linux only software run without any issues.

jefft2554• 7 years ago

It's probably not very smooth and stable if you need stuff like RViz, RQt, etc.

protontypes4• 7 years ago

I will add some tools that will help you work with ROS under Windows. This is definitely missing.

heyflyguy2• 7 years ago

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.

TaylorAlexander• 7 years ago

Oooh I’m working on a farming robot right now. I’m gonna have to join that group!

BayezLyfe• 7 years ago

any specific links to these groups??

heyflyguy2• 7 years ago

Website: http://rosagriculture.org/ Slack: http://rosagriculture.slack.com/ GitHub: https://github.com/ros-agriculture Twitter: @ROSAgriculture YouTube: https://www.youtube.com/channel/UCnr6AObsHnHSGPge0HVlBpA

archontes• 7 years ago

People who would regard farmers as 'simple' don't know any real farmers.

abalaji• 7 years ago

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...

a_t483• 7 years ago

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.

Abishek_Muthian2• 7 years ago

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.

TeMPOraL• 7 years ago

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.

a_t483• 7 years ago

The C++ side of ROS is better but still not amazing.

stinos• 7 years ago

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?

moksly• 7 years ago

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.

stult• 7 years ago

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.

snagglegaggle• 7 years ago

Examples of poor decisions? I am just interested.

j-pb2• 7 years ago

- 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

protontypes4• 7 years ago

The experience went into ROS2 that is much better designed for larger projects.

mottosso• 7 years ago

Replace ROS and robotics with <Product> and <Field>, and this is some solid advice.

Animats2• 7 years ago

Well, yes, that's what ROS does. This "Awesome robotic tooling" GitHub repository adds what? A package index?

protontypes4• 7 years ago

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.

tlarkworthy4• 7 years ago

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.

isatty3• 7 years ago

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.

tlarkworthy4• 7 years ago

"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

ragebol4• 7 years ago

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.

tlarkworthy4• 7 years ago

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

ragebol4• 7 years ago

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 :-)

Robotics Development Environment with ROS in C++ and Python

Related Stories