Your 2023 ROS 2 TSC Community Rep Election is finally here! We’ve got six candidates that would like to fill two slots on the ROS 2 Technical Steering Committee (previous post). For reference there are three ROS 2 TSC community reps, with two reps elected in odd years, and one rep elected in even years. The election will run until 2023-10-20T04:59:00Z, and the winners will be announced on the last day of ROSCon 2023 in New Orleans. We also plan to post the results on Discourse, but this may take some time because, well, we’re all at ROSCon and PX4 Dev Summit.
For voting we’ll be using a type of ranked choice voting called the Condorcet voting method. To vote you simply rate the candidates in your preferred order. For recording the vote, we will use the Condorcet Internet Voting Service, and we request that you use your ROS Discourse handle as your, “recognizable identifier.”
Each of the six candidates were asked to submit a brief biography and candidate statement which are available below. After your have read all of the candidate statements below you can use the link below to vote. If you have questions post them below or send me a DM.
Make sure to use your Discourse handle as your recognizable identifier
Moderators note: I want to remind everyone, including that candidates, that we’re all here to work together to build a better open source project. Please try to keep the campaigning polite and constructive, and assume good intent. Moreover, I would appreciate it if everyone remains reasonable in their discussions about the ROS 2 TSC. The TSC is fundamentally a gathering of our peers where everyone future plans and current efforts are roughly outlined, not some shadowy, all-powerful, organization . My suggestion is that you make reasonable expectations about what a group of busy open source developers can and will accomplish while meeting for ninety minutes once a month. If you really want to understand what happens in the meetings in detail, just read the minutes.
Brett Aldrich (@brettpac)
Hello everyone, I’m Brett Aldrich and I’m the author of SMACC.
In case you’ve never heard of SMACC before here are some public demos we’ve made using it:
I was also speaker at ROSWorld2021
And here are some interviews if you feel compelled to dive deeper.
As I see it, there are 3 problems areas that need to be addressed.
The situation last year regarding the attendance (or lack thereof) of the TSC community reps was quite shameful. There rules regarding this were quite clear and should have been enforced, but werent.This needs to be fixed.
I propose to make the following changes, (I don’t want to take credit for these, many of these ideas have come from others…)
- I propose that all TSC meetings be recorded and posted publicly.
- I propose that all votes made by the TSC should be publicly disclosed, along with any comments by TSC members to clarify their position.
- I propose that TSC Community representatives be given access to ros.discourse analytics.
I propose that we implement an outreach plan and modify the TSC membership requirements for key robot hardware manufacturers in order to get wider participation in the TSC. Early names I would like to include would be Clearpath, UR, The Construct, NVIDIA, Franka Emika, Robotiq, Shadow Robotics, Husarion, Robotnik, Luxonis and a few others I’m leaving out.
I think this would do a lot for the relevance of ROS and the TSC. We’re here to build robots, right?
A word regarding experience…
I learned a few hard lessons during my first term on the TSC, including it takes a little more than enthusiasm to actually get things done.
But the 1 year term was definitely too short to really be effective. The TSC is kind of a complicated place when you first arrive, with a lot of people and a lot going on. Charters, reports, REPs, technical discussions, default implementations, etc. In my mind, It takes at least 3-4 months just to get the lay of the land. And in my case, the shortness of term was compounded by the fact that I didn’t know it was MY term that was only 1 year until month 10 or 11.
Anyways, this time, with the benefit of some experience…
I think I’m the guy to get this done.
Emerson Knapp (@emersonknapp)
Emerson Knapp is a robotics software engineer with a heavy focus on ROS 2. He started using ROS on Jade, building delivery robots with the startup Dispatch.ai. When Dispatch was acquired by Amazon, he helped bring the Scout delivery robot to first release, then moved to AWS to join thei ROS 2 open source effort, where he started contributing to the ROS 2 core in the Crystal Clemmys era. After Amazon, he worked with Foxglove to move ROS 2 bags to use MCAP, and to push forward types-on-the-wire. He’s got over 500 merged PRs and 900 code reviews in ROS 2, spread across the core and base, with a concentration on Rosbag2. Now Emerson continues to be involved in ROS 2 code review, maintenance, and contribution at his new role as Staff Robotics Engineer at Bonsai Robotics where he is leveraging ROS 2 to automate orchard operations.
When he’s not working on robots, Emerson is probably brewing beer or practicing yo-yo tricks.
Hey all, first and foremost I just really enjoy being a part of this ROS community. It’s been a great pleasure to get to know so many smart and passionate people, since getting involved I’ve learned and grown so much professionally and technically, really been able to enjoy building a career around ROS. Now that’s enough buttering you up.
Open source software in general is really important to me, I think it’s both a tool for equity in that everyone gets the same access to great tools, and also for technology acceleration because all of us working together and contributing makes much bigger and better things than we could produce behind closed doors. And I know that great open source software doesn’t just happen, it takes a lot of effort even beyond the code contributions. It takes design coordination, code review, infrastructure maintenance, and much more. I see the role of the ROS 2 Technical Steering Committee as being the forum for making decisions about these core aspects of keeping the project on a sustainable track and moving more forward than backward, so that the entire community can effectively make their contributions and take advantage of others’ work.
There always remains room to improve the TSC’s focus on the T-for-Technical portion of steering the project. The Community Representative role is a really positive initiative to put more on-the-ground day-to-day users of ROS 2 into the “room where it happens”, representing the voices of those who have open the ROS 2 docs permatab, scrying for insight to the signatures of rclcpp or ament APIs or best practices for QoS profile usage.
To put a lens on my particular perspective and focus: while I believe that academic and research usage of ROS 2 is extremely important for pushing the envelope of robotic capabilities, and that the use of ROS in academia is the reason ROS itself grew so much, my personal experience comes from one who’s almost exclusively worked to build products and companies with ROS and ROS 2. My contribution to the committee would reflect that perspective. This isn’t an either-or proposition, in my view - I believe that if this project focuses on meeting the technical rigor required to get products to market, it will also serve the needs of researchers.
If chosen for the role, my plan is to represent as constructively and concretely as I can the trials and tribble-ations of a ROS 2 line cook, to advocate and steer for the quality of life of career software developers and expose insights and interfaces to encourage a thriving developer community and darn good software product ecosystem.
David Lu! (@DLu)
My name is David Lu!! I started working with ROS in 2010 during my PhD at Washington University in St. Louis. I am the sole proprietor of Metro Robots, an independent software contracting firm, though previously I’ve worked for PickNik, Locus, Bossa Nova, Imagineering and Willow Garage, and have also worked with the PR2, Stretch, and a handful of robotic arms. The bulk of my work is focused on navigation (I authored the
robot_navigation stack and help maintain the standard ROS 1
navigation stack), and have also contributed many other ROS-centric projects, such as
roscompile, ROS Metrics, ROS Clock and ROS Map. I’ve presented at ROSCon four times, was the Co-Program Chair twice, and am running a workshop this year (although my singing talk was rejected this year).
Please visit davidlu.dev for links to all my projects and social media accounts.
Everything I said last year remains true, but since then, the challenges facing the TSC have massively shifted. My (naive and idealistic) goals for my candidacy are:
- Reprioritize the needs of the developer over the needs of the maintainers.
- Help usher in a new era of technical governance of ROS with transparency and consensus building.
- Keep pressure on Intrinsic (and other companies) to devote time and resources to open source projects over proprietary for-profit applications.
Steve Macenski (@smac)
Hi all, you probably know me as Your Friendly Neighborhood Navigator and long-time Nav2 project lead! I’ve been working on open-source in the ROS ecosystem since 2016 helping improve mobile robotics technology from SLAM to perception; planning to documentation.
From 2019 til earlier this year, I was the Senior Technical Lead at Samsung Research doing a number of things both internal and external around ROS and robotics. While I can’t point to much that I’ve done internally (except this!), I hope many of you are familiar with my work on Nav2 and the ROS 2 paper published in Science Robotics. It was truly an honor over the 4 years I was at Samsung Research America to be able to take such a proactive role in the ROS community and help bring new techologies to the robotics industry like the MPPI Controller, Smac Planner, Simple Commander, Constrained Smoother, and many more.
I started Open Navigation LLC in June of this year as the next phase in the ROS ecosystem, building an organization robust to the whims and wanes of massive conglomerates to ensure a sustainable future for Nav2 and the broader mobile robotics ecosystem’s development. No one wants to go back to the days of stagnate development, lack of maintainer responses, or a free-for-all to develop commonly needed features. We’re still early days into this process and we have some wonderful Sponsors who’ve stepped up to help build a stable future for the critical product dependencies that they rely upon (and you can too!). We still need several more sponsors before we can have full-time staff dedicated towards open-source development, maintenance, and support, but we’re making steady progress and I’m genuinely excited about the future – but only with your support!
As part of Samsung Research, I was on the TSC. I’m still technically a TSC observer since I provide updates on the ROS Navigation TSC Working Group (that meets every-other Thursday, please join!), but without voting rights or the ability to address topics to the TSC. I’ll readily admit that puts me in a unique position; there’s a legitimate argument to be made that another Community Representative should be selected that doesn’t already sit in the room.
However, I’ve always been a champion for making sure things are intuitive, well documented, and work great out-of-the-box, all of which we have some work to do still yet on. While I can’t promise I will accomplish some particular objectives as a voting and full member of the TSC, I can state that I will address topics as I see them to move towards that direction - whenever possible taking charge myself.
Two areas I’m passionate about addressing during this term:
I would like to see the completion of REP standardization regarding QoS settings for sensor data, maps, and other sensitive topics so that we can build community capabilities without incompatible QoS issues and provide users with best-practices solutions they can follow (https://github.com/ros-infrastructure/rep/pull/212)
I would like to see a policy established regarding AI-based software contributions and documentation so that we can embrace generative AI where folks would like to use it, but place important guardrails on disclosure and tracking of that data should legal concerns later arise.
Max Polzin (@maxpol)
In 2016, after finishing my Masters in Robotics, Systems and Control at ETH Zurich, I joined a team of two fresh graduates who founded Seervision AG to develop autonomous camera robots. In the five years ahead, I would learn how to grow a robotic research project into a commercially successful product. Lessons learned were of technical and organisational nature, i.e. how to develop reliable, robust and functional robots and how to scale a company’s operations. Seervision AG was acquired by QSYS, a global leader in the AV industry, in 2023.
Returning to academia in 2021, I joined the new Computational Robotics Design and Fabrication Lab at the Swiss Federal Institute of Technology in Lausanne (EPFL) as a PhD student. My research focuses on designing and developing novel robots for extreme environments, for example exploration in polar regions to study glacial crevasses.
Over the years, I’ve worked with numerous robots and software. I’ve collaborated on ground robots like Rover Robotics Rover Zero, Husarion Panther, and Clearpath Husky, integrating features like winches for steep terrain navigation and UR5 arms for agriculture. In the aerial domain, I’ve worked with TwingTec AG and developed custom robots for environmental studies. My robotics work leveraged and enriched not only the ROS and ROS 2 ecosystem, including many SLAM systems, Nav2, MoveIt 2, micro-ROS, and ros2_control, but also container, web and cloud technology.
Working in academia, I experience the challenges faced by novice robotics developers, especially those with a different background, such as mechanical engineers. The continued success of ROS depends on its ability to add value for robotics developers and grow its community. As community representative in the ROS 2 TSC, I hope to serve and grow the ROS user base by
- Voicing and representing the needs and challenges of early career developers.
- Initiating and pushing initiatives to ease the learning process for novice developers with diverse backgrounds.
- Establishing links between the ROS and other open source communities, particularly the Arduino and maker community and the drone community around the PX4 Autopilot.
- Advocating for continued adoption of ROS 2 in the academic environment and evangelising scaling implementations.
- Ensuring continuous evolution of the ROS 2 project towards an industrial-grade robotics middleware.
Having 10+ years experience in industrial and academic research and development with ROS and ROS 2 allows me to understand and reason professionally about the community’s needs and make an impact.
Struggling novice developers inspired me to initiate and maintain the ROSbloX project. ROSbloX are building blocks to rapidly create a robot’s software stack. They feature plug-and-play connectivity and integrated data visualisation.
I am mentoring EPFL’s Robocup@Home team to build their robot and participate at Robocup@Home in 2024. With my publications on field robotics in extreme environments and the resulting academic collaborations, for example with polar scientists, I showcase and advocate ROS to a wider audience.
Building bridges between the ROS, PX4 Autopilot, and Arduino/Maker communities, I am frequently publishing examples how to combine the best of all worlds to build advanced robots with novel capabilities on social media, https://www.linkedin.com/in/max-polzin-robotics/, https://www.youtube.com/@rosblox5056, @xploros, @maxpolzin12019. Examples include long-range data transmission over telemetry, a containerized, web-based version of PlotJuggler, or a template for efficient shared memory transport across containerized ROS 2 applications.
Some of my contributions to ROS 2 packages include the integration of the popular PCA9685 I2C PWM generator into ros2_control, pca9685_ros2_control, expanding mocap4ros2_optitrack with measurement delay compensation, an example for using Nav2 with GNSS/IMU only localization in Gazebo Fortress/Garden, and over 50 containerized ROS packages integrated with Github’s CI, e.g. ros-livox-ros2-driver, ros-dynamixel, ros-mocap4ros2-optitrack, ros-zed-ros2-wrapper.
Victor Mayoral (@vmayoral)
Roboticist and long term contributor to ROS and ROS 2. Strong technical background. Various affiliations with industry, academia and government organizations. Spent the last 10 years building robots with ROS. Founded, funded and led some robotic startups, getting to know early the good and the bad exits, while sharing a ROS-journey with quite some good folks. Continue trying to inspire people to build robot brains with ROS. Very interested in ROS-native hardware. One of the top experts globally on some ROS 2 topics including cybersecurity, embedded and hardware acceleration (systems/robots architecture). Strong ROS advocate (before that became a paid job ) and supporter, despite often proposing a different view. Been funding ROS initiatives and gatherings over multiple organizations, for multiple years (e.g. ROSCon).
Links of interest:
- Github: vmayoral (Víctor Mayoral Vilches) · GitHub
- LinkedIn: https://linkedin.com/in/vmayoral/
- Scholar: Víctor Mayoral Vilches - Google Scholar
I’ve been involved in ROS since 2011, when I started contributing to meta-ros (Yocto/OE layers to enable ROS in production-grade embedded systems). Later, in 2014, I had the fantastic opportunity to work closely with the Open Robotics folks, while doing my PhD, in the early days of ROS 2. Been involved with ROS 2 ever since then.
Over the years I’ve contributed to various parts of the ROS stack while reading the market (not always great) and acquiring funding to build ROS-teams. I keep track of some of the companies using ROS commercially (despite some here making it difficult for some reason ) My most relevant contributions are focused on three areas:
- ROS 2 in embedded systems: Maintainer and Multi-year contributor to meta-ros. E.g. brought Yocto (Honister) support for Humble Release. More recently, ported Humble to Yocto
Langdale. Involved in the early days of ROS 2 for microcontrollers. Involved in Hardware-ROS (H-ROS) endeavours. Involved in the early days of the micro-ROS project, and one of original EU consortia leads. Various contributions over various implementations for MCUs.
- ROS 2 cybersecurity: Obtained a few dozen CVE IDs in robotics, a few ROS-related. Helped bring up the ROS 2 Security Working Group, very involved in the early days. Helped build some of the original ROS 2 threat models. Built the Robot Vulnerability Database (RVD), proposed methodologies (RSF, Robotics CTF, DevSecOps in Robotics) and contributed to a bunch of tools to increase the security of ROS robotic systems (scapy ROS 2 dissector, aztarna, ros2_fuzzer, ros1_fuzzer, ros_volatity, etc.). Looked into DDS security issues with top security experts. Reported multiple vulnerabilities affecting ROS 2 systems and worked with authorities to make responsive disclosures, despite many of them remaining and still being ignored.
- (most recently) Hardware Acceleration in ROS 2: Developed and maintain multiple ROS packages to enable hardware acceleration in ROS 2 (
colcon-hardware-acceleration, etc). Worked with industry and with the ROS community to establish a vendor-neutral hardware acceleration architecture which got introduced in Humble release. Produced various community-driven REPs. Created and led the ROS 2 Hardware Acceleration Working Group (HAWG), attracting relevant (semiconductor) industry players to contribute in the ROS community. Despite the hurdles (HAWG still not showing up as a community WG for some reason), led the ROS 2 HAWG to become the most attended and an attracting source during 2021 and 2022.
As I expressed recently, I feel there’s a need for some changes at the TSC of the ROS community. If I get elected, I plan to pursue the following summarized objectives over my period (which will be open to improvements from community feedback at any point in time). For the long version, see discussion here. Shortly:
|ROS 2 TSC Issue||Suggeted improvements|
|Lack of Transparency||All decisions by the TSC should be disclosed, including voters and votes|
|Non-Technical Rejection||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|
|Lack of Strong Contributors||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||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||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. All TSC members should be elected periodically, not only “community reps”.|
|Inconsistency in Standardization||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||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|
|Inequitable Working Group Establishment||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.|