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

Five Learnings from 15 Years in Perception

tangramvision.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Five Learnings from 15 Years in Perception

#11

Post by accurrent »

carlmr wrote: post #7
snovv_crash wrote: post #6

It's a fine balance between Not Invented Here syndrome vs. trying to hammer the square peg of off-the-shelf OSS into the round hole of the actual problem you're trying to solve. For example they suggest ROS as a robust industry-ready software, which absolutely hasn't been my experience: you hire a bunch of domain experts to solve the various [hardware, controls, perception, imaging, systems] problems, but once you us…

>This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything. You end up needing more fine-grained control than ROS gives you to make an actually robust system, but by the time you discover this you'll be so invested into ROS that switching away will involve a full rewrite. So true. The worst is that at many companies they will w…

Tbf ROS is a pretty old project. ROS1 dates back to 2009 iirc. A lot of technologies didnt exist back then. Even ROS 2 is now relatively old. The way I see it is that we have since learned a lot about software engineering. I dont think using cmake with catkin and relying on debian packages makes much sense now a days. But back in 2009 I can see why we would have to do it. Heck using catkin to share c++ code by copying the code into a local workspace was so much easier than having to figure out which set of systemwide packages and which cmake incantations would work correctly. Today, however we know how to do packagemanagement much better via tools like cargo. However some core ideas like pub/sub,micro services, message definitions, message recording and playback will be part of your stack.

With regards to startups in general though. Having worked at a few Ive noticed that at the earliest stages the goal is for a few individuals to build quickly. Often this means certain framework choices that may not be suitable to scaling. As one scales one has to then evolve the architecture to ensure developer velocoty. This may mean rewriting everything. Im not surprised that people are rewriting ROS internally. At the end of the day there are a few good ideas in there, but at some point one has to acknowledge that implementations were lacking.

Personally if one were to write a middleware framework in 2024 Id go with rust, mcap, zenoh, rerun and possibly use ecs instead of topics.

Re: Five Learnings from 15 Years in Perception

#12

Post by palata »

lynx23 wrote: post #10
palata wrote: post #9

Earlier quoted context omitted.

A valid ethical question is: will this technology do more good than bad? Or put differently: given the bad implications this technology will likely have, is it worth it? Example: "I have made this technology that makes me (and only me) earn 1 cent per day when managed right. Bad actors can use it to hack into hospitals and ransom them". Wouldn't you agree that this hypothetical technology is probably not worth it? In…

The problem are incentives. There are monetary incentives to create whatever technology you can, because you can, and thats the way you earn money. There is zero incentive to consider how your technology might be abused.

> There is zero incentive to consider how your technology might be abused.

Ethics is that incentive.

Would you be fine getting a good salary for legally building bombs that are sold legally, knowing that they are purposely killing many innocent children? If the answer is "no", then it means that there is an incentive. You "just" need to find your line.

And I strongly believe that sometimes, the only way is to agree together on a line (through regulations), because individually we may not be strong enough. For instance I think that sending people to the ISS/Moon/Mars is an artistic performance that the world does not need. On the contrary, we invest a ton of public money into doing that, which then unlocks private companies (like SpaceX) to commoditize space, which in turn is bad for the environment. So I would vote against spending public money on this. But now if you offered me to become an astronaut in a space program, I would most definitely go. I find it interesting: I would vote against it, but given the opportunity I would do it :-).

Re: Five Learnings from 15 Years in Perception

#14

Post by jasode »

dghf wrote: post #13

Linguistic tangent: when did "learnings" oust "lessons" as the standard word for "things I have learned"?

Trends in the corpus of books don't always match trends in the corpus of web blogs but the graph of "learnings" popularity seems to match my perception of its increasing usage: https://books.google.com/ngrams/graph?content=learnings&year...

Another phrase I see spreading rapidly is "double-click that" replacing "drill into that". Seems like every podcast instantly adopted "double-click" lingo in the last 2 years.

Re: Five Learnings from 15 Years in Perception

#15

Post by ethbr1 »

accurrent wrote: post #11
carlmr wrote: post #7

Earlier quoted context omitted.

>This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything. You end up needing more fine-grained control than ROS gives you to make an actually robust system, but by the time you discover this you'll be so invested into ROS that switching away will involve a full rewrite. So true. The worst is that at many companies they will w…

Tbf ROS is a pretty old project. ROS1 dates back to 2009 iirc. A lot of technologies didnt exist back then. Even ROS 2 is now relatively old. The way I see it is that we have since learned a lot about software engineering. I dont think using cmake with catkin and relying on debian packages makes much sense now a days. But back in 2009 I can see why we would have to do it. Heck using catkin to share c++ code by copyin…

Even when ROS started, we already knew a lot of better ways to build software.

The problem is the primary ROS contributor was/is a hybrid robotics engineer + software developer, which meant their colleagues were more likely of "closed, vendor firmware toolchains are normal" et al. norms, which meant their community hadn't internalized a lot of those solutions.

And this isn't to bash different types of devs -- god knows even leading edge software practices have all kinds of gaps -- but is to say that few people can be 100% in multiple hard things, all at once.

Re: Five Learnings from 15 Years in Perception

#16

Post by ethbr1 »

jasode wrote: post #14
dghf wrote: post #13

Linguistic tangent: when did "learnings" oust "lessons" as the standard word for "things I have learned"?

Trends in the corpus of books don't always match trends in the corpus of web blogs but the graph of "learnings" popularity seems to match my perception of its increasing usage: https://books.google.com/ngrams/graph?content=learnings&year... Another phrase I see spreading rapidly is "double-click that" replacing "drill into that" . Seems like every podcast instantly adopted "double-click" lingo in the last 2 years.

Buzzwords are pretty viral via consultants, and so eventually leach into the corporate / common speech.

Because if you're not using the newest lingo, you might not be using the newest approaches, and might be falling behind! (gasp!)

Re: Five Learnings from 15 Years in Perception

#17

Post by f1shy »

snovv_crash wrote: post #6

It's a fine balance between Not Invented Here syndrome vs. trying to hammer the square peg of off-the-shelf OSS into the round hole of the actual problem you're trying to solve. For example they suggest ROS as a robust industry-ready software, which absolutely hasn't been my experience: you hire a bunch of domain experts to solve the various [hardware, controls, perception, imaging, systems] problems, but once you us…

> they suggest ROS as a robust industry-ready software, which absolutely hasn't been my experience

Also BY FAR not my experience.

Personally I see ROS as a cool thing for prototyping and research, but I see it certainly not as a serious solution for industry.

> This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything.

This is an excellent short description of the main pain topics. I would add, that the need to work with 5 different languages (YAML, XML, MSG, CMAKE and C and/or Python) from scratch, makes it difficult for SME that are not software people to be productive in short time.

Re: Five Learnings from 15 Years in Perception

#18

Post by f1shy »

carlmr wrote: post #7
snovv_crash wrote: post #6

It's a fine balance between Not Invented Here syndrome vs. trying to hammer the square peg of off-the-shelf OSS into the round hole of the actual problem you're trying to solve. For example they suggest ROS as a robust industry-ready software, which absolutely hasn't been my experience: you hire a bunch of domain experts to solve the various [hardware, controls, perception, imaging, systems] problems, but once you us…

>This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything. You end up needing more fine-grained control than ROS gives you to make an actually robust system, but by the time you discover this you'll be so invested into ROS that switching away will involve a full rewrite. So true. The worst is that at many companies they will w…

At the end what ROS provides for that cost, is a IPC, Logging, configuration and a startup tree (through launch system). Waaaay too expensive.

- We have moved to standard sockets IPC, or protocol buffers. - For logging just trivial printing. - For configuration to libconfig - For launch system to simple shell scripts.

Re: Five Learnings from 15 Years in Perception

#19

Post by ripe »

DaiPlusPlus wrote: post #3

This article struck a personal note with me because around the same time (2008-2012) I was really getting into vision, and even got published as an undergrad for imaging sensor fusion work (...my first, only, and likely last only meaningful contribution to my species); while the wider MV/CV community was making incremental gains every few years (anyone else remember Histogram-of-Oriented-Gradients?), that's what they…

You are right: Computer Vision was always one of the original fields of AI research. The International Journal of Computer Vision was established in 1987 and it remains a premier outlet.

Today the word "AI" has itself been hijacked by marketers of ANN-based techniques, so when the article uses that term, it confuses people who don't know any better.

Re: Five Learnings from 15 Years in Perception

#20

Post by carlmr »

f1shy wrote: post #18
carlmr wrote: post #7

Earlier quoted context omitted.

>This is due to the horrible build system, odd choice of defaults, instability under constrained resources, and how it inserts itself into everything. You end up needing more fine-grained control than ROS gives you to make an actually robust system, but by the time you discover this you'll be so invested into ROS that switching away will involve a full rewrite. So true. The worst is that at many companies they will w…

At the end what ROS provides for that cost, is a IPC, Logging, configuration and a startup tree (through launch system). Waaaay too expensive. - We have moved to standard sockets IPC, or protocol buffers. - For logging just trivial printing. - For configuration to libconfig - For launch system to simple shell scripts.

The beauty with using protobuf, libconfig or whatever is that they're libraries. If you find a better RPC/messaging library for your needs it's easy to replace one library, if you find a better config management you replace one library, if you want better logging you replace one library.

I despise the framework approach, it ossifies bad decisions and then it becomes a monumental task to move away from the framework, because now you need to replace everything.

Post reply on HN