ROS 2 Iron Irwini Release

https://www.openrobotics.org/blog/2023/5/23/ros-2-iron-irwini-released

by kscottz • 3 years ago

55 73 3 years ago

Robotics is really really really really hard. So let's turn the entire thing into a system of distributed microservices, using CORBA/DDS for pubsub...

It'd be like if you designed a video game so that the physics engine (motion planning) happened in one process, while rendering (perception) happened in another process and the world state needed to be exchanged via pubsub. Why do we keep doing this to ourselves?

blensor• 3 years ago

Multiple reasons, here are my two cents: * ROS nodes usually do ( or did back when we used ) pretty resource intensive tasks so they are generally distributed over multiple machines * Individual nodes can have quite diverse library requirements ( specific library versions of obscure libraries ) that don't go together, so you want to decouple them

snovv_crash14• 3 years ago

Only in academia. In industrial settings sending stuff over a network between machines is too unreliable for realtime operation, and oftentimes also too expensive. Also in industrial environments if you can't install things together, they're not of a standard that you're happy to deploy to production.

dbcurtis3• 3 years ago

Pub/Sub is a very natural fit for robotics. Companies do write ROS out of their production stacks when they get the resources. But they don’t replace pub/sub architecture.

ROS provides a plug-in backplane that allows you to innovate in one area while leveraging existing components for parts that are not your differentiator.

cheeselip4207• 3 years ago

pub/sub is NOT a natural fit for robotics - you want bounded timing and generally for error-handling you want to know what happened as a result of a message being published. ROS introduced "commands" and "actions" to attempt to work around this, but its all just shit piled on shit.

Just make a multi-threaded app, and call functions. If you need to distribute over multiple CPUs, then go ahead and do some IPC. But pub/sub is NOT an architecture. Its a soup of tightly coupled fragments of functionality. It falls apart very quickly in the real world.

markisus• 3 years ago

I used to use ROS 1 for work. It is incredibly over-engineered. Somewhere in the code base there is a three level hierarchy wrapping a shared pointer to double. The actual address is configured using an xml file. The purpose? To “abstract” the commanded torque ultimately sent to a motor.

facontidavide• 3 years ago

I have been doing robotics for 20 years, and the "trend" to adopt a distributed architecture was already popular 15 years ago. ROS just adopted and continued that trend. I think you are missing some important points:

- a large amount of data can be transferred asynchronously. Pub/Sub is a great pattern to achieve that; the cases when you need a synchronous interface are the minority.

- a robotic software has MANY components, you need an approach that incentivize decoupling and lousily-coupled interfaces.

- this lousily-coupled architecture has been a catalyst for innovation and cooperation, because it makes it easier for people to share their code as "building blocks" of a larger system.

Is there a considerable overhead? Sure! But it is much more complicated to write thread-safe code in a huge, monolithic application.

lqr2• 3 years ago

I worked on a robotics project with a large team using ROS1. The loose coupling is pernicious: It's easy for everyone to work on their own ROS node in isolation and avoid testing the integrated system. There's no compiler to help you find all the clients of a node, etc.

Loose coupling is good if you mainly use open-source packages and modify one component for your research paper. I'm not sure it's a net positive when building most components yourself.

A big multithreaded program can still use queues instead of locks to share data between threads.

ragebol4• 3 years ago

I've been using ROS for 10+ years, in both university and professional settings.

The hard parts were never in the middleware (ROS), but stuff like perception, world modelling, decision making. ROS gives you an ecosystem of decent options to choose from. And improve on if you need to at all.

The standardized interfaces and IPC make it very easy to plug, at runtime, eg. a different localization algorithm into the system.

mchusma2• 3 years ago

I've also used ROS a lot (but not in the last 2 years), and +1 your comment. The main gripe with ROS is poor documentation, and people's over-reliance on coding in the simulator. Not the architecture. The biggest challenge IMO is actyally getting the perception, world modeling, decision making work reliably in the real world, and this is where AI should provide a big boost.

ModernMech9• 3 years ago

Because robots are naturally distributed and asynchronous realtime systems .

cheeselip4207• 3 years ago

"Naturally?" lol

while(true) { read sensors update world model decide what to do act }

You should only deviate from this when you have a specific reason (concurrency, libraries, IPC, etc). You can attach a debugger. You can deterministically play sensor data through and get great reproducibility for end-to-end testing. Starting with a distributed system is a handicap 80% of the time.

sargun• 3 years ago

I actually talked to someone in industrial robotics, and message passing / message buses are really common there. All of their controllers are loosely coupled, because each unit might be from a different vendor, upgraded at a different time, etc... It also had the nice property that their systems all had multiple supervisors, and if the supervisor detected a bad state by monitoring the bus passively, it could stop all of controllers.

ragebol4• 3 years ago

ROS (1/2) is just damn handy. There's a plethora of libraries available: navigation, localization, perception, motion planning, visualisation, record and replay events for debugging, high-level behavior definition with state machines and behavior trees, motion control, sensors, orchestration anything you need in a robotics system.

I've seen various half-assed versions or something akin to ROS (IPC to have process isolation and distributed, with some processes running on a RTOS) seen built over the years. All of which sucked in different ways. Especially a tool like RViz is always missing. And in many many robotics video I see (of a moderately complex robot), there's ROS's RViz on some screen.

amacneil2• 3 years ago

Especially a tool like RViz is always missing. And in many many robotics video I see (of a moderately complex robot), there's ROS's RViz on some screen.

I would love the future robotics development stack to be more modular, so that (for example) future middleware solutions don't need to also bundle their own visualization software. This was direct inspiration for creating Foxglove Studio[0] for visualization and MCAP[1] for logging - both work great with ROS, or equally well without it.

[0] https://github.com/foxglove/studio

[1] https://github.com/foxglove/mcap

elephantum• 3 years ago

Foxglove is my best argument to use ROS instead of custom solution in semi-robotics cases (several cameras/sensors + ML, but no actuators)

rektide6• 3 years ago

It is wild to me that there's this whole huge message-bus/rpc system Data Distribution Service (DDS) that so much of thr computing industry else has never heard of, but which is totally core to ROS. https://en.wikipedia.org/wiki/Data_Distribution_Service

It does have some real further mindshare. I noticed GM/Eclipse Foundation's new uProtocol has support for it. https://hn.algolia.com/?query=Uprotocol&sort=byDate&type=sto...

anonymousDan• 3 years ago

Interesting. Does it define a wire protocol or is the interface implicit to the client library.

elcritch2• 3 years ago

message-bus/rpc system Data Distribution Service (DDS) that so much of thr computing industry else has never heard of, but which is totally core to ROS.

From my understanding ROS2 chose it because it had decent mindshare in automotive and some other industrial fields.

The core data serialization isn’t too terrible. I’ve been working toward writing an embedded version in Nim. The spec is simpler than it seems.

The biggest downside to ROS2 is the multiple layers of abstraction combined with a bespoke meta-build system. To be fair, it’s still simpler than diving into the grpc c++ library IMHO.

amacneil2• 3 years ago

Congrats to the Open Robotics team and everyone who contributed to this release!

Calling out a couple changes I'm excited about that we (Foxglove) helped contribute to:

- MCAP is now the default logging format in Rosbag2[0]. This is a much more performant and configurable format than the previous default (SQLite-based). SQLite is still a fully supported alternative.

- Message type definitions (schemas) can now be exchanged at runtime[1]. This means that tools such as rosbag2, or visualization tools such as Foxglove Studio[2] can now communicate with a ROS system over the network without needing a copy of the source code or complete ROS workspace.

[0] https://github.com/ros2/rosbag2/pull/1160

[1] https://github.com/ros2/ros2/issues/1159

[2] https://github.com/foxglove/studio

EddieEngineers3• 3 years ago

How can I get into robotics? I absolutely love the field from the outside but have zero idea how to get into it. Currently a software engineer & studying mechanical engineering part time with a goal of going into robotics eventually, but it doesn’t seem to have a natural starting point for hobbyists.

the_only_law• 3 years ago

Currently a software engineer & studying mechanical engineering part time with a goal of going into robotics eventually

Well it sounds like you’re a bit beyond being a just hobbyist if you’re pursuing formal education. Sorry if this is just me being ignorant , but does your masters programs have any career resources you could look into?

EddieEngineers3• 3 years ago

Yeah they do, however I was more interested in tinkering on projects on the weekends much like how I learnt to code. So many things seem to be simulation related with Gazebo or whatever, I’d be keen to build stuff but following a guide to help cover the EE parts.

mchusma2• 3 years ago

My 2 cents, as someone who has been mostly a hobbyist here. (1) Find a buddy who is also interested in it. Things are a lot better if you have a friend.

(2) Then try to build something based on turtlebot or similar platform. Start with just something you can make roam around your house and do stuff.

(3) If you can afford to budget something like $5k+ to it overall, it will be a lot easier. I have seen people try to do everything on a shoestring and it makes things a lot harder. The reason is hardware is hard, and you can move a lot faster if you can just throw things at it. E.g. instead of getting 1 Rasberry Pi or Jetson, get 2-3. Get extra cameras, get 2 extra bases.

A buddy and I got a fully working robot roaming around the house doing basic stuff (chasing dogs, etc) in about 3 months, but we both would just show up with new parts. Having a 3d printer is helpful to make things looking good, but not necessary.

RobotToaster• 3 years ago

How is package compatibility with the new version? When I looked at ROS before it seemed to have issues with certain packages only being available for older versions.

inamberclad• 3 years ago

ROS is a good research platform, but when it comes down to brass tacks, people stick with smaller, simpler systems. I've used NASA CoreFlight professionally and while it doesn't have all the nice creature comforts, I'm much happier in a small, clean, C-only codebase that runs on Linux, VxWorks, and RTEMS, with two layers of abstraction at most.

captaindiego• 3 years ago

I like ROS, the library of things you can use to get prototypes running quick is nice, but wish they hadn't rolled its own build system in addition CMake (Catkin) with the concept of packages, while not being a true package manager. Whenever your middleware dictates your build system things start to get pretty messy. My dream for ROS 2 (or maybe 3) is one where ROS does less instead of more - sometimes simpler is better.

ROS 2 Iron Irwini Release

Related Stories