Show HN: Basis – a production focused robotics framework

Hey HN! Myself and my cofounder are excited to actually launch the product we've been working for the past six months. It's a robotics framework with a focus on testing and production. The current industry standard (ROS) is great for prototyping, but suffers from performance and testing problems as the robot gets more complex. I would have loved to work on this another six months or a year to polish it up and really, but I know it's better to launch a bit before you think you're ready.

It's a C++ pub-sub framework (a lot like ROS, in that way), but rather than declaring C++ publishers/subscribers directly, you declare the topics and types your code cares about in a configuration file, along with conditions on those inputs. Doing this allows for deep knowledge about the code running, which unlocks the possibility of deterministic simulation and testing (along with making it easy to generate bindings for other languages, create alternate schedulers, more easily swap out internal concepts, etc). It also enables easy static analysis of the codebase - given a launch file and arguments to the launch file, one can analyze the topic network and find missing publishers or publishers that publish to nothing.

Show HN: Basis – a production focused robotics framework
github.com

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?

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: compression, encryption, authentication/authorization, proper schemas and API definition/versioning.

Does Basis intend to target any of this?

The problem with multitasking OS, drivers, and networked links are well documented:

https://en.wikipedia.org/wiki/Clock_domain_crossing

The trick is usually to stratify the navigation, path-planner, guidance, manual-overrides, and safe-machine-state system definitions into different problem domains.

YMMV =3

I suspect it just happened to be at the right place at the right time, worked well for a set of users in the robotics community and built up strong network effects there.

This is a pretty common story. Python became very successful in a similar way. I have seen things like flight critical software written in Python not because Python is a good language for it (if I heard this 15 years ago I would laugh), but because Python became a de-facto standard for prototyping in the domain due to its libraries, tools and bindings and solving a realtime challenge for an existing prototype is often an easier lift than rebuilding it from scratch. My 2c.