3 ms·

I'm always looking for a ROS replacement. The limitations section at the bottom of the readme is excellent. Good level of detail and self-awareness. More proje

by huem0n 2y ago

I'm always looking for a ROS replacement. The limitations section at the bottom of the readme is excellent. Good level of detail and self-awareness. More projects need that. Sadly, while theres a lot of stuff I like, ultimately I don't think this is the ROS replacement the world needs. Specifically because of step 1: clone the repo (or add as submodule). Its a terrible move, IMO, to not have the pub/sub system be a binary executable or shared object file. ROS's fatal flaw (among many flaws IMO) is requiring every library-user to be able to build from source. I'm glad it doesnt dictate a folder structure, but I'm really sad to see this project continue the trend of needing to build from source.

huem0n 2y ago
To not be all negative though; I love the work on making it deterministic, and having first class docker support. ROS is such a crap-shoot when it comes to reproducibility. I mean bag files are great and all, but when its demo time on stage something always behaves inconsistently. I'm actually not a fan of the "bring your own serializer" design. I think just use one serializer thats fast (like protobuf) and then let other serializers be built on top of that (e.g. JSON). I could be wrong, but thats my hunch of a good system.
- a_t48 2y ago
  I'd like to very much encourage protobuf as the serializer, but supporting others both gives users the freedom to pick their own tradeoffs, and makes it 10x easier to transition from ROS or another framework. We do support JSON output from the serializer layer - I'd rather not do other conversions if possible.
a_t48 2y ago
We will eventually have a binary distribution. I chose not to for this release because it's not the workflow I want to encourage, and due to the management overhead of having to create packages for every combination of hardware/OS we'd like to support with a team of two (also, I need to learn the proper way to install headers with CMake...). I don't want to lock users to my OS of choice, I want to ensure it's easy to do things like turn on "-march=native" for the whole codebase, and I want it to be easy to fork and patch/customize. I don't get your comment about ROS - in my experience with ROS, most users don't build the distribution from source, they use apt or similar, up until they need to fork it to fix some bug or another (and then cry because you have to muck with apt's repository version syntax to use _your_ version of the package and not upstream). Regardless, I think it is important that users are able to build from source if needed - see above. Why would you like to restrict that?

by huem0n 2y ago

huem0n 2y ago

To not be all negative though; I love the work on making it deterministic, and having first class docker support. ROS is such a crap-shoot when it comes to reproducibility. I mean bag files are great and all, but when its demo time on stage something always behaves inconsistently. I'm actually not a fan of the "bring your own serializer" design. I think just use one serializer thats fast (like protobuf) and then let other serializers be built on top of that (e.g. JSON). I could be wrong, but thats my hunch of a good system.

a_t48 2y ago
I'd like to very much encourage protobuf as the serializer, but supporting others both gives users the freedom to pick their own tradeoffs, and makes it 10x easier to transition from ROS or another framework. We do support JSON output from the serializer layer - I'd rather not do other conversions if possible.

a_t48 2y ago

We will eventually have a binary distribution. I chose not to for this release because it's not the workflow I want to encourage, and due to the management overhead of having to create packages for every combination of hardware/OS we'd like to support with a team of two (also, I need to learn the proper way to install headers with CMake...). I don't want to lock users to my OS of choice, I want to ensure it's easy to do things like turn on "-march=native" for the whole codebase, and I want it to be easy to fork and patch/customize. I don't get your comment about ROS - in my experience with ROS, most users don't build the distribution from source, they use apt or similar, up until they need to fork it to fix some bug or another (and then cry because you have to muck with apt's repository version syntax to use _your_ version of the package and not upstream). Regardless, I think it is important that users are able to build from source if needed - see above. Why would you like to restrict that?