Live data from Hacker News

Show HN: Basis – a production focused robotics framework

github.com

11–20 of 38 posts

Re: Show HN: Basis – a production focused robotics framework

#11
post #8

It’s interesting to me that every robotics framework essentially boils down to a specialised pub-sub system with some flavour of serialisation and some kind of startup/launcher to wrangle running separate processes. Props to this team for picking Protobuf given its wider adoption unlike ROS and its custom format. Is there a reason an existing pub-sub system like NATS isn’t suitable for a framework like this? Also unf…

I always wonder about this too. Half the ROS projects I've seen are just single-board applications with topics. ROS bags are a useful facility for data capture and testing, and there are some ROS packages that are useful (against the backdrop of an awful packaging/build system). But even all that is just because the community decided this particular pub-sub system was the robotics one and started building packages on…

One story not mentioned here is the real history.

ROS was developed as the framework for the PR1 robot, as a "Linux for robotics" idea. But it really took off when Willow Garage GAVE out a bunch of PR2 robots to academic institutes around the world.

It then stuck because those labs, even independently, developed really useful tools in a very backwards compatible language (C++) or with support to old languages (Lisp). You can find many repos such as this one which basically have EVERYTHING, handed down from PhD to PhD student over decades

https://github.com/jsk-ros-pkg

Basically a lot of the headache inducing grudge work exist there as a library, you only need to glue it together.

You want to calibrate your camera, get the relative position to the root of a robot arm? You can knack it together with openCV and then end up debugging for hours because coordinate transform convention was wrong. Or just install this library, publish your sensor data in specified topic, and it does it for you.

Imo it's easy to miss the usefulness of ROS if you don't consider the tf package, rosbag and rviz together with ROS as a bundle.

Everytime I see a pub/sub "new ROS" framework, sooner or later I realize I need to reinvent tf/rosbag/rviz, because those standard packages are almost never available (or available only for the developers specific need)

Re: Show HN: Basis – a production focused robotics framework

#12
post #10
post #8

Earlier quoted context omitted.

I always wonder about this too. Half the ROS projects I've seen are just single-board applications with topics. ROS bags are a useful facility for data capture and testing, and there are some ROS packages that are useful (against the backdrop of an awful packaging/build system). But even all that is just because the community decided this particular pub-sub system was the robotics one and started building packages on…

IMO, the real value of ROS is the data logging (bag/mcap files), visualization (FoxGlove) are the main value of ROS. Even then, I'm not sure it's worth the overhead and brittleness of building and running it. There is just so much complexity deploying and developing for it.

Yep. ROS is great if you are an academic or a garage startup who needs to get anything at all up and running ASAP because it is extremely flexible and has a huge volume of community modules.

But, when it comes time to deploy serious business (very often Safety Critical) robots in the field, you don’t want flexibility. You want certainty. You don’t even want everyone’s contributions. You want specialized, carefully vetted code.

Thus the effort to make it easy to transition off of ROS to something simpler and more reliable.

Re: Show HN: Basis – a production focused robotics framework

#13

Can you point to specific examples or discussions supporting the claim that ROS (focusing on ROS 2 given noetic is almost EOL) suffers from performance and testing problems?

Testing: this is mostly my experience, but ROS doesn't have any form of built in integration testing. I should be able to take a launch file and a bag, run it, and validate the outputs easily. And that's not even getting into test determinism - it's killer for larger robots, and IMO nearly required for doing integration testing/full sensor simulation.

Perf: Again, mostly my experience, with ROS1, in self driving. Two issues:

1. High rate topics were previously a bit dicey - I remember someone hooking up an IMU driver directly to the topic graph with no batching (600 Hz) and causing some perf degradation. 2. There's no builtin controls for core pinning, etc, which hurts on high core systems. In fairness, we haven't implemented these either, but it's coming.

There's some ROS2 examples here: https://discourse.ros.org/t/ros2-speed/20162/2 but the topic is a little old, and it honestly looks a little dependent on the DDS backend. They are swapping to Zenoh anyhow (mostly for config complexity reasons, I believe), I'm not sure what the perf will be, there.

Getting real perf benchmarks is top of mind for me, understand if my explanation is not so convincing.

Re: Show HN: Basis – a production focused robotics framework

#15
post #8

Earlier quoted context omitted.

I always wonder about this too. Half the ROS projects I've seen are just single-board applications with topics. ROS bags are a useful facility for data capture and testing, and there are some ROS packages that are useful (against the backdrop of an awful packaging/build system). But even all that is just because the community decided this particular pub-sub system was the robotics one and started building packages on…

One story not mentioned here is the real history. ROS was developed as the framework for the PR1 robot, as a "Linux for robotics" idea. But it really took off when Willow Garage GAVE out a bunch of PR2 robots to academic institutes around the world. It then stuck because those labs, even independently, developed really useful tools in a very backwards compatible language (C++) or with support to old languages (Lisp).…

We support mcap (the data container format that ROS2 uses) and Foxglove for viz. Shoutout to Foxglove, it's a much nicer experience than rviz. Something like tf is on the todo list - I recognize it's important.

Re: Show HN: Basis – a production focused robotics framework

#16
post #10

Earlier quoted context omitted.

IMO, the real value of ROS is the data logging (bag/mcap files), visualization (FoxGlove) are the main value of ROS. Even then, I'm not sure it's worth the overhead and brittleness of building and running it. There is just so much complexity deploying and developing for it.

Yep. ROS is great if you are an academic or a garage startup who needs to get anything at all up and running ASAP because it is extremely flexible and has a huge volume of community modules. But, when it comes time to deploy serious business (very often Safety Critical) robots in the field, you don’t want flexibility. You want certainty. You don’t even want everyone’s contributions. You want specialized, carefully ve…

This, so much.

Re: Show HN: Basis – a production focused robotics framework

#18

Cool project. Thanks for sharing! I’ve worked with ROS in commercial fleets of tens to hundreds of robots for, gosh I guess over a decade now. The main issue from my POV as a web person is how poor a fit ROS comms are across unreliable networks (basically anything outside localhost). ROS2 tries to do better with choose your own DDS but there’s still pains with wanting some of the basics found in other realms: compres…

Compression, encryption, auth: not immediately. What's the use case here? Multi-machine robots are _tricky_ to get right. Running remote controls and telemetry via the framework would be really cool, but is also tricky to tune (need really good qos controls), and needs some work to be exposed safely to the outside world.

Proper schemas/API versioning: I'm not sure what you mean by "proper schemas", but schema/API versioning is also an area I'd like to get right. I've been bit before by tests using old ros bags, before some message type was changed or topic name was moved.

Re: Show HN: Basis – a production focused robotics framework

#19
post #15

Earlier quoted context omitted.

One story not mentioned here is the real history. ROS was developed as the framework for the PR1 robot, as a "Linux for robotics" idea. But it really took off when Willow Garage GAVE out a bunch of PR2 robots to academic institutes around the world. It then stuck because those labs, even independently, developed really useful tools in a very backwards compatible language (C++) or with support to old languages (Lisp).…

We support mcap (the data container format that ROS2 uses) and Foxglove for viz. Shoutout to Foxglove, it's a much nicer experience than rviz. Something like tf is on the todo list - I recognize it's important.

That's cool to hear! I'll follow the project and fingers crossed it works out. Since I still kind of rely on legacy packages I probably won't/can't move to it in the nearest future but it would definitely be great when "prototyping" and production could be merged to one (without headache)

Re: Show HN: Basis – a production focused robotics framework

#20
post #18

Cool project. Thanks for sharing! I’ve worked with ROS in commercial fleets of tens to hundreds of robots for, gosh I guess over a decade now. The main issue from my POV as a web person is how poor a fit ROS comms are across unreliable networks (basically anything outside localhost). ROS2 tries to do better with choose your own DDS but there’s still pains with wanting some of the basics found in other realms: compres…

Compression, encryption, auth: not immediately. What's the use case here? Multi-machine robots are _tricky_ to get right. Running remote controls and telemetry via the framework would be really cool, but is also tricky to tune (need really good qos controls), and needs some work to be exposed safely to the outside world. Proper schemas/API versioning: I'm not sure what you mean by "proper schemas", but schema/API ver…

Use case: Imagine a location with hundreds of autonomous mobile robots that want to share state and plans with each other to behave more optimally than if they only saw each other through their sensors. They also want to share state and telemetry with monitoring systems so that humans can maintain a fleet's healthiness and address issues proactively.

After years of working with tens of thousands of deployed robots, one of the most painful things with ROS, from my perspective, is that the message definitions are very limiting. Cannot have `null` types. In research and shorter term contexts, it doesn't really jump out as an issue, but the story for how to upgrade and deploy to large fleets without downtime or hidden compatibility pains (MD5sum anyone?) is paramount when I think about "production" ready robotics.

Post reply on HN