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

41–48 of 48 posts

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#41

Post by j-pb »

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…

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.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#42

Post by mncharity »

LeifCarrotson wrote: post #28
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

It definitely would. RoboDK is one product that is moving in the right direction. In the PLC space, Beckhoff controllers using commodity x86/64 hardware and standardized IEC 61131 programming languages are gobbling up Rockwell and Siemens' market share. Given they're perpetually about 20 years behind the times, perhaps this year someone at Fanuc, ABB, Kuka, and Yaskawa will catch up to the year 2002 and read Spolsky'…

> IEC 61131 programming languages

A very brief search turned up assorted overviews[1][2][3], and a github topic[4]. The PLCopen standard[5] is paywalled - only $400 single user, with low low per-seat multipliers! :/

[1] https://en.wikipedia.org/wiki/IEC_61131-3 [2] https://dc-us.resource.bosch.com/media/us/products_13/produc... [3] https://www.controleng.com/articles/which-iec-61131-3-progra... [4] https://github.com/topics/iec61131-3 [5] https://plcopen.org/iec-61131-3

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#43

Post by cmontella »

j-pb wrote: post #41
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…

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.

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!

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#44

Post by metadojo »

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…

you are leaving out a whole host of use cases bro. maybe in the past robotics was just for industrial use cases. but there are orders of magnitude other use cases that a ROS can help solve. simple things around the house , in the neighborhood, and other mechatronic integrations that would not properly called a robot. I would say the ones you are addressing with billy bob on the 3rd shift are like 1 percent of the cases. There are plenty of things you can actuate in the world that dont require sub mm repeatability. like what about tending my hydroponic vertical garden? theres nothing about the ubiquitous robotic future of humankind that needs any of the things you mentioned. thats more of an improvement on current use cases.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#45

Post by j-pb »

cmontella wrote: post #43
j-pb wrote: post #41

Earlier quoted context omitted.

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.

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

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.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#46

Post by cmontella »

j-pb wrote: post #45
cmontella wrote: post #43

Earlier quoted context omitted.

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

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

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 corey@mech-lang.org 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.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#47

Post by LeifCarrotson »

iancmceachern wrote: post #34
LeanderK wrote: post #33

Earlier quoted context omitted.

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.

Exactly. Advancements and capabilities in university press releases like this don't result in real-world improvements because the two fields are divergent.

Re: Towards robot accelerators, democratizing hardware acceleration in robotics

#48

Post by iandanforth »

vmayoral wrote: post #26
iandanforth wrote: post #11

Did you know it takes almost a hundred ms for a signal to go from your fingers to your brain? Did you know that the brain is constantly predicting the future to make up for its slow reaction time? Did you know even small computers are really really fast? If you did then you'd probably guess that initiatives like this are a waste of time and money. The difficulty is in the software, not the hardware, or the compute la…

I agree that one of the major aspects to improve in robotics is software. There's still a lot do there and many are working towards it. Most leading initiatives around ROS 2. I also believe that we need faster robotics simulation, and hardware acceleration will be valuable there, not only with GPUs, but also other accelerators (e.g. FPGAs outperform GPUs in many benchmarks both performance and energy consumption-wise…

Yeah, started my own robotics company, early engineer at another that sold for >$200M. You seem to have misinterpreted my statement of "hardware is already good enough" to mean "hardware is unimportant."
Post reply on HN