Google Summer of Code - Call for Mentors

TLDR: GSoC 2025 has kicked off, and the OSRF is once again hosting projects. If you have a project and want to mentor someone, please get in touch by emailing gsoc@openrobotics.org!


The Open Source Robotics Foundation is planning on participating in Google Summer of Code 2025. We are now putting out a call for mentors. We need people to volunteer to mentor one or more projects and participants throughout the GSoC period.

By being a GSoC mentor, you will be contributing to a large technical contribution to one of the OSRF’s projects, but more importantly you will be contributing to the growth in expertise and experience of a new engineer! Being a mentor is very rewarding work, and we have seen many of our previous GSoC participants go on to be important long-term members of the community and long-term contributors.

Information on what it takes to be a mentor can be found on the GSoC website:

If you are interested in mentoring a GSoC participant this year, then please get in touch by emailing us at gsoc@openrobotics.org! Please describe why you want to mentor with the OSRF, what qualifies you to be a mentor, and what projects you wish to offer. For each project, please include the following information, in this bullet-list format.

  • List of prerequisites
  • Description of necessary programming skills
  • Difficulty level
  • List of potential mentors
  • Expected size
  • Expected outcome
  • Detailed description

For examples of projects that the OSRF has hosted in previous years, take a look at this page.

We are open to mentors until February 9th, 2025 at 18:00 UTC.

4 Likes

I’m not able to mentor this one, as I suck at python, but perhaps someone else could:

Adding jobserver support to colcon

Detailed description:
Currently its not possible to limit the amount of threads used by colcon exactly. E.g. one can specify the amounts of threads used per package (T) and the maximum number of packages build in parallel (P). Therefore colcon can spawn up to P*T threads.
On machines with little RAM this can leads to a system freeze, as all memory is consumed by the threads and the system starts swapping. E.g. This mostly happens for c++ packages with heavy template usage, were one thread can consume multiple GB of RAM.
As a workaround either T or P can be reduced, which then leads to longer build times, which is not desirable.

A better solution would be, to implement a jobserver like the one in catkin. A jobserver allows to control the total amount of threads used by all make child instances of colcon. Additional, one can monitor the RAM usage of the system, and dynamically limit the amount of threads used, if a low RAM threshold is hit.

For more information on jobservers see: POSIX Jobserver (GNU make)
The catkin jobserver implementation can be found here: catkin_tools/catkin_tools/execution/job_server.py at main · catkin/catkin_tools · GitHub

4 Likes

This would be great. Colcon continued to cause lock ups in CI for us and it’s not something we can solve.

Can I apply to become a mentor? I am working as a robotics software engineer at a startup but didn’t contribute previously in GSoC. I am good with ROS and willing to join.

1 Like