ROS is a catch-all solution in robotics. Goal is to reduce complexity in robotics development.
Take duckie-town as an example, exactly how much it is trying to mask over the complexity is quite obscure! The ROS’ way seems to be bit defying RCJ philosophy - i.e. kids being innovative. In order to use ROS, devices that they choose MUST use ROS abstraction layer APIs. The ultimate question is that is that our intention?!
The following is not the best explanation. (I have yet got the time to delve more time in dig deeper in ROS yet… Thus, the following is only what I envision after reading up the framework document.)
to do task X:
- using ROS, you must use ROS’s method A, then, subscribe B, then, do task X. Why that trouble? It is because ROS is trying to make it look the same for everyone even the hardware is different.
or - but then, I can just do task X myself, and select any hardware even when this hardware does not have the library interface through ROS.
ROS is supposed to be an elegant catch-all solution for using various hardware. While that is great for academic purpose, I strongly feel it is overly complicated. Besides, it does not seem making sense to confine kids to ROS.
Again, I do think ROS is beautiful idea, but seems impractical. This ROS somehow echoes the principles behind the CORBA framework in the old days. CORBA - catch-all solution for middle-ware.
- my 2cents thought
Elizabeth