Skip to content

GSoC25

Jump to bottom
Jenn Nguyen edited this page Apr 4, 2025 · 38 revisions

Overview

This document describes a list of potential ideas created for the 2025 Google Summer of Code. However, the ideas are open to everyone with interest on collaborating, and OSRF is open to new ideas. Feel free to use our application template below to indicate your interest in some of the projects. If you would like to suggest new projects please email [email protected].

The following list shows a set of ideas that can extend the functionality of some of the open source projects led by OSRF.

ROS (Robot Operating System) provides libraries and tools to help software developers create robot applications. It provides hardware abstraction, device drivers, libraries, visualizers, message-passing, package management, and more.

Gazebo is a multi-robot simulator for indoor and outdoor environments. It is capable of simulating a population of robots, sensors and objects in a three-dimensional world. It generates both realistic sensor feedback and interactions between physically plausible objects.

Open-RMF is a free, open source, modular software system that enables robotic system interoperability. Open-RMF coordinates multiple fleets of indoor and outdoor robots with typical robotic use cases and integrates them with elevators/lifts, doors and other infrastructure.

Infrastructure is the computing infrastructure that supports the above projects, such as by providing continuous integration services and building binary packages.

The link between all projects is their open source nature and its relationship with robotics. Browse through the list and do not hesitate to contact us if you wish to participate in any of the projects. Share with us your thoughts and ideas on any future improvement or project you may have.

ROS 2 projects list

For a general introduction on how to start contributing to ROS 2, check out the Contributing page! If you have any technical questions feel free to ask them on Robotics Stack Exchange. For high-level conceptual discussions, post on ROS Discourse.

Improvements to ROS 2 Doctor 👩🏻‍⚕️

  • Prerequisites: Ubuntu and ROS 2 development environment, no need for specialized hardware.
  • Necessary programming skills: Familiarity with C/C++/Python, CMake, ABI/API.
  • Difficulty level: Medium.
  • Potential mentors: Tomoya Fujita
  • Expected size: 100 hours to 150 hours.
  • Expected outcome: A ROS 2 command line interface ros2cli with doctor sub-command and ros2_documentation.
  • Detailed description: Currently, the ROS 2 doctor subcommand, ros2 doctor, is lacking a lot of useful information, such as ROS environment variables, RMW-specific environment variables, and configuration and service information (number of endpoints, QoS compatibility status, etc). This information is really important and useful for debugging issues with ROS 2, and would greatly improve our ability to support issues reported by our user community. In other words, adding this new information to our existing ROS 2 Doctor command would accelerate community communication and make bug reports much more precise! Aligned with ros2cli development, this project also targets the implementation of improved documentation on how to create an issue report with a new issue template.
  • Reference pull requests: Add default github issue templates, add: get clients, servers info

Structured Parameter Support for ROS 2

  • Prerequisites: Basic knowledge of the rclcpp. No need for specialized hardware.
  • Necessary programming skills: Familiarity with C++, YAML, Python and CMake.
  • Difficulty level: Medium
  • Potential mentors: Janosch Machowinski
  • Expected size: 175 hours
  • Expected outcome: Ability to use structured parameters in rclcpp
  • Detailed description: Currently the ROS 2 Parameter interface only supports ‘basic’ datatypes, or arrays of basic datatypes. (E.g. int, std::string, float, std::vector<int>, std::vector< std::string >, std::vector<float> etc) The scope of this task would be, to add support for structured parameters,this is to say C++ structs as parameters, E.g.
struct MyConfigData 
{ 
int id; 
std::string interfaceName; 
std::vector<struct SomeOtherData> data; 
};

To achieve this goal, the following tasks need to be completed:

  • Modify ParameterValue -- A new member needs to be added to ParameterValue messages. The new member shall contain a structured parameter in the form of a YAML serialized structure.
  • Modify rclcpp -- Currently there a checks in place, that forbid passing of complex structures as parameters, these need to be removed.
  • Update parameter value -- The rclcpp::ParameterValue needs to be modified to return the serialized YAML structure.
  • Convenience methods -- Add convenience functions to convert the serialized structure to a ROS message. ROS messages have a built-in introspection feature. This feature shall be used, to auto serialize the YAML blob into a ROS message. The introspection feature allows to iterate the ROS message. Therefore one can run over a given ROS message and check, if the YAML blob contains entries for all the members in the ROS message. One can also check, if no additional entries are present in the YAML blob. As the ROS message contains the data type of each member, and a generic function to write it, the deserialization of individual message members can also be implemented in a generic way.
  • Stretch goal -- Implement tooling to generate YAML ‘layouts’ from a given ROS message. The goal is to implement a simple command line tool, for generating empty YAML structures for a given ROS message. These empty yaml structures are supposed to be used as templates / copied into configuration files.

C/C++ Struct to ROS Message Converter

  • Prerequisites: Basic knowledge of the rclcpp. No need for specialized hardware.
  • Necessary programming skills: Familiarity with C++, jinja, YAML, Python and CMake.
  • Difficulty level: Medium - Hard
  • Potential mentors: Janosch Machowinski
  • Expected size: 175 hours
  • Expected outcome: Automatic wrapping and unwrapping of C++ structures to ROS messages!
  • Detailed description:

The goal of this proposal is to enable a workflow with ROS 2, were one only needs write C/C++ structures and ROS 2 tooling takes care of the generation of intermediate message generation and serialization. This tooling would greatly reduce the amount of boilerplate code needed to transfer a given structure from one node to another node. The outcome we desire would be a tool that can take input of the form:

struct Foo { 
  int a; 
  float b; 
}; 

struct Bar { 
  std::vector<Foo> foos; 
};

and automatically generate the following two ROS messages along with the corresponding typeAdapters :

Foo.msg: 
Int a 
Float32 b 

Bar: 
Foo[] foos

This goal shall be archived by the usage of castxml , Python and Jinja. Castxml is a tool, that converts C++ headers to an xml abstract syntax tree representation, without the hassle of parsing C/C++ code. Therefore castxml enables simple Python scripts to perform C++ introspection. Jinja is template code generation library, that can be used from Python. Combining castxml with jinja therefore allows us to parse arbitrary C++ structures, introspect them, and generate matching ROS message. It also allows for generation of serialization code from the structure to the ROS message and back.

Stretch goal: opaque type support

Opaque types are types, for which no automatic serialization and intermediate message can be generated For example, Eigen::Vector2d
would be opaque, as some members are private. Therefore there should be the option, to register handlers for these opaque types. The handlers shall enable the user to specify custom messages and converter functions for the given opaque type. Library support would be a secondary stretch goal. The system shall generate installable files, that register (if included / loaded) known types as opaques. The auto-generated ‘library opaques’ should just refer to the already generated messages and converters of the originating library. This would effectively suppress type generation for types from other libraries.

Improvements to ROS 2 Tracing

  • Prerequisites: ROS 2 experience, some tracing/LTTng tracer experience, Linux, Git
  • Necessary programming skills: C++, Python
  • Difficulty level: Medium to Hard
  • Potential mentors: Christophe Bédard
  • Expected size: 175 hours to 350 hours
  • Expected outcome: A solution to allow enabling the ROS 2 tracepoints after an application has already been launched.
  • Detailed description: Software tracing is a method of collecting low-level runtime data to understand a system's execution. ros2_tracing is a collection of tracing instrumentation for ROS 2 and tools to configure tracing for ROS 2 applications. See the ros2_tracing repository and this ros2_tracing introduction in the ROS 2 docs. Currently, when tracing a ROS 2 application, the tracer has to be configured and tracing has to be started before launching an application. This is because important trace data is generated during the initialization phase of an application; without this information, trace data generated later (e.g., message publication data) cannot be decoded. This means we cannot decide to start collecting trace data for an application that is already running, which makes debugging a system that’s already running harder. The first goal of this project is to find a solution to allow configuring tracing at any point after the application has been launched. See ros2/ros2_tracing#44. This would also make live tracing easier: live tracing means processing the trace data live, as the application is executing, unlike the typical workflow, which is to process the trace data offline, after the execution. A stretch goal for this project would be to improve the tracing configuration tools (ros2 trace command, Trace launch action) to allow configuring a live tracing session. See ros2/ros2_tracing#149.

Gazebo projects list

For a general introduction on how to start contributing to Gazebo, check out the guided tutorials and Contributing guide! If you have any technical questions feel free to ask them on Robotics Stack Exchange or message @HelloWorld on Gazebo Community. For good first technical issues to tackle and become familiar with the development workflow, search on GitHub under the "gazebosim" organization for "good first issue" tags. The "help wanted" tag may contain more advanced tickets.

Raytracing enabled Faster-Than-Realtime GPU based lidar plugin for Gazebo

  • Prerequisites: Cursory understanding of what a GPU is and what "ray tracing" means in the context of graphics. Access to a ray tracing enabled GPU on a non-Apple platform (one can be provided remotely if necessary).
  • Necessary programming skills: Familiarity with C++, CMake and an understanding of ABI.
  • Difficulty level: Medium to hard.
  • Potential mentors: Arjo Chakravarty.
  • Expected size: 175 hours to 350 hours.
  • Expected outcome: A source buildable package containing a LiDAR plugin for gazebo that exploits raytracing.
  • Detailed description: This GSoC project exploits ray tracing GPUs in Gazebo. Recently, GPU manufacturers have been adding raytracing capabilities to their GPUs. This includes Apple, Intel, AMD and NVIDIA. Ray tracing has been shown to be an effective pathway for simulating faster-than-realtime depth sensors. Other simulators that do this only exploit NVIDIA's proprietary OptiX API. Recent work in the Rust wgpu community has made it easy to use the Vulkan APIs for raytracing. Early experiments show the ability to ray trace a 256x256 depth camera at 1000fps on a consumer laptop with a 4 year old GeForce 3090 GPU. A prototype has alreasdy been produced, so this project would be focused on extending the prototype into a complete solution. The prototype builds on the rust wgpu package and a thin C wrapper that enables integration into Gazebo. Potential extension work is to support various types of depth sensors including maritime sonars/radars, along with potential publication to a relevant robotics venue.

Gazebo Plugin For Gaussian Splatting

  • Prerequisites: Cursory understanding of what a GPU is. No need for specialized hardware. Some knowledge of what NeRFs and Gaussian Splats are.
  • Necessary programming skills: Familiarity with C++, GLSL, and CMake.
  • Difficulty level: Medium to hard.
  • Potential mentors: Arjo Chakravarty.
  • Expected size: 175 hours to 350 hours.
  • Expected outcome: A ROS 2 package with the relevant Gazebo plugin to display splats.
  • Detailed description: Gaussian splatting is an up and coming technique for realtime photo-realistic rendering. It could solve the problem of photo-realism without the need for a specialized 3D artist. This can be a game-changer for the way we simulate robots. The goal of this project is to write a simple shader plugin for Gazebo that renders these splats. Work in this project may lead to a publication. If the candidate wishes, we could also add ROS tools to generate such splats from ROS 2 bags.

Physics-based sonar simulation and new examples with commonly used hardware for underwater robotics

  • Prerequisites: Linux, Git, experience with ROS and Gazebo, familiarity with basic simulation concepts.
  • Necessary programming skills: C++, Python and CUDA.
  • Difficulty level: Medium
  • Potential mentors: Woen-Sug Choi, Mabel Zhang and Rakesh Vivekanandan.
  • Expected size: 350 hours.
  • Expected outcome: Complete the migration and enhancement of a physics-based sonar simulation plugin, enriched with new example cases for underwater robotics. The project will leverage the ROS 2 framework and the latest long-term support (LTS) version of ROS and Gazebo (ROS Jazzy and Gazebo Harmonic). The ultimate goal is to provide a robust tool that can be optionally upstreamed to the new Gazebo, significantly benefiting the maritime robotics community.
  • Detailed description: The focus of this project is migrating and enhancing the physics-based multi-beam sonar simulation from Project DAVE (a community library for maritime robotics using ROS and Gazebo), adapting it to function within the ROS 2 and new Gazebo environments. This includes selecting essential components of Project DAVE to maintain the integrity of example use cases. Key aspects of improvement are:
    • Performance Enhancements: Introducing half-precision calculations in CUDA to boost refresh rates, potentially contributing to journal publications.
    • Capability Expansion: Extending simulations to incorporate additional sonar types, such as side-scan and mechanical scanning sonar.
    • Benchmark Integration: Incorporating benchmark cases for maritime robotics hardware, including notable examples like the BlueROV, to ensure the model's adaptability and accuracy in simulating hydrodynamic properties. This project is inspired by the latest advances in underwater sonar simulation technology, which employs acoustic scattering models and GPU-accelerated CUDA computations to deliver physically accurate sonar imagery at functional refresh rates, crucial for realistic robotics simulations. We believe that these enhancements will not only improve sonar simulation but also provide invaluable resources to the maritime robotics community in developing solutions that are both innovative and practical.

Open-RMF projects list

Improve UI/UX of Site Editor

  • Prerequisites: Proficiency with modern programming languages like C++, Python, JavaScript, or Rust. Experience creating UI, either using immediate mode (e.g. imgui, egui) or retained mode (e.g. angular, react, Qt) UI frameworks. Great to have: Familiarity with Rust and Bevy, experience with designing UIs, experience using 3D CAD tools Difficulty level: Easy to Medium
  • Mentors: Xiyu Oh, Grey.
  • Expected size: Medium to Large (320 hours to 480 hours).
  • Expected outcome: An improved user experience for the site editor.
  • Detailed description: The Open-RMF site editor is a 3D tool for creating and editing digital twins of facilities where robots operate. While the tool has a considerable amount of functionality, it currently suffers from a cluttered UI that might not be intuitive for users. At a minimum this project would aim to declutter and refine the UI by reorganizing the widgets and taking advantage of the builtin capabilities of egui, the UI framework that is currently being used by the site editor. A more ambitious candidate can consider migrating the site editor to a different UI library, perhaps one that is reactive and uses retained mode rendering. The site editor is fully implemented in Rust and the Bevy video game engine, so all work for this project will be done in Rust.
  • Expected breakdown:
    • Evaluate the current state of the site editor UI/UX by experimenting with its current usability.
    • Identify usage pain points and draft ideas for what changes to the UI could improve it.
    • Evaluate the capabilities of egui and identify whether it offers the capabilities needed to improve the UI or if another framework should be considered.
    • Implement improvements to the UI and iterate. Gather feedback on usability from the team and continue to refine the improvements.

Workflow Diagram Editor

  • Prerequisites: Familiarity with graphical behavior models like Behavior Trees or Petri Nets. Proficiency with modern programming languages like C++, Python, JavaScript, or Rust. Great to have: Familiarity with Rust and Bevy, experience with programming 2D canvas widgets.
  • Difficulty level: Medium to Hard
  • Potential mentors: Grey / Luca Della Vedova
  • Expected size: 400 hours to 480 hours
  • Expected outcome: A Bevy-based library for graphically editing diagrams on a 2D canvas. The library’s capabilities should be suitable for a follow-up project to create an application to draw and edit workflow diagrams for bevy_impulse.
  • Detailed description: bevy_impulse is a library in the Open-RMF project that allows users to define complex multi-agent workflows. Workflows are similar to Behavior Trees but are not limited to a tree structure. They can be considered a special case of Petri Nets. A 2D diagram editor that allows users to sketch workflow diagrams would allow us to unlock the full value of bevy_impulse by enabling visual programming of multi-agent behaviors. A fully realized workflow editing application might not be feasible for the scope of one GSoC term, so we primarily aim to start building a foundation for that application. The library will be developed in Rust using the Bevy game engine so it can be cross-platform and target web assembly for use in web browsers, and integrate well with bevy_impulse’s libraries.
  • Expected breakdown:
    • Get familiar with Bevy and its surrounding ecosystem of third party plugins.
    • Get familiar with the workflow concepts that are used in bevy_impulse, e.g. its various operations and how they connect together.
    • Investigate various diagram editing tools (e.g. Unreal’s Blueprint editor and Unity’s Visual Scripting editor) and draw inspiration for how the UI might work.
    • Devise a strategy for how the widgets would be rendered in a Bevy application.
    • Implement the rendering of the diagram widgets and connection curves
    • Provide an API for downstream projects to decorate the diagram widgets according to their use cases.

Multi-Agent Traffic Optimization

  • Prerequisites: Proficiency with motion planning and graph search. Experience with Rust programming or familiarity with languages like C++, Python, and JavaScript.
  • Great to have: Familiarity with Rust and Bevy, experience with multi-agent path finding algorithms.
  • Difficulty level: Medium to Hard
  • Potential mentors: Grey / Luca Della Vedova
  • Expected size: 320 hours to 480 hours
  • Expected outcome: The mapf library is a multi-agent path finding and planning framework developed for the next generation of Open-RMF. For this project the contributor will improve multi-agent traffic debug tools in the Open-RMF site editor and use them to ensure consistent, intuitive multi-agent paths are generated by Open-RMF’s mapf library.
  • Detailed description: A key component of Open-RMF is the ability to route multi-agent traffic to avoid conflicts between mobile robot agents that are each performing independent tasks. The mapf library was designed to be a modular, customizable framework for multi-agent path finding. The goal of this project is to pressure test mapf, identify scenarios where it fails or gives inconsistent results, and resolve any underlying issues that could negatively impact its use in a deployment. The site editor will be used to generate test cases, to simulate the results of the mapf library, and to provide a tool to debug the planner. The debugging tool would visualize and step through each iteration of the mapf solving process, allowing the user to investigate how the solver works and identify where it could be improved. This role may involve enhancing the debugging tools in addition to the mapf library itself. Both mapf and the site editor are written in Rust, so this role will be done entirely in Rust.
  • Expected breakdown:
    • Familiarize yourself with the site editor and how to create different scenarios.
    • Familiarize yourself with the debugging tool and how multi-agent plans are generated.
    • Build different scenarios, looking for failure cases or sub-optimal solutions.
    • Use the debugging tools to track down the causes of undesirable behaviors.
    • Ambitious candidates may work on creating pipelines to automatically generate large scenarios and/or to add randomization to test cases.

New Open-RMF Demo: Free Fleet Map Switching

  • Prerequisites: Linux, Git, ROS 2, Gazebo, familiarity with Nav2 and Open-RMF are a plus
  • Necessary programming skills: Python, C++.
  • Difficulty level: Medium
  • Potential mentors: Aaron Chong
  • Expected size: 175 to 350 hours
  • Expected outcome: A new Open-RMF demo simulation which showcases Open-RMF integration with a fleet of turtlebots running Nav2 and Free Fleet within a two story building. These two simulated robots will be capable of navigating and performing tasks across the multiple building levels and switching Nav2 maps when arriving at a particular floor via elevator. This new demo will serve as a starting point for folks new to Open-RMF and Free Fleet.
  • Detailed description:
    • Simulation demo and mapping: Re-use the existing rmf_demos hotel world, to create a new demo world and replace the existing robots with two simulated TurtleBots. These turtlebots will then map the simulation world and share the map between themselves to support single-floor navigation using Nav2.
    • Integration of Open-RMF and Free Fleet: Set up a Free Fleet adapter, and integrate it with the two TurtleBots, to support basic single-floor Open-RMF tasks.
    • Implement localization and map-switching command: This will allow the simulated robots to traverse levels using the virtual elevators, switch Nav2 maps, and still be able to localize, navigate, and receive Open-RMF commands to perform tasks across levels. Other supporting features within the Free Fleet Adapter will also require implementation. The fleet_adapter_mir can be used as a reference implementation.
    • Documentation of usage, configuration and the new simulation as a "how to" guide for users .

ROS Controls projects list

Mission-Control for ros2_control

  • Prerequisites: git and Github
  • Necessary programming skills: C++, Python
  • Difficulty level: Medium
  • Potential mentors: Bence Magyar, Sai Kishor
  • Expected size: 175 hours to 350 hours
  • Expected outcome: A new tool that supports transitioning ros2_control components between known states using a declarative notation.
  • Detailed description: The ros2_control framework focuses on direct management of hardware and their controllers to enable real-time capabilities with ROS. Although those interfaces are easy to use, they provide only "manual" control over the system's state. Therefore, very often in more complex systems our users have to implement an external, state-machine like component that serves as an orchestrator for ros2_control. The main purpose of such a component is to serve as a high-level conductor of ros2_control making sure that at the appropriate moment the right controllers and hardware are in expected states. The project could also synergize with ongoing state visualization efforts as well as an extension to wrangle ROS 2 Managed Nodes. This functionality should replace some high-level components currently used, e.g., MoveIt2-"SimpleControllerManager".
  • Goals:
    • Defining a scenario in form of a multi-robot and multi-tool configuration and its behavior that serves as a benchmark.
    • Review that the controller_manager provides all the necessary data for this application.
    • Define a file format for users to declare controller / state presets.
    • Implementing the mission-control module/script that sets the controller_manager, i.e., the ros2_control framework, in a specific configuration/state.
    • Contributors are encouraged to review existing research papers and open source projects for similar functionality.

Hardware Diagnostics Support for ros2_control

  • Prerequisites: git and Github
  • Necessary programming skills: strong C++, ROS 2
  • Difficulty level: Medium/Hard
  • Potential mentors: Bence Magyar, Sai Kishor
  • Expected size: 175 hours to 350 hours
  • Expected outcome: Reporting capabilities are available for hardware components with minimal code changes
  • Detailed description: The ros2_control framework uses a plugin-based system to support multiple hardware drivers at the same time. It takes care of resource constraints between different controllers and hardware components, asynchronous operation of controllers, etc. As of now, controller_manager publishes the diagnostics of itself, and for controllers and hardware components about their lifecycle state and operational statistics such as their periodicity and their execution time. However, A current limitation of the framework is that hardware components, e.g. the ros2_control hardware driver plugin for a given robot, doesn't have a good API for reporting the diagnostics of its own hardware, for instance, the state of the CAN Bus, some internal motor control board stats like temperature, error codes etc. This integration would make the ros2_control, provide complete diagnostics within its ecosystem. This project focuses on setting up an API that hardware manufacturers & driver maintainers can use to report things with minimal code changes to their existing setups.
  • Goals:
    • Modify the Hardware Interfaces to fetch the hardware diagnostics.
    • Possible unification of three hardware interfaces into a single one.
    • Add tests to test the integration.
    • Add Documentation.

Infrastructure Projects

Releasing sdformat in PyPI

  • Prerequisites: Experience with Git, Python packaging, CMake and GitHub Actions.
  • Necessary programming skills: CMake, Python and C++.
  • Difficulty level: Medium
  • Potential mentors: Jose Luis Rivero.
  • Expected size: 350 hours.
  • Expected outcome: A mechanism that allows the Gazebo project to release sdformat in PYPI.
  • Detailed description: Implement a method to generate a Python Wheel from the SDFormat source code using standard Python packaging tools. Automate the process of releasing a Wheel by integrating the Wheel creation into the release pipeline of the Gazebo project. Integrate the PyPI publishing mechanism into the release pipeline. Try to generalize the solution so it can be applied to other Gazebo libraries.

vcstool Modernization and Improvements

  • Prerequisites: git and other version control systems, GitHub Actions
  • Necessary programming skills: Python
  • Difficulty level: Medium
  • Potential mentors: Clara Berendsen, Jose Luis Rivero, Christophe Bédard
  • Expected size: 175 hours to 350 hours
  • Expected outcome: Modernize use of Python, create new useful features
  • Detailed description:
  • vcstool is a meta version control system tool that interacts with multiple version control systems to make working with multiple repositories easier. It is heavily used in ROS and Gazebo environments, for example when building ROS 2 from source or in the Gazebo source installations. It is an official package in Debian and Ubuntu among other distributions and also available via PyPI. vcstool has not really been maintained over the last few years. The first goal of this project is to update it to bring modern Python support to the code and replace the ancient implementations. The GitHub Actions workflow also needs to be updated, since it uses older versions of actions. There are many bug reports, feature requests, and open PRs (see the original repository). The second goal of this project is to help fix bugs, identify interesting feature requests and implement them, and in general help shape the future direction of vcstool. Expanding vcstool’s API surface so it can be used in place of https://github.com/vcstools/vcstools would be an excellent stretch goal for the project.

Add support for mixin composition in colcon-mixin.

  • Prerequisites: git and GitHub, have used the colcon build tool in the past
  • Necessary programming skills: Python
  • Difficulty level: Medium
  • Potential mentors: Scott Logan, Sean McGrath, Steven! Ragnarök
  • Expected size: 175 hours to 350 hours
  • Expected outcome: Add new features to colcon-mixin which will allow mixins to reference other mixins.
  • Detailed description: colcon is an extensible build tool optimized for building collections of federated projects which is commonly used with Open Robotics projects. Mixins allow for easily repeating complex actions by incorporating command line arguments defined in external files. It is not currently possible for the command-line arguments provided by a mixin to reference other mixins but this feature has been requested in https://github.com/colcon/colcon-mixin/issues/39 This project will involve constructing a mixin graph and exploring how to determine the order of application as well as how mixin arguments extend or override arguments from referenced mixins.

Relevant resources

ROS

ROS web page

ROS 2 tutorials

ROS Q&A

List of code repositories

Gazebo

Gazebo web page

Gazebo tutorials

Gazebo Q&A

Gazebo mailing list

GitHub (code and issue tracker)

Open-RMF

RMF root repository

RMF Site Editor

Open-RMF Workshop at ROSCon 2022)

Application template for students

  • If you would like to suggest new projects you are free to e-mail your ideas to us at: [email protected]. We recommend you stick to one of the projects listed above unless you have already recruited a mentor.
  • If you have specific questions to discuss about a project, send an email to [email protected]. You may also ask your question in the gsoc-q-and-a channel on our Discord server.
  • If you meet the general requirements and are interested in working on one of the OSRF projects during Google Summer of Code, you can apply by submitting your application through the Google GSoC web site once participant applications open on March 25th, 2025.

Completing Your GSoC Application

Proposal Title

Your proposal title should match one of the projects listed above.

Proposal Summary

For your proposal summary introduce yourself and briefly discuss your plan for addressing the project you have selected.

What to Include in Your Proposal PDF File

Your proposal PDF file should include the bulk of your application. Please include the information outlined in the subsequent four sections below.

Contact Information

  • Your name
  • A phone number
  • An email address where we can reach you for daily communication
  • Your Github profile or personal website

Education and Coursework

Please provide information about your university, degree type, and your expected graduation year. Please list relevant technical courses you have taken. In particular, we are interested in your background in:

  • Robotics
  • Software engineering
  • Computer graphics
  • Physics simulation

Experience

Please list any experience you’ve had in software development, including relevant class projects, internships, undergraduate or graduate research, and/or contributions to open source projects. For each example, please include a brief description of the overall project along with the specific contributions you made and when you made them.

In addition to the above information, we are interested in concrete examples of your work, which may include:

  • 📢 Open source contributions: Our mentors are looking for students who have mastered the fundamentals of open source contribution. If you have contributed to any of our open source projects, or any other open source projects, please include a link to those contributions prominently in your application.
  • Sample code: please send an example of code you have written that you are proud of; be prepared to answer questions about it. A link to a Github repository works the best!
  • Publications: if you have participated in undergraduate or graduate research, please include a link to a copy of any relevant publications.
  • Specialized skills: if you have experience/skills in particular areas that you believe would be useful to one of our projects, please let us know.
  • Personal website: if you have a website that discusses your research or other projects, please include a link.
  • References: names and contact information for people you have worked with who can recommend you.

Statement of Intent

In a paragraph or two, describe your interests and background. Please tell us which of the project ideas you are interested in and why you’d like to work on it. If you have a proposal for a project not included on our list, please describe the idea clearly and provide a motivation for the work and a timeline for how you plan to accomplish it.

⚠️ A Note on Generative AI ⚠️

We strongly discourage students from using generative AI tools to generate their application. Students working with OSRF project mentors over the summer must possess strong communication skills. Our mentors use GSoC applications to evaluate each student's written communication skills. Our mentors may choose to reject students they suspect have used generative AI tools as part of their application. Moreover, as per the OSRA's interim policy on generative AI tools, contributors are not permitted to use generative AI tools for code contributions.

Clone this wiki locally