3 ms·

Examples of poor decisions? I am just interested.

j-pb 7y ago
- Fundamental bug in the way they compute message schema checksums used for compatibility checks, causes buffer overflows and undefined robot behavior when changing array lengths. Is marked as wontfix because they don't want to recompile existing packages. - custom build tooling based on cmake is super cumbersome and buggy, and it means that you simply cannot communicate with ROS based stuff, without yourself becoming a ROS module that uses that custom build tooling - there is no QOS, messages are retained somewhat due to the topic semantic, but you can't tune retention parameters or resends
- protontypes 7y ago
  With roslibpy you can communicate with ROS stuff without being a ROS Node: https://github.com/gramaziokohler/roslibpy https://github.com/gramaziokohler/roslibpy "Unlike the rospy library, this does not require a local ROS environment, allowing usage from platforms other than Linux." Please also consider, that this is related mostly to ROS1.
  - a_t48 7y ago
    This is interesting, but won't you lose out on a lot of the benefits of using ROS in the first place? None of the tooling (command line tools and roslaunch stuff) that expects nodes will work.
  - j-pb 7y ago
    Yea I purposefully didn't include ROS-Bridge because thats another can of worms.
- rmattes 7y ago
  catkin packages are just CMake projects, and you can use find_package to discover them without making your module into a catkin package. I've written a few drivers this way without any problems (using existing message definitions.) For example: https://bitbucket.org/richmattes/si7021-sensor/src/master/CMakeLists.txt https://bitbucket.org/richmattes/si7021-sensor/src/master/CM... Lack of QOS (and many other things) are definitely a drawback of ROS. ROS 2 is built on top of DDS, which replaces ROS 1's bespoke messaging/transport and has a robust set of tune-able QOS parameters.
deleted 7y ago
[deleted]

j-pb 7y ago

- Fundamental bug in the way they compute message schema checksums used for compatibility checks, causes buffer overflows and undefined robot behavior when changing array lengths. Is marked as wontfix because they don't want to recompile existing packages. - custom build tooling based on cmake is super cumbersome and buggy, and it means that you simply cannot communicate with ROS based stuff, without yourself becoming a ROS module that uses that custom build tooling - there is no QOS, messages are retained somewhat due to the topic semantic, but you can't tune retention parameters or resends

protontypes 7y ago
With roslibpy you can communicate with ROS stuff without being a ROS Node: https://github.com/gramaziokohler/roslibpy https://github.com/gramaziokohler/roslibpy "Unlike the rospy library, this does not require a local ROS environment, allowing usage from platforms other than Linux." Please also consider, that this is related mostly to ROS1.
- a_t48 7y ago
  This is interesting, but won't you lose out on a lot of the benefits of using ROS in the first place? None of the tooling (command line tools and roslaunch stuff) that expects nodes will work.
- j-pb 7y ago
  Yea I purposefully didn't include ROS-Bridge because thats another can of worms.
rmattes 7y ago
catkin packages are just CMake projects, and you can use find_package to discover them without making your module into a catkin package. I've written a few drivers this way without any problems (using existing message definitions.) For example: https://bitbucket.org/richmattes/si7021-sensor/src/master/CMakeLists.txt https://bitbucket.org/richmattes/si7021-sensor/src/master/CM... Lack of QOS (and many other things) are definitely a drawback of ROS. ROS 2 is built on top of DDS, which replaces ROS 1's bespoke messaging/transport and has a robust set of tune-able QOS parameters.

deleted 7y ago

[deleted]