Towards robot accelerators, democratizing hardware acceleration in robotics
news.accelerationrobotics.com
Towards robot accelerators, democratizing hardware acceleration in robotics
1–10 of 48 posts
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#2Looks 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.
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#3comparison using Jetson TX2 or Xavier could have provided better insight instead of Nano 2G which struggles even in basic task but otherwise looks quite promising
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#4While 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.
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#5While 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…
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.
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#6While 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?
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#7While 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?
arduino or rpi with something like mqtt, PyRemoteObjects on top , just a few off the top of my head.
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#8While 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…
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 ?
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#9While 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?
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.
Re: Towards robot accelerators, democratizing hardware acceleration in robotics
#10While 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…
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).