6 ms·

While hardware accelerators in robotics are very cool, and needed. The fact that the entire workflow is ROS2 centric is a bummer. FPGA and Accelerator Programmi

by j-pb 4y ago

While hardware accelerators in robotics are very cool, and needed. The fact that the entire workflow is ROS2 centric is a bummer. FPGA and Accelerator Programming is already a huge PITA, and despite it's success ROS is really one of the worst frameworks I've ever used in terms of DX. It makes an already hard problem, needlessly harder. I wouldn't be surprised if they developed their own FPGA programming environment based on C++ and CMake, and all kinds of other custom language and tool shenanigans.

octocop 4y ago
Do you mind sharing some of the issues that you are having with ROS2? I'm also using it and i find it quite straight forward.
pabs3 4y ago
What would you use instead of ROS?
- thendrill 4y ago
  arduino or rpi with something like mqtt, PyRemoteObjects on top , just a few off the top of my head.
- cmontella 4y ago
  Indeed, ROS set out to create an ecosystem of reusable robot software infrastructure, but a monoculture has grown instead. I started building a ROS alternative called Mech (see my profile) after becoming frustrated with ROS. It’s getting there but not ready for prime time yet. To answer the sibling comment, my biggest problem with ROS is how inscrutable it is for undergrads. I’ve witnessed students struggle to even install it while following directions step by step. It is a huge mess of incidental complexity, layering the complexity of C++ build systems on top of an IPC system on top of an expansive middleware. The learning curve is so high that when I spend a semester teaching robotics, students still struggle with ROS basics at midterms. The course turns into more about learning ROS rather than learning actual robotics. I’m hoping one day Mech will work along side and in conjunction with ROS to provide an easier way of doing things for those who want to get right to the heart of robotics.
  - metadojo 4y ago
    Bruh, take a step back for a second. ROS is a messaging system. Its like Microservices for Robotic components. If students are having trouble with ROS you might take a different angle on the purpose. When you teach ROS you are learning middleware patterns of integration first. Secondly you have to teach fundamental geometric concepts like TF. So thats why your students are having problems you are giving them too broad or too narrow or some convoluted context to reason about what they are doing. Try flipping the script.
    - j-pb 4y ago
      If only ROS were that. ROS wasn't a particularly good Middleware, and ROS2 isn't a middleware at all (DDS is a middleware, ROS is a framework using DDS). The issue with ROS isn't the general idea of communicating nodes over a blackboard and the accompanying standard libraries, but the huge pile of low quality tools, sparse documentation, ad-hoc architecture, bad code, and mediocre introspection tooling. A lot of that can be traced back to C++ and CMake, but ROS manages to take already complex tools and make them even more complex in an attempt to make them easy with automagic. If ROS2 had just opted for ProtoBuffers/FlatBuffers/CaptnProto over MQTT/NATS and build TF et.al as a library over that, we could just point students to the excellent documentation of the Serialisation Format, of the Middleware and to the (with all that freed developer time) much better documentation of the Robotics libraries, and call it a day. Instead they spend months with the idiosyncrasies of the build system, only to continue struggling with the documentation, and the sub-par tooling when something goes wrong. Cough only two seconds of time travel in ROSBags cough
  - ragebol 4y ago
    Why not provide a pre-set up machine? I would also not have them install eg Matlab or LabView themselves at the start of classes. But yes, I recognize the struggle. At my RoboCup team (TechUnited Eindhoven), the learning curve is also steep: from non-CS students that use Matlab on Windows, to using Linux with C++ & Python, ROS, git, not to mention our own stuff on top. It's a filter, to say the least.
    - 4y ago
- vmayoral 4y ago
  Use ROS 2. The misconceptions about ROS have been mostly addressed with ROS 2. Check out industry adoption of ROS 2 in various industries including automotive, healthcare and warehouse automation. ROS 2 is (and will remain as) the de facto standard for robot application development.
  - j-pb 4y ago
    The issue with ROS are mostly cultural, and heavily ingrained into the community. ROS2 isn't going to fix that and has been shown to repeat the same mistakes of ROS. The atrocious build system has stayed the same. People continue to add even more brittle automagic to the pile. (.e.g. automagic compilation of C++ to FPGAs) The grown semi ad-hoc messaging semantics for services has stayed the same. Even if DDS was an acceptable foundation, adding a ROS message translation layer and ROS semantics on top of a perfectly valid schema language is bringing the same pitfalls that Object Relational Mappers have, in that you now have to understand three systems, the source, the compiler, and the target. And given that ROS1 had a 'wontfix' issue on the message schema checksums being computed wrongly (ignoring the cardinality of fields), which could result in your robot literally ripping your head of when it received messages from two different library versions, I don't trust anybody from the community to get it right this time. The whole DDS vendor based ecosystem is antithetical to open source. The DDS standard is way too big, and a bunch of vendors meeting every couple years to demonstrate that their systems can send messages about shapes between one another simply doesn't cut it to prove correctness. ROS(2) is an attempt to make C++ more easy by layering automagic and complexity on top. Most robot shops I know waste most of their time fighting that magic and complexity. The other ones don't use ROS(2). ROS should have been: * A bunch of libraries (not frameworks) to solve robotics, vision, and knowledge representation related tasks. * A bunch of best practices to work with common middlewares, none of which are developed as part of ROS. * A repository of competing data schemata for the above libraries and middlewares to facilitate interoperability but allow for experimentation. * Dataviz libraries for common notebooks, e.g. jupyter, observablehq, that work with the common data schemata. Instead we got one of the hairiest C++ projects and a bunch of shell scripts to open your default text editor more conveniently. Yay.
- iancmceachern 4y ago
  Custom written stack
thendrill 4y ago
I have to agree with you on this one. Yes Ros looks hood on paper but the moment you open it, it just screams academia and academics. Also yes FPGA is faster for in general. But who is gonna program it ?
- vmayoral 4y ago
  Move to ROS 2 :)! Regarding who's going to create the accelerators, enablers like this allow any ROSser to jump into creating their own accelerator from C++ by purely adding some metadata into their CMakeLists.txt files (which every ROS package has already). On top of that, organizations are creating professional-grade kernels meant for production. NVIDIA and AMD are investing in that direction and so are we at Acceleration Robotics. Here're a few of the first ones announced: - Accelerated perception stack (ROS 2 API-compatible) https://accelerationrobotics.com/robotcore-perception.php https://accelerationrobotics.com/robotcore-perception.php - Accelerated coordinate system transformation (ROS 2 API-compatible, tf2) https://accelerationrobotics.com/robotcore-transform.php https://accelerationrobotics.com/robotcore-transform.php
pclmulqdq 4y ago
You have to remember that in a professional setting, the alternatives to ROS are atrocious pieces of crap like LabVIEW. From there, ROS is a step up! Both are programming environments designed by mechanical engineers, who care more about making easy problems really easy than making hard cases any better (after all, to a mechanical engineer, hard programming problems are really hard on their own).
vmayoral 4y ago
That's exactly what this work does while remaining ROS 2-centric (with C++, CMake extensions and other friends). Goal in this research was to provide a way for the path of least friction for roboticists. There's a huge gap between robotics development (more sw-centric today) and the average hardware engineer in big semiconductor companies. Totally different perspectives and viewpoints. We felt bridging the gap was necessary.

by j-pb 4y ago

octocop 4y ago

Do you mind sharing some of the issues that you are having with ROS2? I'm also using it and i find it quite straight forward.

pabs3 4y ago

What would you use instead of ROS?

thendrill 4y ago
arduino or rpi with something like mqtt, PyRemoteObjects on top , just a few off the top of my head.
cmontella 4y ago
Indeed, ROS set out to create an ecosystem of reusable robot software infrastructure, but a monoculture has grown instead. I started building a ROS alternative called Mech (see my profile) after becoming frustrated with ROS. It’s getting there but not ready for prime time yet. To answer the sibling comment, my biggest problem with ROS is how inscrutable it is for undergrads. I’ve witnessed students struggle to even install it while following directions step by step. It is a huge mess of incidental complexity, layering the complexity of C++ build systems on top of an IPC system on top of an expansive middleware. The learning curve is so high that when I spend a semester teaching robotics, students still struggle with ROS basics at midterms. The course turns into more about learning ROS rather than learning actual robotics. I’m hoping one day Mech will work along side and in conjunction with ROS to provide an easier way of doing things for those who want to get right to the heart of robotics.
- metadojo 4y ago
  Bruh, take a step back for a second. ROS is a messaging system. Its like Microservices for Robotic components. If students are having trouble with ROS you might take a different angle on the purpose. When you teach ROS you are learning middleware patterns of integration first. Secondly you have to teach fundamental geometric concepts like TF. So thats why your students are having problems you are giving them too broad or too narrow or some convoluted context to reason about what they are doing. Try flipping the script.
  - j-pb 4y ago
    If only ROS were that. ROS wasn't a particularly good Middleware, and ROS2 isn't a middleware at all (DDS is a middleware, ROS is a framework using DDS). The issue with ROS isn't the general idea of communicating nodes over a blackboard and the accompanying standard libraries, but the huge pile of low quality tools, sparse documentation, ad-hoc architecture, bad code, and mediocre introspection tooling. A lot of that can be traced back to C++ and CMake, but ROS manages to take already complex tools and make them even more complex in an attempt to make them easy with automagic. If ROS2 had just opted for ProtoBuffers/FlatBuffers/CaptnProto over MQTT/NATS and build TF et.al as a library over that, we could just point students to the excellent documentation of the Serialisation Format, of the Middleware and to the (with all that freed developer time) much better documentation of the Robotics libraries, and call it a day. Instead they spend months with the idiosyncrasies of the build system, only to continue struggling with the documentation, and the sub-par tooling when something goes wrong. Cough only two seconds of time travel in ROSBags cough
- ragebol 4y ago
  Why not provide a pre-set up machine? I would also not have them install eg Matlab or LabView themselves at the start of classes. But yes, I recognize the struggle. At my RoboCup team (TechUnited Eindhoven), the learning curve is also steep: from non-CS students that use Matlab on Windows, to using Linux with C++ & Python, ROS, git, not to mention our own stuff on top. It's a filter, to say the least.
  - 4y ago
vmayoral 4y ago
Use ROS 2. The misconceptions about ROS have been mostly addressed with ROS 2. Check out industry adoption of ROS 2 in various industries including automotive, healthcare and warehouse automation. ROS 2 is (and will remain as) the de facto standard for robot application development.
- j-pb 4y ago
  The issue with ROS are mostly cultural, and heavily ingrained into the community. ROS2 isn't going to fix that and has been shown to repeat the same mistakes of ROS. The atrocious build system has stayed the same. People continue to add even more brittle automagic to the pile. (.e.g. automagic compilation of C++ to FPGAs) The grown semi ad-hoc messaging semantics for services has stayed the same. Even if DDS was an acceptable foundation, adding a ROS message translation layer and ROS semantics on top of a perfectly valid schema language is bringing the same pitfalls that Object Relational Mappers have, in that you now have to understand three systems, the source, the compiler, and the target. And given that ROS1 had a 'wontfix' issue on the message schema checksums being computed wrongly (ignoring the cardinality of fields), which could result in your robot literally ripping your head of when it received messages from two different library versions, I don't trust anybody from the community to get it right this time. The whole DDS vendor based ecosystem is antithetical to open source. The DDS standard is way too big, and a bunch of vendors meeting every couple years to demonstrate that their systems can send messages about shapes between one another simply doesn't cut it to prove correctness. ROS(2) is an attempt to make C++ more easy by layering automagic and complexity on top. Most robot shops I know waste most of their time fighting that magic and complexity. The other ones don't use ROS(2). ROS should have been: * A bunch of libraries (not frameworks) to solve robotics, vision, and knowledge representation related tasks. * A bunch of best practices to work with common middlewares, none of which are developed as part of ROS. * A repository of competing data schemata for the above libraries and middlewares to facilitate interoperability but allow for experimentation. * Dataviz libraries for common notebooks, e.g. jupyter, observablehq, that work with the common data schemata. Instead we got one of the hairiest C++ projects and a bunch of shell scripts to open your default text editor more conveniently. Yay.
iancmceachern 4y ago
Custom written stack

thendrill 4y ago

I have to agree with you on this one. Yes Ros looks hood on paper but the moment you open it, it just screams academia and academics. Also yes FPGA is faster for in general. But who is gonna program it ?

vmayoral 4y ago
Move to ROS 2 :)! Regarding who's going to create the accelerators, enablers like this allow any ROSser to jump into creating their own accelerator from C++ by purely adding some metadata into their CMakeLists.txt files (which every ROS package has already). On top of that, organizations are creating professional-grade kernels meant for production. NVIDIA and AMD are investing in that direction and so are we at Acceleration Robotics. Here're a few of the first ones announced: - Accelerated perception stack (ROS 2 API-compatible) https://accelerationrobotics.com/robotcore-perception.php https://accelerationrobotics.com/robotcore-perception.php - Accelerated coordinate system transformation (ROS 2 API-compatible, tf2) https://accelerationrobotics.com/robotcore-transform.php https://accelerationrobotics.com/robotcore-transform.php

pclmulqdq 4y ago

You have to remember that in a professional setting, the alternatives to ROS are atrocious pieces of crap like LabVIEW. From there, ROS is a step up! Both are programming environments designed by mechanical engineers, who care more about making easy problems really easy than making hard cases any better (after all, to a mechanical engineer, hard programming problems are really hard on their own).

vmayoral 4y ago

That's exactly what this work does while remaining ROS 2-centric (with C++, CMake extensions and other friends). Goal in this research was to provide a way for the path of least friction for roboticists. There's a huge gap between robotics development (more sw-centric today) and the average hardware engineer in big semiconductor companies. Totally different perspectives and viewpoints. We felt bridging the gap was necessary.