8 ms·
Robotics and ROS 2 Essentials
- fyhn 2y agoThose of you who use ROS in production, do y'all use ROS 1 or 2? Do you maintain your own fork? I'm curious how people do this, with the upcoming Noetic deprecation.
- im_down_w_otp 2y agoWhat's that old robotics industry saying? "You either die trying to scale ROS to production, or you live long enough to repeatedly reinvent it?" - Johnny 5
- f1shy 2y agoWhere I was, 1 was standard, 2 experimental and nothing worked really. Slowly a half assed, bug ridden internal implementation of ROS 2 was started… a sh*tshow to be honest. The discontinuity between R1 and R2 was for me just unacceptable, unprofessional and just awful. If I could decide (and in the area where I am, we did) I would ditch the whole thing. After all, if you squint, ROS is a collection of things: - a launcher (which is a very bad scripting language embedded in horrible XML). Can be very easy be substituted by some python or shell scripts. - a description language of messages, that can be read by C, Python and Lisp; can be substituted by raw sockets or google protocol buffers or whatever. - a parameter/configuration distribution system, which can be implemented based on libconfig (https://github.com/hyperrealm/libconfig https://github.com/hyperrealm/libconfig) All that options are pretty much standard, stable and well supported, with bindings for any mainstream language. I would run away from ROS2 to avoid another disaster when ROS3 comes.
- exe34 2y agohi, I've dabbled in robotics from a hobbyist perspective, and I've gotten as far as installing ROS and following some tutorial and online courses a few times. I agree with what you said about launcher/ipc/config - my plan if I ever use Ros is to keep it in a box and use my own communication layer to connect with things in various environments (rather than trying to solve incompatible conda environments). however one thing you've missed, which may well be the biggest offer from Ros and the reason why I haven't sworn off it entirely is the library of robotics functionality such as SLAM and various planning algorithms. in your opinion, are these at least well implemented? would they be easy to rip out and run separately?
- dima55 2y agoWell, if 9/10 of a thing is a dumpster fire, would you expect the last 1/10th to not be?
- f1shy 2y agoYou said it much better “ launcher/ipc/config” My suggestion: start with ROS, but make absolutely sure to separate ROS from your “business intelligence“. The one think I hate from ROS, is that it makes it difficult. But keep them separated. Also the launch IPC and config parts, don’t do them dependent from each other. If possible do not rely on launcher. So later you can switch away if needed. And you will need. ROS is great for prototyping, changing things, development. But is just not for deploying in production. The whole possibility of inspecting the messages between nodes, means you have to pay a price. > in your opinion, are these at least well implemented? would they be easy to rip out and run separately? Not a simple answer: - from the architecture pov i think many questionable decisions were made: you need to master many languages: XML, launch, message files, yaml, python or C, Cmakefiles for catkin… why?! Why not making launcher files, messages all just yaml or json? Just too complex for nothing. - The code, you can look yourself, is write only. No way you can change anything without needing 1 year understanding… - BUT: it does work, and works well. I’ve not found a kill bug or something. So, I guess is ok.
- exe34 2y agothank you!
- ModernMech 2y ago> After all, if you squint, ROS is a collection of things: ROS came about because before ROS existed, robotics researchers cobbled together ad-hoc ROS-like systems using the tools you point out. ROS itself started as a project called "Switchyard", which was built to operate one of Stanford's robotics projects. Research labs around the country each had their own take on this kind of system, which made sharing research very difficult. What ROS did was standardize the platforms between all labs, enabling us to share our algorithms, which at the time mostly revolved around localization, mapping, and path planning.
- spieswl 2y agoI'd imagine it runs the gamut. ROS for some older places; those starting fresh are probably doing ROS 2.
- patrick451 2y agoWe use ros1 today. We have a very slow moving effort to migrate things to ros2 that I'm not really involved with. A previous job used ros2. IMO, it's worse in most ways compared to ros1. The launch system of ros2 alone is enough reason not to use it.
- amacneil 2y agoI run a robotics dev tools company and we work closely with companies of all sizes across the robotics industry, so have a unique perspective on this. I would say about half of the industry (read: for-profit robotics startups from early stages through to 10,000s of robots in production) uses ROS, and of those probably 2/3 are on ROS 2 at this point, and the rest are in some stage of migration. ROS 2 solved a lot of problems that didn't need solving, but like it or not ROS 1 is abandonware at this point so almost no one is planning to stick with ROS 1 longer than they have to. Most companies aren't maintaining their own fork of ROS (other than to submit patches upstream), but a small number of companies on ROS 1 forked it and diverged so significantly that there is no point trying to rebase on ROS 2 - of these GM Cruise was the most notable, although the future of their stack is unknown now that GM canceled the robotaxi project. The other half of the industry uses some sort of in-house stack built from parts (compare batteries-included frameworks like rails/django to building a backend using libraries like expressjs and sequelize). There is usually some form of pub/sub messaging architecture, because pub/sub is a natural fit for robotics and makes it easier to log and replay/resimulate. Some common things I see are zeromq, vanilla DDS (no ROS), zenoh, or write their own pub/sub (sometimes using shared memory). The messages themselves are often protobuf, flatbuffer, cbor, json, or sometimes just raw c structs. Building your own stack isn't hard, but its much easier if you have used ROS before and know which concepts you want to reuse, rather than reinventing everything from first principles. Some newer robotics frameworks are also starting to spring up which is great to see, for example https://github.com/copper-project/copper-rs https://github.com/copper-project/copper-rs and https://github.com/dora-rs/dora https://github.com/dora-rs/dora There are also frameworks more specifically targeted towards robot learning, for example https://github.com/huggingface/lerobot https://github.com/huggingface/lerobot If people are just starting out in robotics, or just starting a robotics company, I still recommend ROS despite its warts, it is worth learning because it has had such a big influence on the current ecosystem. There is no "right answer" though, many companies have been successful with each approach.
- rubicks 2y agoYou treat it like the metaphorical toxic waste it is: avoid it at all costs. You don't need ROS to get a dependency manager, a build system, a middleware, and/or a process manager.
- jvanderbot 2y agoFor a while new grads had a severe lack of hands on ROS experience. Though many companies don't use ROS, it is so entrenched in the industry that most solutions look similar enough for transferrable skills. (Src: was hiring mgr in robotics) Highly recommend if you want to get into robotics you have ROS experience and demos / stories at hand.
- brutus1979 2y agoI'm really intrigued by robotics as future career. How would you rate it for the next 10-15 years? I'm seriously thinking of investing in a masters degree focused on robotics (CMU). I'm close to 50 and already have a cs PhD. Just intrigued by it and feel it might have a longer career (when it takes off).
- f1shy 2y agoYou have a CS PhD? I highly doubt you can learn something there. If it is about knowledge, find out what books are used in the masters. With a PhD you must be able to learn yourself
- ModernMech 2y agoRobotics is very different from CS. At CMU robotics is huge and consists of thousands of researchers, with dozens of classes a MS student would have never encountered during their CS PhD or undergrad. It's true you can learn robotics from books, but CMU or any grad program has access to robotics hardware resources you can't find online or in the library. For example I took a course there that had the Aldebaran Nao as a platform. The course has a dozen of them, at the time they were worth $20k a piece.
- f1shy 2y agoAbout the theory, you can learn yourself (I think) about practice, well, you may learn 1 or 2 platforms, but not all. If you get a job, you will for sure have to learn a lot from the platform they use, but much more of the application they do. Also the platforms get obsolete fast… What about buy 2nd hand/use/resell some hardware? I do not know how much cost a Ms in CMU, but sure does bot even compare to 20k. Sorry maybe I’m a little bit negative, but if you have already one good title, that is more than enough. The problem is I fully subscribe to Stallone[0] [0] https://m.youtube.com/shorts/srEsT5h4gdo https://m.youtube.com/shorts/srEsT5h4gdo
- margalabargala 2y agoWhile it's used in industry sometimes, ROS is really one of those by-and-for-academia tools. There's a reason it's near-universally reviled, and why "migrate off of ROS" is a standing goal at a lot of robotics companies. There's also a reason why it's a standing goal, rather than a completed goal. It does little or nothing really well, but it does everything kind of okay. There's a lot of "alternatives", most of which do something much better, sometimes much much much better, than ROS, but none of which can replace it all completely. PyRobot, Viam, OROCOS, Webots, all of these do some things much better than ROS, but none of them can drop in and easily replace everything without a lot of developer time, often adding new features to the platform.
- liendolucas 2y agoI suffer it so much every single time I have to interact with it that sometimes I really really want to do something else, but I can't. Unfortunately is not my call, is part of my job. I have already made my opinion about ROS in a previous thread, but another user synthesized it very clearly: it's a trainwreck. Now we can be more precise: it's an academia trainwreck tool.
- forrestthewoods 2y agoWhat is your opinion of ROS? I can’t find the previous thread you mention.
- liendolucas 2y agohttps://news.ycombinator.com/item?id=40631558#40634889 https://news.ycombinator.com/item?id=40631558#40634889
- oarfish 2y agoTrust me, having your own crufty cobbled-together robotics code base that gets more and more insipid over time is way worse. 10/10 would start anything new with ROS.
- 2y ago
- wslh 2y agoBased on the Andino robot project [1] the price is greater than USD 250 [2] I wonder how far we can push the price down for schools. For example, putting an [old] mobile phone (with a camera and replacing the battery), and moving to ESP32 and use another OS. [1] https://github.com/Ekumen-OS/andino/ https://github.com/Ekumen-OS/andino/ [2] https://docs.google.com/spreadsheets/d/1TMbENKlHr4g9bBA-EPNuTyLKbku6SCwj58utU9mCj5Y/edit?gid=0#gid=0 https://docs.google.com/spreadsheets/d/1TMbENKlHr4g9bBA-EPNu...
- adeptima 2y agoHad a recent conversation with nephew about his robotics study, and it seems he’s overwhelmed with ROS, OpenCV, Python, AI transformers tutorial hell. Told him we should go together to industrial expo - starting from 3d printing, molding, material science and robotics and spend some time together to hack into hard core C++ SDKs used by big tech like Nvidia and Co, and look how to developed linear algebra and statistic on real life examples. His dream is to automate small mid business manufacturing, and become a Steve Job like figure one day. What’s the good information and resources to follow and educate about real life robotics? Any tips or even sarcastic comments are welcome. Please help to be a cool uncle ;)
- puffybunion 2y agoCan someone that hasn't achieved Steve Jobs' accomplishments show you the way to them? Perhaps you should gift him a biography about Steve Jobs.
- adeptima 2y agoI knew the guy who worked with Jobs and hated him with passion. Let's keep the useful image parts. “How many of you are from manufacturing companies?” [Some hands go up.] “Oh, excellent. Where are the rest of you from? Okay, so how many are from consulting?” [A number of hands go up.] “Oh, that’s bad. Yeah, the mind is too important to waste—you should do something.” “I think that without owning something over an extended period of time—like a few years—where one has a chance to take responsibility for one’s recommendations, where one has to see those recommendations through all action stages, accumulate scar tissue for the mistakes, pick oneself up off the ground, and dust oneself off, one learns only a fraction of what one can.” https://www.youtube.com/watch?v=Gk-9Fd2mEnI&t=184s https://www.youtube.com/watch?v=Gk-9Fd2mEnI&t=184s
- exe34 2y agoI don't think a lot of Olympics gold medalists are taught by former Olympics gold medalists. Most teachers never go on to accomplish what their students achieve. I think OP has a fair chance of giving the nephew a great start - and whether that leads to Jobs level of accomplishments will depend on perseverance and luck.
- mrtb 2y agoI'm new to embedded systems programming and looked into ROS recently, without using it, while figuring out a minimal software stack for a UAV project (px4 over ArduPilot for the flight controller, but what to run on a "companion" computer is open ended). [my XP is in cloud infra, RESTful microservices, web apps, videogames] Researchers, hobbyists, and some industry professionals (for prototyping?) seem to love ROS for its big community, logging/debugging/visualisation tools (rosbag, rviz), the pub/sub architecture (easy integration and loose coupling with third party modules), existing support for many sensors/peripherals/hardware components; plus off-the-shelf libs for SLAM, navigation, inverse kinematics, etc. But ROS is hated by others for its custom build system (on top of CMake), the custom language-agnostic IDL for message types (like Protobuf but worse, esp. for versioning and backwards compatibility), non-determinism and untestability of the pub/sub model (esp. for safety-critical stuff), overengineering and layers of indirection / learning curve, poor performance, and high platform lock-in. Looking at ROS as a robotics noob, it seems like useful 'muddleware' for toy projects, but where every sub-problem that it abstracts away from you can be solved better by other existing tools. I'm looking more into: Mobile Robot Programming Toolkit [1], Yet Another Robot Platform [2], genom3 [3], and Open Robot Control Software [4] (all C++). Or the Rust ones like RoboPLC [5], Dora-rs [6], Copper-rs [7], and Basis [8] (which supports Protobuf!). If you're not using ROS for a "serious" project, do you use other middleware offerings or just pick 'n' mix lower-level libs tailored for your use cases? [1] https://mrpt.org https://mrpt.org [2] https://www.yarp.it https://www.yarp.it [3] https://git.openrobots.org/projects/genom3 https://git.openrobots.org/projects/genom3 [4] https://orocos.org/ https://orocos.org/ [5] https://github.com/roboplc/roboplc https://github.com/roboplc/roboplc [6] https://github.com/dora-rs/dora https://github.com/dora-rs/dora [7] https://github.com/copper-project/copper-rs https://github.com/copper-project/copper-rs [8] https://github.com/basis-robotics https://github.com/basis-robotics
- a_t48 2y agoCorrection - Basis will be Rust compatible in the future. :)
- janice1999 2y agoIs ROS 2 approachable for a teenager interested in electronics and what hardware would you recommend for them (considering it as a present for a family member)?
- exe34 2y agofor a teenager, I definitely wouldn't recommend Ros, unless they're already very deep into Linux, c++, build systems, etc - I'm sure there are kids out there that can handle it, but I'd say most would find Ros endlessly frustrating. I think it makes grown men cry. robot wise, I'd recommend something they can program with a raspberry pi and python, if they have some light background in programming. I had a quick look on Amazon and I have no affiliations with these, but maybe look for something like this: https://www.amazon.co.uk/FREENOVE-Raspberry-Tracking-Avoidance-Ultrasonic/dp/B0BNDQFRP1/ https://www.amazon.co.uk/FREENOVE-Raspberry-Tracking-Avoidan... note this one doesn't have either a raspberry pi nor any batteries. you might find a better one.
- rubicks 2y agoCan confirm. I am a grown man and my professional work with ROS has made me cry.
- inetknght 2y agoI tried to use ROS2 twice in my professional career. Both times ended up with massively bloated build pipeline code, significantly longer build times, and massively bloated Docker images. Don't use ROS2. The benefits just aren't worth it. It's great for school but it's terrible for production.
- pattycakes 2y agoSounds like your build system is the problem, not ROS.
- markisus 2y agoLast time I used ROS, it forced you to use its build system. Catkin or something? It was a layer on top of Cmake.
- rubicks 2y agoMy colleagues and I used to joke that any build system issue you encounter will be addressed in next year's build system. * https://wiki.ros.org/rosbuild https://wiki.ros.org/rosbuild * https://wiki.ros.org/catkin https://wiki.ros.org/catkin * https://docs.ros.org/en/jazzy/Tutorials/Beginner-Client-Libraries/Colcon-Tutorial.html https://docs.ros.org/en/jazzy/Tutorials/Beginner-Client-Libr... * https://docs.ros.org/en/jazzy/How-To-Guides/Ament-CMake-Documentation.html https://docs.ros.org/en/jazzy/How-To-Guides/Ament-CMake-Docu... It doesn't feel like a joke anymore.
- 2y ago
- causal 2y agoI loathe ROS as much as the next guy but is there any serious free alternative with much community?
- asadalt 2y agoi am dealing with ros these days for calibrating my custom hardware. it really is gROSs. Thankfully, I have fully isolated ROS parts into their own dockerfiles.
- yalogin 2y agoThis is exactly what I am researching right now. I am working on a project build a robot that maps its surroundings and walks around. The goal is to learn some AI (slam and camera based ML) and also hardware (Robot itself). I am thinking of raspberry pi with cameras and then using just building the slam algo from scratch. Is this a good option or am I trying to bite off more than I can chew. I understand ML theory but haven't done any other than the basic 101 ML programs and the coursera course. I am fluent in OS (systems), C, python. Can folks with knowledge opine on this? Are there better ways to learn ML? I chose the robot so I can have something to keep on building/adding
- aktenlage 2y agoDepends on what you want to learn. The SLAM Frontend (computing motion information from sensors) offers a lot of variety through the chosen combination of sensors (wheel odometer, IMU, mono/stereo/multi camera, lidar, radar, sonar, to name a few). At least for vision, deep learning should be very useful. For the others I have no experience how much machine learning is relevant. Geometry and physics based methods should work well here, but there is probably much room to tack on some ML. The SLAM backend (optimization) is mostly old-school methods like nonlinear least squares optimization or particle filters. Not sure if that counts as ML today. I'd go for g2o or Ceres for mapping (unless you expect to have no loop closures), as there's really no need to reinvent that. It's definitely useful to learn about the backend, but usually the combination of sensors and their properties will demand more algorithmic tailoring than the backend, which gets more abstract input (i e. motions & uncertainties) and can be used more black-boxy.
- yalogin 2y agoThanks for the input, would you recommend developing slam from scratch or start with some libraries and tailor it to my sensors?
- anymouse123456 2y agoWe have a handful of devices built on STM32, RP2040, RP2350, RP Pico and RP Pico-W running bare metal firmware and green threads for task management. These were generally designed to communicate over UART (to a physically-connected host) or a LAN (wired or wireless) using MQTT topics and plain text message formats. We have a primary, core machine built around Linux SOMs like NVidia's Orin or the RPI5, which could run real software (like ROS). I expect to have dozens and eventually many hundreds of nodes in a variety of facilities. So far, things were going pretty well, though very sparse in terms of tooling. For example, I've got a makeshift midi controller (for physical knobs) that uses a Python script, debug connectors, and messy gnuplots to do PID tuning. I got pretty pumped about the Foxglove Studio product and pulling on that thread led me into the (completely awesome) YT channel "Articulated Robots" (https://www.youtube.com/@ArticulatedRobotics https://www.youtube.com/@ArticulatedRobotics), which led us down a path to seriously considering a move toward ROS2. I wrote it off a couple years ago (2021/2022-ish) for a handful of reasons: a) The move from ROS1 to ROS2 triggered my PTSD from my time at Google where everything had 2 versions: One that's deprecated, and One that's not ready yet. It also triggered trauma from Python's ongoing and complete disregard for backward compatibility. b) It's obviously designed to run on Linux, but I have a bunch of low-cost bare metal micros driving around. What the hell kind of robotics platform doesn't (by default) run on microcontrollers? c) CMake is already one of the absolute worst piles of trash I've ever encountered in nearly 25 years of software development. Wrapping CMake (twice now!?), which is already a crap wrapper is so obviously such an awful idea that it's tough for me to trust anyone who had part in that decision. d) C++. No thank you. Slow builds are a non-starter. C is fine IMO. Now, I've spent 4-5 days watching videos, doing tutorials and bringing up ROS2 topics and basically fiddling around with it and just learned that Google(ish) bought the core team, which has me deeply concerned about the future of the platform. I'm actually still kind of interested in the DDS portion of ROS2, but the whole mess trips my spidey sense and has me feeling like dragons be lurking. Seeing this thread with so many people speaking so negatively about it has me desperately wanting more information. Can anyone point me to anything that presents concrete problems and (better) alternative systems that work?
- rcxdude 2y agoThe one over-arching issue I'd point to is that network pub-sub is the way to connect different parts of your system in ROS, and that's a bad default, and an even worse single option. For most data-flow, you probably don't want to be hitting a serialisation step at all, but if you do, you probably want to be thinking carefully at the system level about how to move it around (how much data, what latency, from what kind of system to what other kind of system, how to deal with failures, corruption, etc), not just throwing it all into a general one-size-fits all approach. ROS systems tend to have multiple key control loops running through a transport that really likes to foul them up, and make for slow, unreliable behaviour. Most robotics projects that use it can get to it doing something pretty quickly, but getting it to work more than 20% of the time is a huge struggle. Otherwise, concrete problems are a bit harder to talk about, because they're very diffuse: while ROS has a lot of components and tools you would want in a robotics system, and they are all integrated together, the average quality is very low: they are on average slow, buggy, hard to use, and tend to lack important features, from build systems to GUIs. While it's tempting to use a it out of the principle that you shouldn't be duplicating work, in general I would say most robotic applications are far better served by using a custom framework that better fits their system design, using appropriate libraries for each part, but not an off-the-shelf do-everything framework (and it feels like there are gaps that could make this less effort, but in my experience writing your own replacements for ROS components is less effort than dealing with all the problems that come with using it: it's shockingly low effort to reach feature parity). (NB I haven't touched ROS for a while, but it doesn't seem like this has improved much, though there's been plenty of code churn)
- cahaya 2y agoRecommendations? I'm seeking a robotics course akin to prompt engineering, LangChain, or LangGraph that prepares me for the 'ChatGPT' moment in robotics. While SLAM navigation and similar topics are vital, it feels reminiscent of five years ago when one needed to master machine learning to create their own ML models. Nowadays, most LLM models are API-based and don't require an ML background.
- doganulus 2y agoThe ROS project has terrible governance, and the community suffers heavily from groupthink. I just got banned from their forum for questioning what the ROS Foundation has done in the past two years--specifically on the build system. Yes, their middleware is unforgiving of alternative ways other than their wrong and outdated development practices, but their community is more religiously attached to their precious tools for development. This is the post I wrote: https://discourse.ros.org/t/build-systems-package-management-and-nix/41488/47?u=doganulus https://discourse.ros.org/t/build-systems-package-management...
- esteve 2y agoNo, you were not banned, your permission to post publicly was restricted because for the past three years you've been insulting, spreading lies and refusing to cooperate with other members of the community who actually want to change things and improve ROS. You're the one who is taking this personally because you claim Open Robotics is going after you. You've broken the code of conduct numerous times. The fact that you're incapable of any introspection and realizing that other people in that same thread are criticizing ROS in a civilized way and who are also proposing alternatives to ROS' build system, while you're just adding noise and whining about being personally targeted, makes Ryan's decision to restrict your permission to post publicly even more reasonable.
- doganulus 2y agoGroupthink is what happens when people don't share their dissenting views, so the group as a whole makes poor decisions. This is why it is a bad idea to silence dissent. This defines the ROS community, as you have exemplified. So it is good that you come and read the comments here. Welcome!
- esteve 2y agoMany people in that thread you linked to have criticized ROS and explained the issues they have with the build system, some even proposed improvements, but somehow you're the only one that had to have their permissions restricted because of your behavior. And that's after repeatedly breaking the code of conduct for years. I've yet to see any technical contribution from you in ROS or any other project. You don't know what groupthink means, you only know to play the victim, and even in that, you're doing a terrible job.
- saddat 2y agoAny thoughts on the take over of ROS developers by Google/Intrinsic ?
- BenFranklin100 2y agoROS is painful to work with and doesn’t scale well. It’s a shame Microsoft abandoned Robotics Developer Studio over a decade ago. Robotics Developer Studio started off in a promising direction. It had the CCR (Coordination and Concurrency Runtime) and the DSS (Decentralized System Services) which together made it possible to coordinate real time robotics in a RESTful environment across distributed hardware. It had also had full access to .NET. There’s never been anything quite like it since. Unfortunately MS pulled the plug before it had a chance to mature into an easy-to-use well documented platform.
- zoran3431 2y agoOk I will just say it. ROS sucks and is a nightmare to use. When it does work it doesn't work well. I am not sure why we continue to use this outdated programming method. I have several robot. All of them could use ROS but I choose not to torture myself with what a mess that would be. Now a days coding or programming does not have to be unenjoyable. If you want to not use the dreaded ROS method to kill your brain then use ChatGPT 1.o this will change the way you code forever and you will actually enjoy it and look forward to coding with it. It takes the nightmare away that ROS created. No one wants to use ROS let's be honest. So finally there is a better way. ChatGPT 1.o makes ROS to look like an outdated mess.
- RugnirViking 2y agowhat? I love ROS. There are setup files for stuff inside ROS (pathfinding etc) that I haven't enjoyed, and I've definitely struggled with things like keeping it all standardised with like dockerfiles, but the ROS itself? the concurrency is amazing. I constantly wish I had it on non-robotics projects... as others have mentioned, it has scaling issues. But for getting things done on a base level, its super powerful. The fault-tolerance it allows has benefited our robots a lot - it's often possible even with severely degraded systems to manually guide one around. I do agree with what others have said about how the best usages are often to not go too deep into the ecosystem and instead use its messaging and concurrency protocol in limited ways, and have a lot of your internal logic siloed, to avoid hardcore dependency. After all, the idea of this kind of system is to allow new nodes to listen to sensor data (coming in) and/or planning goals (going out) to be able to make their decisions. Not passing some kind of intermediate calculation to some other subsystem
- doganulus 2y agoROS is like the One Ring. Binds everything in the darkness but corrupts you into his dark slave slowly. It must be thrown away into the hot lava.
- Waterluvian 2y agoWorked with ROS in research, industrial, and warehouse spaces for 12 years now, with fleets of hundreds to thousands of robots, tens to hundreds of thousands total worldwide. If there's one thing I could convince people of, it's to never use ROS to communicate between hosts. If you want to use ROS for IPC on the same host, fine. That can all be debated but okay. But if you want to communicate to different robots, especially over WiFi, ROS is missing most of what you need, and it's things that roboticists do not need to reinvent as the Web has been grappling with these issues for a lot longer by millions of more developers. - You will have to worry about versioning, either on your terms of when you're inevitably forced to - Even if you don't plan on operating multiple versions in harmony (years later you'll regret believing you could get away with this), you have to deal with the edge effects of when you upgrade them remotely/on-site. - ROS API definitions ("ROS Messages") are defincient. Yes, you really need to support `null` but you also need a whole lot more expessiveness in general. You'll invent your own string-but-actually-json message at some point. - You end up manually dealing with well-trodden problems like compression, authentication, authorization. - Failed comms, reconnecting, retrying, etc. will be a huge pain. I think the simplest question to ask yourself/team is: "Could this be an HTTPS API? Could this be a Websocket? Do we even have the correct skills on the team to answer this question or did we only hire ROS people?"