[cmontella]

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.

[ragebol]

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.

[cmontella]

They all have their own laptops and prefer to use them. We also don’t have enough money to provide a computer for everyone. But I mean the setup is just one part of the issue, as you note. What I’ve found is I’ve had way more success teaching robotics to younger students via matlab/windows than Linux/ros/c++.

[j-pb]

I'm a huge fan of your work. Is there a reason why you didn't pursue the triple model of EVE and went with tables instead? It feels like the former would be such a great fit for the knowledge representation side of robotics.

[cmontella]

Hey, thanks! That's one of the main and crucial differences between Mech and Eve, actually. The main reason I went with tables in Mech is because of the robotics domain. Robotics has a lot of linear algebra and much of the math can be parallelized naturally. This means in Mech we can store columns as contiguous arrays, and take advantage of SIMD optimizations. The triple store in Eve worked well with the whole relational algebra nature of that language, so it was a natural fit there. Not so much for my use case.

Maybe there's room for an Eve-Mech bridge where Eve can be used on the knowledge representation side, and Mech for the lower-level motion planning stuff. That's a fun thought!

[j-pb]

Really interesting point. I always figured I'd go with an ECS system like specs for the high perf case, but you're absolutely right, columnar storage is gonna be orders of magnitude faster. (Fun fact, the hibitset of specs looks _a lot_ like a worst case optimal join.) A GPU/FPGA accelerated Mech would be really really cool :D.

A hybrid system is a really interesting idea. I actually wrote my bachelors thesis on a system heavily inspired by EVE to be used for knowledge representation in robotics and have been experimenting a lot with implementations of the idea over the years. You should really open a Mech discord channel, I'd love to hang around and help build something like that :D.

[cmontella]

Do you have a link to your thesis? I'd really like to read it!

GPU/FPGA Mech has been my dream since like... forever. I started taking a crack at it here: https://gitlab.com/mech-lang/core/-/blob/gpu/src/bin/gpu.rs, but mostly I was just figuring out wgpu's capabilities in Rust. But that was months ago and I've since decided to push it off until after I launch what I have done already.

I have a private slack that I've been using to work with my students, I'd love to send you an invite. Send me an email at [e-mail] and I'll send it to you. I've been putting off doing a discord channel because I wanted to code up a chat app in Mech instead :P I think I'm almost there but I've been thinking that for years >_<. If I don't have one by the time I launch in October I'll probably bite the bullet and do discord then.

[metadojo]

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]

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