3 ms·

ROS (1/2) is just damn handy. There's a plethora of libraries available: navigation, localization, perception, motion planning, visualisation, record and replay

ROS (1/2) is just damn handy. There's a plethora of libraries available: navigation, localization, perception, motion planning, visualisation, record and replay events for debugging, high-level behavior definition with state machines and behavior trees, motion control, sensors, orchestration anything you need in a robotics system. I've seen various half-assed versions or something akin to ROS (IPC to have process isolation and distributed, with some processes running on a RTOS) seen built over the years. All of which sucked in different ways. Especially a tool like RViz is always missing. And in many many robotics video I see (of a moderately complex robot), there's ROS's RViz on some screen.

amacneil 3y ago
> Especially a tool like RViz is always missing. And in many many robotics video I see (of a moderately complex robot), there's ROS's RViz on some screen. I would love the future robotics development stack to be more modular, so that (for example) future middleware solutions don't need to also bundle their own visualization software. This was direct inspiration for creating Foxglove Studio[0] for visualization and MCAP[1] for logging - both work great with ROS, or equally well without it. [0] https://github.com/foxglove/studio https://github.com/foxglove/studio [1] https://github.com/foxglove/mcap https://github.com/foxglove/mcap
- elephantum 3y ago
  Foxglove is my best argument to use ROS instead of custom solution in semi-robotics cases (several cameras/sensors + ML, but no actuators)
  - ragebol 3y ago
    Yep. I've worked in a startup making a Laser Direct Imaging PCB photomasking machine, basically using lasers to do photo masks etc a couple year ago. When I came in, there was a custom IPC thing made, sending essentially Python dicts over ZeroMQ (IIRC). It worked to get the machine running and doing it's thing. For calibration of the cameras (needed to see how warped the PCB was and adjust the pattern) I needed to keep track of transforms etc. A perfect use-case for something like ROS's TF, in some incarnation. The machine was not a 'robot' per se, but there was many sensors, decision making, actuation, so kinda like a robot. For debugging the images and calibration transforms, we needed to write custom stuff. The whole thing was akin to ROS, with a couple days it could have been made to work with it. But alas
rektide 3y ago
It is wild to me that there's this whole huge message-bus/rpc system Data Distribution Service (DDS) that so much of thr computing industry else has never heard of, but which is totally core to ROS. https://en.wikipedia.org/wiki/Data_Distribution_Service https://en.wikipedia.org/wiki/Data_Distribution_Service It does have some real further mindshare. I noticed GM/Eclipse Foundation's new uProtocol has support for it. https://hn.algolia.com/?query=Uprotocol&sort=byDate&type=story https://hn.algolia.com/?query=Uprotocol&sort=byDate&type=sto...
- anonymousDan 3y ago
  Interesting. Does it define a wire protocol or is the interface implicit to the client library.
  - elcritch 3y ago
    Both, sorta. There’s a serialization format, and the wire message format with QoS on top of UDP. The message format seems similar to MQTT semantics, but with a few extras. I think the wire format is fixed, but it’s pretty simple. The serialization layer (CDR) is swappable, but mostly all the same, though one of the most popular implementations uses a slightly non-standard FastCDR. Though from my testing it produces the same bytes and the CDR spec was updated. Maybe they match now. I wish there was a better implementers guide. DDS might be a decent alternative to MQTT for more generic embedded if so.
    - rektide 3y ago
      The wireshark wiki has a surprisingly good write up on the underlying RTPS protocol: > The Real-Time Publish-Subscribe (RTPS) Wire Protocol provides two main communication models: the publish-subscribe protocol, which transfers data from publishers to subscribers; and the Composite State Transfer (CST) protocol, which transfers state. https://wiki.wireshark.org/Protocols/rtps https://wiki.wireshark.org/Protocols/rtps ROS docs talk quite a lot a out various vendor implementations of RTPS middleware. But little docs on the protocol. Did a little search but haven't found many truly great in depth resources. OpenDDS seems to be the main impl I've stumbled across. Descend docs. https://opendds.readthedocs.io/en/latest-release/devguide/introduction.html#data-centric-publish-subscribe-dcps-overview https://opendds.readthedocs.io/en/latest-release/devguide/in...

amacneil 3y ago

> Especially a tool like RViz is always missing. And in many many robotics video I see (of a moderately complex robot), there's ROS's RViz on some screen. I would love the future robotics development stack to be more modular, so that (for example) future middleware solutions don't need to also bundle their own visualization software. This was direct inspiration for creating Foxglove Studio[0] for visualization and MCAP[1] for logging - both work great with ROS, or equally well without it. [0] https://github.com/foxglove/studio https://github.com/foxglove/studio [1] https://github.com/foxglove/mcap https://github.com/foxglove/mcap

elephantum 3y ago
Foxglove is my best argument to use ROS instead of custom solution in semi-robotics cases (several cameras/sensors + ML, but no actuators)
- ragebol 3y ago
  Yep. I've worked in a startup making a Laser Direct Imaging PCB photomasking machine, basically using lasers to do photo masks etc a couple year ago. When I came in, there was a custom IPC thing made, sending essentially Python dicts over ZeroMQ (IIRC). It worked to get the machine running and doing it's thing. For calibration of the cameras (needed to see how warped the PCB was and adjust the pattern) I needed to keep track of transforms etc. A perfect use-case for something like ROS's TF, in some incarnation. The machine was not a 'robot' per se, but there was many sensors, decision making, actuation, so kinda like a robot. For debugging the images and calibration transforms, we needed to write custom stuff. The whole thing was akin to ROS, with a couple days it could have been made to work with it. But alas

rektide 3y ago

It is wild to me that there's this whole huge message-bus/rpc system Data Distribution Service (DDS) that so much of thr computing industry else has never heard of, but which is totally core to ROS. https://en.wikipedia.org/wiki/Data_Distribution_Service https://en.wikipedia.org/wiki/Data_Distribution_Service It does have some real further mindshare. I noticed GM/Eclipse Foundation's new uProtocol has support for it. https://hn.algolia.com/?query=Uprotocol&sort=byDate&type=story https://hn.algolia.com/?query=Uprotocol&sort=byDate&type=sto...

anonymousDan 3y ago
Interesting. Does it define a wire protocol or is the interface implicit to the client library.
- elcritch 3y ago
  Both, sorta. There’s a serialization format, and the wire message format with QoS on top of UDP. The message format seems similar to MQTT semantics, but with a few extras. I think the wire format is fixed, but it’s pretty simple. The serialization layer (CDR) is swappable, but mostly all the same, though one of the most popular implementations uses a slightly non-standard FastCDR. Though from my testing it produces the same bytes and the CDR spec was updated. Maybe they match now. I wish there was a better implementers guide. DDS might be a decent alternative to MQTT for more generic embedded if so.
  - rektide 3y ago
    The wireshark wiki has a surprisingly good write up on the underlying RTPS protocol: > The Real-Time Publish-Subscribe (RTPS) Wire Protocol provides two main communication models: the publish-subscribe protocol, which transfers data from publishers to subscribers; and the Composite State Transfer (CST) protocol, which transfers state. https://wiki.wireshark.org/Protocols/rtps https://wiki.wireshark.org/Protocols/rtps ROS docs talk quite a lot a out various vendor implementations of RTPS middleware. But little docs on the protocol. Did a little search but haven't found many truly great in depth resources. OpenDDS seems to be the main impl I've stumbled across. Descend docs. https://opendds.readthedocs.io/en/latest-release/devguide/introduction.html#data-centric-publish-subscribe-dcps-overview https://opendds.readthedocs.io/en/latest-release/devguide/in...