[HN Gopher] $100 robot kit running ROS2 and Navigation2
___________________________________________________________________
$100 robot kit running ROS2 and Navigation2
Author : jackp510
Score : 83 points
Date : 2020-12-11 18:56 UTC (4 hours ago)
(HTM) web link (blog.hadabot.com)
(TXT) w3m dump (blog.hadabot.com)
| blt wrote:
| Re: the "what is ROS?" question asked by many on this thread:
|
| Like others have said, ROS includes a serialization protocol with
| codegen, a pub/sub and RPC messaging system with discovery, a
| build system, a configuration file system, logging system, and a
| repository of packages using them.
|
| You might ask: why is it popular? One reason: it was started
| before the current ubiquitous solutions for those things were
| ubiquitous.
|
| But I think the main reason is: in robotics, we use a lot of
| semantically complex data like high-dimensional sensor readings,
| probabilistic models of the world, representations of rotation
| and angular velocities, etc., and we need to do a lot of things
| with that data. For example, suppose we use a vision system to
| identify objects from a camera. We don't just display that
| information to a user -- it becomes the input to the high level
| planner, which is its own complex system.
|
| If your object recognition library and your planning library are
| both pure C++ libraries, then they probably each define their own
| classes for the datatype "list of (bounding box, object name)
| pairs". You need to write glue code to use the libraries
| together.
|
| However, if those libraries are both ROS packages, the idiomatic
| thing is to publish a package containing only message definitions
| (like vision_msgs [1]) and have both libraries produce / consume
| that. This makes it easier to put together complex systems that
| pass around highly structured data, because you don't have to
| constantly write glue code to get your libraries to work
| together.
|
| TL;DR: ROS is popular because it's like a big collection of
| .proto or .thrift files for complex robotics datatypes that
| everyone agrees to use in their libraries.
|
| [1] https://index.ros.org/p/vision_msgs
| lxe wrote:
| I'm trying to figure out what ROS2 is -- judging by the docs and
| tutorials it seems like a very low level and abstract piece of
| complex software but I'm struggling to understand its
| practicality.
|
| Can someone provide an ELI5 or like a few sentences of a "pitch"
| style overview?
| richmattes wrote:
| ROS isn't really one thing. Per the "about"[1] it's really made
| up of several pieces:
|
| Plumbing:
|
| ROS is centered around a publish/subscribe messaging framework,
| with a central broker that ROS processes (called nodes)
| register with to advertise their publications and request
| subscriptions. Message definitions that are passed on the
| pub/sub "topics" are specified in language agnostic Interface
| Definition Language (IDL) files. There's an RPC service layer
| built on top of the messaging infrastructure, and the central
| broker also hosts a 'parameter server' database that nodes can
| use to query or update named values. ROS client libraries that
| provide APIs for topics/services/parameters are provided for
| several languages, primarily C++ and Python. A set of commonly
| used message definitions and conventions, which form de-facto
| standard interfaces, are used to establish interoperability and
| substitutability between ROS nodes.
|
| Tools:
|
| ROS provides build tools for individual software packages based
| on CMake and custom metadata embedded in an xml file. Packages
| can be grouped into workspaces, built with ROS tools, and
| workspaces can be layered on top of one another. Other ROS
| tools exist for process management (the launch system),
| introspection of running ROS processes, interaction with
| topics/services, and visualization of message data published
| with well-known message types. This list is by no means
| comprehensive
|
| Capabilities:
|
| Building on the concepts of publication/subscription with
| shared interface descriptions, and the package abstraction,
| various packages are publicly available that use ROS interfaces
| to accomplish various functions. These could include reading
| data from a sensor and converting the data to a ROS message,
| implementing robotic navigation algorithms, providing a
| visualization or UI, or controlling the behavior of a
| simulation. It's possible to build on and modify a lot of
| existing capabilities to build a system, which arguably speeds
| up the
|
| Ecosystem:
|
| ROS is widely used across industry and academia, and there's
| lots of people familiar with its workings. These people work
| together to advance the state of the art of the ROS framework
| and the capabilities implemented with it, the
| standards/conventions for interoperating with various
| components, and
|
| ROS 2 is an evolution of ROS. It keeps a lot of the same
| concepts, but replaces the bespoke pub/sub messaging protocol
| with an abstraction to plug in lower-level messaging libraries
| (DDS is used by default). The reasons and motivations for
| starting over with ROS 2 are outlined here[2], but may require
| some familiarity with ROS 1 to get all of the nuance.
|
| [1] https://www.ros.org/about-ros/ [2]
| https://design.ros2.org/articles/why_ros2.html
| stefan_ wrote:
| ROS itself is basically a glorified message bus, and the
| ecosystem around it allows you to quickly cobble together a
| robot from disparate parts (use one thing to publish frames
| from your specific camera model, feed it into some other module
| that does SLAM).
|
| Very popular in research, so in practice little of it really
| works together, much is abandoned and most stuff barely
| compiles. Lately there have been "smart" people thinking they
| can just install ROS and presto robot AI startup. These people
| are in for a harsh lesson.
| a_t48 wrote:
| > Lately there have been "smart" people thinking they can
| just install ROS and presto robot AI startup. These people
| are in for a harsh lesson.
|
| Oh, but they can. The "presto AI" part is easy. Making a
| working product after ROS collapses under its own weight is
| the tough bit.
| ethbr0 wrote:
| ROS is a helper framework, for people who would otherwise be
| implementing low-level embedded interfaces to arbitrary
| hardware, so that they can share more of their work.
|
| It's like Rails, if instead of targeting the web your
| deployment platform were an unmanned autonomous submarine
| vehicle.
|
| And you needed to support a donated Russian sonar, some second-
| hand one-off logic boards, some sensors you soldered together
| in your lab, and implement a navigation algorithm you only have
| in research paper form.
| ska wrote:
| Basically ROS is a collection of libraries, mostly for and by
| researchers for interfacing with and controlling robots.
|
| Libraries exist at different levels of abstraction, but it is
| for the most part not exactly plug-and-play.
|
| It's super useful if you are for example building robots in an
| academic lab, say, or re purposing existing hardware &
| software. The further you get from that environment, the less
| obvious the fit will be. But if you are playing around with
| robotics, ROS can help you avoid reinventing a whole bunch of
| wheels just to get started.
| jackp510 wrote:
| The short elevator pitch in my "unofficial" over-simplified own
| words - "ROS is framework to program complex robotics
| applications that encourages modularity and shareability of
| modules. ROS is to robotics development what Django/Rails is to
| web development."
|
| ROS2 is version 2 of the original ROS framework.
|
| As a results of the ROS framework, a number of modules
| (packages in ROS-talk) for complex robotics algorithms,
| functionality has been implemented by companies / the community
| and shared among each other.
|
| For instance, Hadabot reuses the Navigation package (along with
| many others) that has been pre-impremented which allows me to
| employ many robotics functionalities without having to re-
| invent the wheel.
| ducktective wrote:
| I'm really struggling in learning ROS in a _systematic_ way. The
| tutorials are all over the place and somehow unorganized IMO.
| When trying to replicate stuff on my machine, all kinds of weird
| errors pop up.
|
| Honestly, I don't even __get __what ROS is about? Like it seems
| it is an "amalgamation" of tools and scripts to create a general
| API with some ideas of robotics application in mind. Also the
| naming of its stack seems weird to me: tf2, MoveIt!, the over-
| loading of terms like joint controller, robot controller, etc...
|
| If anyone can point me to a free, coherent and hands-on study
| plan or guide with exercises that actually build and run fine
| that would be awesome.
| qchris wrote:
| I have this exact same problem. I'm not exactly sure why, but
| finding _useful_ examples has been a serious pain point for me.
| It seems like there 's a serious dearth of material between the
| "here's the absolute smallest thing you can do" and "now we're
| going to built the F-35, but with ROS!". Like, I want to
| subscribe to and manipulate the value in a topic. Fine. But how
| about _two_ topics in the same program? All of a sudden my code
| won 't compile and the tutorials aren't helpful.
|
| Especially with the release of ROS2 (which, frustratingly,
| seems to be rarely stand-alone, in that the learning process
| often references or links to ROS(1) code through things like
| rosbridge), it's just been a frustrating experience. If someone
| were to release a paid textbook walk-through that actually
| explains it in a systematic, stand-alone, way with linked
| repositories, I'd buy it tomorrow.
|
| Which, I suppose, is sort of exactly where this kit is aimed!
| jackp510 wrote:
| This is exactly what I'm trying to address with Hadabot. A
| systematic / opinionated way to learn ROS (specifically ROS 2),
| understand its significance, in a hands-on manner, with a real
| robot. The next milestone for Hadabot is a very simple
| introductory ROS robotics curriculum / syllabus that is not as
| intimidating as a MOOC, requires low mental load to get started
| and reach various milestones. Lots of hard work ahead to get
| this right! Don't hesitate to reach out w thoughts and opinions
| - jack AT hadabot DOT com - Jack
| ethbr0 wrote:
| I can't offer any modern links, but some background and framing
| that might help a bit.
|
| Disclaimer: Everything to follow circa-2010. Modern ROS* may be
| substantially different.
|
| First, and most importantly, "Why ROS?" To which one might
| reply "To run robots," but that's not _really_ why.
|
| Historically, ROS' purpose is so that researchers can avoid
| rewriting boilerplate linking / low-level code, and reuse high-
| level components developed elsewhere.
|
| To that end, ROS provides two main functional components: a
| standardized message bus, and a somewhat-structured framework
| into which one can plug arbitrary modules. So yes, closer to an
| API/spec than an OS.
|
| So the easiest way to think about ROS (the base framework) is
| as a no-batteries-, no-motor-, no-X-included kit. Bring your
| own everything. And for values of everything, where there is
| likely some component out there that does X... but that
| component isn't ROS.
|
| So you (as it sounds like) essentially end up with the
| JavaScript ecosystem problem, except moreso. Do I use X or Y
| for this purpose? Does X integrate cleanly with A? Does Y?
|
| When you look at ROS as something useful to a PhD student
| pursuing their robotics dissertation on SLAM, but who doesn't
| want to write all the other bits, it makes a bit more sense.
| mikepurvis wrote:
| I've been doing ROS professionally for ten years and have
| presented twice at ROSCon. I would argue that part of the
| difficulty with this is that ROS is many different things to
| different people. I'm a low level platform/OS/firmware guy, so
| I tend to care most about the build system, dependency
| management, the relationship with the host OS, the standardized
| sensor messages, and the approach to logging (rosbag).
|
| People in the perception space may care more about all the
| standard camera drivers, the publicly available SLAM datasets,
| and the zero copy nodelet system for passing image date through
| a pipeline.
|
| People in controls care about the simulator integration, and
| the flexibility of move_base and its successors through a rich
| plugin system.
|
| Then there are people doing stuff with manipulators, people
| doing realtime industrial stuff, people doing quadcopters,
| people doing academic research, people trying to build a
| product, people doing web frontends.
|
| It's a lot of use-cases, so it's hard to recommend any one
| "getting started" path because it depends a lot what your
| interests are and your expected end goal. But generally
| speaking a safe option is to get a robot like Turtlebot up in
| the simulator, get it map-making and navigating autonomously,
| and then start mutating that-- add more sensors to it, or write
| your own planner, or make an rviz plugin that does something
| interesting, etc. Maybe swap out gmapping for cartographer, or
| set it up to explore on its own.
|
| These kinds of tasks will familiarize you with a lot of the
| tools that _almost every_ ROS person uses, so that you 'll have
| more of a sense of what the potential next steps are.
| DoctorDabadedoo wrote:
| > Honestly, I don't even get what ROS is about?
|
| You can think ROS as a framework aimed at developing robotic
| applications (similar to what a REST framework would be for
| developing a web API). With it you get access to a lot of open
| source packages and tools out of the box (simulation via
| Gazebo, native process communication using pub/subs, autonomous
| navigation, joint transformation, etc.). There is a lot of
| dependence handling to make a robot work (component drivers,
| real time comm, planners, SLAM, the list goes on), if you are
| able to abstract something of the pipeline, it's worth it.
|
| The whole thing might not seem very concise, but looking back,
| it was released aiming to facilitate research development, all
| these packages are maintained indepently. ROS2 is an attempt to
| tackle some architecture and scope issues brought up by the
| industry.
___________________________________________________________________
(page generated 2020-12-11 23:00 UTC)