Jaime, while I do not wish to engage in public fights with you or a discussion about Acceleration Robotics, I feel compelled to address the attacks and misunderstandings in your response. It seems there is a fundamental misunderstanding on your part about my role and the work we do at Acceleration Robotics.
Your characterization of our work as merely “enclosing others hardware in a plastic box” (referring to ROBOTCORE RPU, an open community-oriented design we disclosed as part of our work in the HAWG[1]) is not only incorrect but also demonstrates a profound lack of understanding of the technology and the broader robotics ecosystem. Semiconductor building blocks refer to Intellectual Property (IP), or hardware designs that then turn into hardware (and or silicon, depending on whether they become soft-cores or hard-cores). Your own products run on what was once a soft-core, only to become a hard-core. The whole robotics ecosystem (and hopefully spearheaded by ROS) is going to benefit significantly from domain-specific compute architectures. That’s what we’ve been doing for a few years now. That’s what many are doing now.
Examples of some of our released products include ROBOTCORE Transform or ROBOTCORE Perception, which are ROS 2 API-compatible and give you a computing performance increase. You’re welcome to check those (or have your team look at them) and send feedback if you wish.
You’re once again misunderstanding (purposely?). I will repeat it: because “you are not involved in the technology anymore, you should get someone involved in the technology from your side that can help steer the project (participate in the ROS 2 TSC)”. I’m not making a statement about you personally, or about technology in general. I’m questioning your capabilities as a ROS 2 TSC representative and how much that brings to the community.
Your decision to dismiss our framework outright without consideration is disappointing, but not surprising given your apparent lack of understanding of our intentions and the work we do. Accusing me over an over of ad hominem attacks and attempting to deviate the conversation is a diversionary tactic that does not address the substantive issues at hand.
Your attack on my position, and our products is very unprofessional. As a TSC representative, it is your responsibility to represent the interests of the ROS community, not just your own or your person or your company’s. Your response, however, seems more focused on attacking me and my company rather than addressing the substantive issues at hand. Again, asking for more accountability from TSC members.
Your comments about NVIDIA and your accusation of us using other names to market our products are ridiculous, baseless and unfounded. We have always been transparent about our collaborations and references to other projects and companies are made in the appropriate context.
This (discussion) is about the ROS community, not the overall market. I’ve been extremely critical myself towards the attitude of companies like NVIDIA over multiple threads here in Discourse, calling for technology alignment (as opposed of forks and re-marketing), calling against their lock-in approach by forking and changing APIs, calling for community-aligned benchmarking (using what’s already a standard, but not qualified to become a REP, that is ros2_tracing) and also complaining about those times wherein NVIDIA forked packages and changed their license to make it less commercially friendly (packages many of us here have contributed for a decade).
This is one of those things TSC members like you should be looking at (and btw, as acknowledged above, we got positive “reactions” out of these past discussions).
And again, I reject your view. It’s not my approach, it’s the community approach. Not because I say so, because it’s been embraced for years now. The whole ROS 2 stack is instrumented with ros2_tracing which is the basis of REP-2014 (again, something you’d know if you were closer to technology), which makes me confident that it should get standardized, and which triggered this whole rant. There’re even DDS implementations that have been instrumented with ros2_tracing and/or LTTng (e.g. CycloneDDS) giving robotic engineers the capability to better understand their dataflows. It’s important for you to understand that this is not me being right, it’s what’s out there, what’s adopted. When/if your group @Jaime_Martin_Losa decides to align to the trend (and instrument your DDS solutions to align with LTTng/ros2_tracing), you’ll be aligning with the community, not “feeding me”.
By the way Jaime, you’ve repeatedly pointed out that there’s no consensus. But there is, even with NVIDIA. As I explained above, the rejected the use of ros2_tracing (grey-box performance benchmarking) and instead decided to re-implemented ros2_benchmark (black-box performance benchmarking). We studied their approach, forked it to improve it and integrated it in both REP-2014 and RobotPerf (empowering you to do both). So yes Jaime, we’ve worked towards consensus from a technology point of view. And I think we have it.
From your words, It is clear that the rejection of the REP has more to do with politics and personal biases than the merits of the proposal. Your responses @Jaime_Martin_Losa only reinforces this perception. It is disappointing to see this level of unprofessionalism from a TSC representative. Instead of attacking those who are trying to contribute to the community, perhaps it would be more productive to focus on constructive feedback and working towards solutions that benefit the entire community.
Repeating myself, I recognize that emotions can run high when we are passionate about a subject. I’ll try to be more constructive re-iterating those proposals I believe are necessary for situations like this to be avoided in the future (small edits included on each proposal stated before, hopefully improving them):
| ROS 2 TSC Issue | Comment | Suggested action |
|---|---|---|
| Lack of Transparency | I criticized the lack of transparency in the TSC’s decision-making process, particularly in the evaluation of REP-2014, and other WG-related matters. I called for more openness and accountability. | All decisions by the TSC should be disclosed, including voters and votes |
| Non-Technical Rejection | I expressed frustration that the feedback for the rejection of REP-2014 was mostly non-technical, despite the proposal feedback being discussed, reviewed, re-iterated based on initial feedback, which we addressed in detail | TSC comments and feedback should remain technical. If they don’t have the expertise, they should either defer to the corresponding WGs or invite external independent experts (without conflicts of interest) that advise accordingly |
| Political Nature of TSC | I criticized the TSC for being more political and less technological, and questioned the value of the current TSC setup | TSC membership shouldn’t be voted by the TSC, it should be voted by the community as a whole (open poll to all members of the community), preferrably in an open/transparent manner (again to facilitate accountability). Also, TSC memberships should be renewed and voted periodically, e.g. every year. Politics and lobbying within the TSC should be rejected. |
| Lack of Strong Contributors | I criticized the TSC for missing strong contributors, key players, and individuals with a strong track record in the community. | TSC should be diverse in both gender and representation. Companies (Big companies, smaller and startups) as well as community (non-affiliated membership) representatives should get similar representation counts. The overall ROS community should have avenues/methods to raise concerns against TSC members, and methods to replace them if appropriate |
| Anonymous Lobbying | I expressed concern about anonymous lobbying (mostly corporates, and under confidentiality) and the confidential tone of ROS TSC discussions | Confidentiality should not be part of the TSC on a general basis and never used for TSC decisions, or to justify the TSC. Members can establish confidentiality outside of the TSC if needed. Nobody should be put in the position of “hey, resign because you’re breaking confidentiality”. Transparency should be an inherent part of what the TSC does. |
| Need for Community-Centric Governance | I called for a change in the current leadership towards a more community-centric governance model | TSC community representatives should increase to match the count of company representatives and (regardless of their affiliation) should act as non-affiliated for what the TSC matters concern |
| Inconsistency in Standardization | I criticized the inconsistency in the TSC’s decision to reject standardizing a benchmarking approach in ROS 2, despite existing ROS codebase consensus, despite existing accepted implementations and despite the consensus reached among those involved in its development | Accept the community standards as community standards. Don’t reject what’s obvious (e.g. adoption of ros2_tracing for tracing and metrics collection, when the whole ROS 2 stack is already instrumented accordingly). |
| Lack of Accountability | I criticized the opacity and lack of accountability in the governance structure, and called for proper mechanisms to replace inactive or non-contributing representatives | Better accountability by recording meetings. Also, all votes should be publicly disclosed, with the corresponding voters. Voters should be allowed to provide comments to clarify their position. All TSC members should be elected by the community, accountable for their acts and/or replaced given the right circumstances |
| Slowing Down of Innovation | I expressed concern that recent policies and events are slowing down the innovation process in the ROS ecosystem and discouraging many from continuing to contribute | Proactive contributions aligned with ROS interests should be encouraged. Not discouraged or stopped due to lobbying and market interests. TSC should carefully consider the technical value of each new initiative and its implications for the ROS ecosystem. If in conflict, other companies’ vision about such new contributions should be discounted |
| Inequitable Working Group Establishment | I criticized the current exclusion and classification among Working Groups (WGs), as we are all part of the same community and represent the same interests, whether on the TSC or not. | Establish more homogeneous WGs that do not exclude or classify members based on their affiliation with the TSC or any other organization. All members of the ROS community should have equal opportunities to participate and contribute to the WGs. |
Again, you’d know this if you were technically competent and or would’ve been tuned to the Hardware Acceleration working group activities. ↩︎