The OTHER problem with ROS is that it only address what I call the "middle layer". It is not good for low level hardware control. It leaves uses one their own for that. It is also not good for the higher level decision making that I would call AI. So you and up building bridges at both ends.
The other huge complain is the complexity of the dependancies and the build system. It is such that only "experts" are able to port ROS to new platforms, even if the platform is very much like Linux, say BSD UNIX or MacOS. It is basically a house of cards, one tiny problem and nothing works. In theory a distributed system that depends on massage passing should not be so tightly coupled. I should be able to build a ROS node on using some OS I just invented and plug it into a years old ROS system and it should "just work". Every last bit of ROS should be ablate be build independently and the only interface should be the text of the massages pass. Itshould not all need to be built in the same work space.
Perhaps it is a cultural thing and we could correct this by hold a frequent "plug fest". This is where people bring devices built using diverse software code bases and test for interoperability. We see this in other areas why not in robotics
In my opinion the root cause is over coupling. entire idea of a "ROS work space" is likely the cause of this.
That said, of course I continue to use ROS, but it is far harder and slower to use then it should be.
---
[Visit Topic](
https://discourse.ros.org/t/why-dont-we-use-ros/3161/7) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)