Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards robot accelerators, democratizing hardware acceleration in robotics

news.accelerationrobotics.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#31

Post by metadojo »

cmontella wrote: post #9
pabs3 wrote: post #6

Earlier quoted context omitted.

What would you use instead of ROS?

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 i…

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.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#32

Post by ragebol »

cmontella wrote: post #9
pabs3 wrote: post #6

Earlier quoted context omitted.

What would you use instead of ROS?

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 i…

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.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#33

Post by LeanderK »

LeifCarrotson wrote: post #18

As a controls engineer who has implemented and assisted with dozens of robotic manufacturing cells, the problem isn't the motion planning or compute, it's legacy product support and ease of onboarding new hires. Any given cell may be in production for 10 years - some only for 5, but some for 20 or more - and you need The problem is that academia is working in ROS (now ROS 2), writing Python and VHDL, while the real w…

I may be misunderstanding your comment, but as I understood it you are talking about industry failures academia can't do anything about. If industry is massively behind on outdated, closed environments and academia work's with different, open tools then that's not academias fault. Like:

> it's legacy product support and ease of onboarding new hires.

I don't see how academia can help with this, this so very much an industry problem.

> But I need these to be accessible by Billy Joe, whose only credentials that got him the job in the maintenance department is that he helped out his daddy working with a welder and an old clapped-out Bridgeport on the farm growing up.

While accessible interfaces and forms of human-computer interactions are researched by academia, they are not building products. Research has to be relevant, but it's still research. Those problems, they might be better addressed by a startup than academia, if that's even realistic. Academia can't solve a problem if it's not a research-problem.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#34

Post by iancmceachern »

LeanderK wrote: post #33
LeifCarrotson wrote: post #18

As a controls engineer who has implemented and assisted with dozens of robotic manufacturing cells, the problem isn't the motion planning or compute, it's legacy product support and ease of onboarding new hires. Any given cell may be in production for 10 years - some only for 5, but some for 20 or more - and you need The problem is that academia is working in ROS (now ROS 2), writing Python and VHDL, while the real w…

I may be misunderstanding your comment, but as I understood it you are talking about industry failures academia can't do anything about. If industry is massively behind on outdated, closed environments and academia work's with different, open tools then that's not academias fault. Like: > it's legacy product support and ease of onboarding new hires. I don't see how academia can help with this, this so very much an in…

That's what he is saying. ROS is made, lead, by academia. He is saying that ROS isn't terribly useful in industry for the reasons he lists.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#35

Post by iancmceachern »

cs702 wrote: post #22
LeifCarrotson wrote: post #18

As a controls engineer who has implemented and assisted with dozens of robotic manufacturing cells, the problem isn't the motion planning or compute, it's legacy product support and ease of onboarding new hires. Any given cell may be in production for 10 years - some only for 5, but some for 20 or more - and you need The problem is that academia is working in ROS (now ROS 2), writing Python and VHDL, while the real w…

After reading this, I'm persuaded this space would benefit greatly from having a few dominant open-source software frameworks and a few dominant open-source hardware standards, making product support and new-hire onboarding much easier for vendors of all sizes. Alas, I recognize that no established vendor in the space would ever want to see the emergence of industry standards. :-P

What you describe is ROS. The issue is that industrial manufacturers of things like arms or motion controllers all have their own proprietary stuff.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#36

Post by iancmceachern »

pabs3 wrote: post #6
j-pb wrote: post #4

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 b…

What would you use instead of ROS?

Custom written stack

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#37

Post by cs702 »

iancmceachern wrote: post #35
cs702 wrote: post #22

Earlier quoted context omitted.

After reading this, I'm persuaded this space would benefit greatly from having a few dominant open-source software frameworks and a few dominant open-source hardware standards, making product support and new-hire onboarding much easier for vendors of all sizes. Alas, I recognize that no established vendor in the space would ever want to see the emergence of industry standards. :-P

What you describe is ROS. The issue is that industrial manufacturers of things like arms or motion controllers all have their own proprietary stuff.

What I describe is what ROS supporters want it to be. As I wrote, no established vendor in the space wants to see the emergence of commodity industry standards. It seems that for the foreseeable future, we're stuck with the status quo.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#38

Post by meowtastic »

vmayoral wrote: post #17
meowtastic wrote: post #2

Looks impressive to a layman like myself. I'm guessing it addresses the global shortage of single-board computers like Raspberry Pis right? Curious to know how long it'll take to do that as well.

Well, yes but not only. There's only so much you can do with Pis and other SBCs that offer a CPU-centric compute solution. Robots are real-time systems and CPUs don't excel at that. When optimizing dataflows for lower latencies and higher throughputs, you typically seek specialized compute architectures and that's wherein GPUs and FPGAs come in. That's what this work really enables.

I see, thanks for the explanation!

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#39

Post by cmontella »

ragebol wrote: post #32
cmontella wrote: post #9

Earlier quoted context omitted.

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 i…

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.

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++.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#40

Post by j-pb »

metadojo wrote: post #31
cmontella wrote: post #9

Earlier quoted context omitted.

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 i…

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 broa…

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

Post reply on HN