Hello,
I saw watched this talk and am very interested in contributing to the Medical ROS effort!
How do I get involved? Is there a dedicated channel?
Any help is appreciated.
Thank you!
Thanks for the link. I didn’t even know this existed. I am interested in knowing a bit more too. So now I, hopefully, will get notified if there are other replies 
1 Like
Even I tried to have a look into this field but it seem the project is at fundamental level and they haven’t formed a group here yet. May be @tfoote will be able to provide more insights.
1 Like
Thanks for the info ! We would be also very interested in participating to this project.
1 Like
The project is still being formed.
There’s some very early work and tooling which is available at:
In general however we want to avoid diverging from the mainline development as much as possible so a lot of the work to support this effort is targeted at being integrated into the default branches of the existing code base. So that we can avoid forking development.
We haven’t setup a dedicated channel or community effort yet. The best way I can suggest getting involved right now is to simply focus on helping improve the quality of the core capabilities of ROS. And of course keep an eye peeled for future communications.
2 Likes
Hi @tfoote,
this topic is very interesting to me as well.
I see that the repos / GitHub org that you shared are not specific to medical, but to anyone working on topics where safety is a concern (which makes it even more interesting ).
My question is: what is the difference between this project and the Safety WG (GitHub - ros-safety/safety_working_group: ROS safety working group repository)?
Kind regards,
Gergely
3 Likes
Thanks for the links of this topic, I am quite interested in benchmarking.
I have a question about the safe-ros tools. Can we consider that GitHub - safe-ros/ros2_profiling: A set of tools and techniques for evaluating performance of ROS 2 based systems share goals with RobotPerf (https://robotperf.org/) ?
2 Likes
Fantastic! Thanks for the info.
It’s probably worth having the Intrinsic folks commenting on this. Also, this discussion might be worth a different thread.
I’d point out that profiling (closer to tracing) is not the same as benchmarking. See [1] for a discussion on this. The approach we’re following at the ROS 2 Hardware Acceleration Working group through the RobotPerf subproject (GitHub org) focuses on benchmarking whereas ros2_profiling (to my understanding at least) focus on profiling. It’s true that the definition of ros2_profiling (which says “A set of tools and techniques for evaluating performance of ROS 2 based systems”) hints more towards benchmarking, which is confusing indeed. That said, both projects seem to be build upon the same underlying principles, which is good for supporting each other down the road:
From a tech viewpoint and looking at ros2_profiling and RobotPerf’s benchmarks together, both seem to be leveraging ros2_tracing and align very well to the ongoing standardization effort for Benchmarking ROS 2 at REP 2014. ros2_tracing provides the tracing tools we both leverage. That’s already a good common baseline. From my understanding of the source code, ros2_profiling focuses a bit more on the tools whereas RobotPerf’s benchmarks on the benchmarks. We’re just getting started, but RobotPerf’s benchmarks will put lots of emphasis on how to create new benchmarks (see benchmark specs), so that others (you!) can contribute their own performance evaluation tests. We’re interested to evaluate performance of ROS 2 Nodes and Graphs (as close as possible to real applications and) of incrementally growing complexity.
The point of divergence that I can see between these two initiatives is on how each project does a) collection, b) post-processing and c) analysis. @mjcarroll any chance you can drop to one of our weekly calls in the future to discuss this and align?
@fjrodl good to read you’re looking into benchmarking. Please consider contributing to either of the approaches. Also, have a look at REP 2014 and consider contributing benchmarks built on top of ros2_tracing. That way, either of the project will benefit. If you’d like to discuss your thoughts, feel free to join one of the weekly meetings of RobotPerf.
1 Like
I believe there is a quote about hard problems in computer science and naming things. Sorry for any confusion on that front. Let me try to clarify.
The overarching goal here was being able to instrument live systems without substantial modification and with low overhead and be able to retrieve metrics that are interesting from a safety point of view such as latency, jitter, bandwidth as well as indirect measurements like CPU/memory/IO statistics/etc. Many of these metrics directly overlap with those that you would be interested in from a benchmarking perspective. The goal is to launch an existing system, without modification, collect the necessary metrics, and then make assertions about the performance via a testing framework (pytest in this case).
I read the REP 2014 as well as some of the other referenced packages when we were initially setting out and reached the same conclusion that lttng is really the way to go in terms of generating the data that we would be interested in for this application.
The main portion of the ros2_profiling package that would be of general interest is a graph-based API for interacting with tracedata from a running system. This builds upon @christophebedard’s fantastic tracetools_analysis and exposes the data in such a way that makes analysis and testing easier. This also builds on the Message Flow Analysis with Complex Causal Links for Distributed ROS 2 Systems work to trace complex data flows through multiple nodes, processes, or potentially systems.
I think there is great potential for collaboration here, like Tully said, we tried to stick to the things that are generally available and accepted in the ROS community and have no intention of re-inventing any wheels.
I would be happy to join the weekly meeting to discuss more. I will put it on my calendar for next week. Thanks for pinging me on this.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.