Here are some of the reasons why people do not prefer ROS for their robotic projects:
Difficulty in learning: It will be difficult to learn ROS from their default wiki pages. Most users depend on books to start with ROS. Even this book covers only the basics; learning ROS is going to be bit difficult.
Difficulties in starting with simulation: The main simulator in ROS is Gazebo. Even though Gazebo works well, to get started with Gazebo is not an easy task. The simulator has no inbuilt features to program. Complete simulation is done only through coding in ROS. When we compare Gazebo with other simulators such as V-REP and Webots, they have inbuilt functionalities to prototype and program the robot. They also have a rich GUI toolset and support a wide variety of robots and have ROS interfaces too. These tools are proprietary, but can deliver a decent job. The toughness of learning simulation using Gazebo and ROS is a reason for not using it in their projects.
Difficulties in robot modeling: The robot modeling in ROS is performed using URDF, which is an XML based robot description. In short, we need to write the robot model as a description using URDF tags. In V-REP, we can directly build the 3D robot model in the GUI itself, or we can import the mesh. In ROS, we should write the robot model definitions using URDF tags. There is a SolidWorks plugin to convert a 3D model from SolidWorks to URDF. But if we use other 3D CAD tools, there are no options at all. Learning to model a robot in ROS will take a lot of time and building using URDF tags is also time consuming compared to other simulators.
Need for a computer: We always need a computer to run ROS. Small robots that work completely on microcontrollers don't require a ROS system. ROS is only required when we want to perform high-level functionalities such as autonomous navigation and motion planning. In basic robots, there is no need to use ROS if you are not planning higher level functionalities on the robot.
ROS in commercial robot products: When we deploy ROS on a commercial product, a lot of things need to be taken care of. One thing is the code quality. ROS codes follow a standard coding style and keep best practices for maintaining the code too. We have to check whether it satisfies the quality level required for our product. We might have to do additional work to improve the quality of code. Most of the code in ROS is contributed by researchers from universities, so if we are not satisfied with the ROS code quality, it is better to write your own code, which is specific to the robot and only use the ROS core functionalities if required.
We now know where we have to use ROS and where we do not. If ROS is really required for your robot, let's start discussing ROS in more detail. First, we can see the underlying core concepts of ROS. There are mainly three levels in ROS: file system level, computation graph level, and community level. We can have a look at each level in short.
