If you were in robotics prior to 2010, you probably would have used something called Player/Stage (by some of the same people who developed ROS). Believe it or not, another big motivation for ROS was solving the (many) problems that popped up as people tried to get Player/Stage running with robots like the Pioneer 3-DX.

* robotic software projects are often abandoned, and only ROS keeps the driver packages working

* Yes it is terrible, but the alternatives are even worse

Almost all modern reasonably good platforms will already offer a tested ROS configuration. Even the UR5 had simulation and control options out of the box.

People can't avoid standards.. even the awful ones.. =3

I've seen people get sucked into ROS + simulation who end up never touching real robots. Which is fine if that's what you want to play with, but it's debatable if "ROS + sim" alone is even "robotics."

Also not a fan of simulators for simple platforms, as a lot of stuff breaks when the environment is chaotic. =3

The next person gets up and gives a talk about all the advancements in generating point clouds from optical cameras.

By far the best part is how tied to specific versions of Ubuntu each ROS release is, just getting all the packages installed and running requires sacrificing a cat while chanting Hail Mary backwards in Latin.

100% this. I had a very, very miserable time setting up two systems and trying to get them running a version that was supported. The worst part is SBCs that stop getting OS updates and become permanently locked in to a specific version. Which also forces the rest of your hardware to use the same version. Using a Jetson Nano with Ubuntu 18.04 in 2022 was lots of fun...

Last year I met a couple of university students working on a robot and out of curiosity I asked what they were using as a microcontroller and the software stack. They were running ROS. When they said they still hadn't upgraded to ROS 2 yet, I could feel their pain...

Reinventing the build chain every other year is miserable too.

Monocular feature extraction has been around for decades, but is only reliable for people that never go outside in the sun/dust/rain. =3

Also, the talk about visual camera point could generation was very impressive.

Lidar also suffers from the environment, and angles, and reflection, and light sources.

There are some fairly good FOSS tools around like COLMAP, if you want to learn why automatic monocular pose recovery and SfM is hard.

Real autonomous robotics is hard, and people make the same predictable mistakes every 4 years. Retrofitting a consumer Yarbo would be cool though. =3

I'm quite familiar with robotics and lidar, and ground planes, and ROS. Not sure what 4-year cycle you're talking about.

I observe many groups solving platform design issues also eventually move on to other projects or careers. The dozens of documented fools-errands from Academic literature and Commercial sectors are eventually lost again each time. There are various institutional structural reasons this occurs, but the outcome is usually the same.

One must accept many problems are not purely technical in nature, and unfortunately complex Mechatronics often tend to exhibit sustainability problems.

>I'm not sure how you ended up here.

Don't worry about it... =3

Starting, but not limited to a "T".(ROS: Robotics community; RTOS: Embedded community)

Involving anything managed by a GPOS (e.g. Linux) in robotics is something I would use with extreme caution, and for limited cases like a CV module.

It was like pulling teeth trying to explain to someone that they couldn’t use the Linux GPIO subsystem from python to accurately measure sub-millisecond events…

Linux is a general purpose OS, it’s typically tuned for throughput not precise timing. Sure there’s PREMPT_RT but it only buys you so much.