List of Suggested Projects for GSoC 2024

This is a list of projects suggested by ArduPilot developers for GSoC 2024. These are only suggestions so if you have your own ideas then please discuss them on the ArduPilot Discord Chat or on the discuss server here. We have a lot of talented developers in the ArduPilot dev team who would love to mentor good students for GSoC 2024.

  • Visual Follow-me using AI

  • MAVProxy AI chat enhancements

  • WebTools automated log analysis

  • Improvements to the Custom Build Server

  • High Altitude Non-GPS Position Estimation

  • Improve web server for file management and parameter management

See lower down on this page for more details for some of the projects listed above


The timeline for GSoC 2024 is here

How to improve your chances of being accepted

When making the difficult decision about which students to accept, we look for:

  • Clear and detailed application explaining how you think the project could be done

  • Relevant prior experience

  • Experience contributing to ArduPilot or other open source projects

  • Understanding of Git and/or GitHub

Visual Follow-me using AI

  • Skills required: Python, Yolo, C++

  • Mentor: Randy Mackay

  • Expected Size: 175h or 350h

  • Level of Difficulty: Medium

  • Expected Outcome: Copter or Rover follows a user while also keeping the camera mount pointed at them

There are two steps to this project

Step #1 is to add Visual Follow-me support for all ArduPilot camera gimbals:

  • Users will start “image tracking” using the existing Image Tracking auxiliary function or by sending a DO_TRIGGER_CONTROL command from a ground station (no GCSs support sending this yet)

  • ArduPilot’s GCS_MAVLink and AP_Mount libraries will be enhanced to forward this command onto the companion computer (e.g. NVidia Nano, RPI5, etc)

  • The companion computer will run a new Python program using Yolov8 (or similar) to recognise objects (e.g. people) and then send mavlink gimbal commands to keep the gimbal pointed at the object

  • The Python program could first be written as a MAVProxy module before being migrated to a stand-alone program

Step #2 is to allow the vehicle to follow the object

An important output of the project is to document the setup for future developers and users.

Some of the development can be completed using the SITL simulator but funding will also be provided for an RC car frame, autopilot and companion computer (e.g. NVidia Nano, RPI5, etc) if required.

MAVProxy AI Chat Enhancements

  • Skills required: Python, AI

  • Mentor: Randy Mackay

  • Expected Size: 175h

  • Level of Difficulty: Medium

  • Expected Outcome: The MAVProxy chat module can better control Copters, Planes and Rovers including creating new missions

This project involves numerous small enhancements and bug fixes to MAVProxy’s AI chat module (see blog here) including:

  • Arming and control of Planes

  • Arming and control of Rovers and Boats

  • Camera gimbal controls (point gimbal, take pictures, record video)

  • Create simple missions

  • Improve reliability of existing functions

A stretch goal is to replace the use of OpenAI with a locally installed, open source LLM.

Most of the development can be completed using the SITL simulator and any OpenAI usage costs will be covered. Funding for an autopilot and frame will be provided if required.

WebTools automated log analysis

  • Skills required: HTML, JavaScript

  • Mentor: Peter Hall

  • Expected Size: 175h to 350h

  • Level of Difficulty: Medium

  • Expected Outcome: A new WebTool with the ability to automatically highlight and diagnose common issues from flight logs.

ArduPilot has several WebTools for log review, these run in any browser with all computation on the client side. So far we have tools for setup tasks (FilterReivew, PIDReview, MAGFit) and a tool that focuses on hardware issues (HarwareReport). The next evolution is a tool to look for in-flight issues. There are two existing automated log review tools. MissionPlanner includes a basic analysis tool. Dronekit log analyzer has a larger number of checks (see: analyzers) and would be the initial benchmark for this project. Once a framework for the tool is up and running checks for as many issues as possible can be added, the tool should focus on making the checks easy to add and update rather than a fancy-looking interface.

Improvements to the Custom Build Server

  • Skills required: Python, Flask, Javascript, Docker

  • Mentor: Shiv Tyagi, Peter Barker

  • Expected Size: 175h to 350h

  • Level of Difficulty: Medium

  • Expected Outcome: Enhanced custom build server with automated build size estimation and operational/security improvements

The custom build server stands as a valuable utility, empowering users to tailor their software builds by selectively enabling or disabling features deemed less crucial for their specific requirements, thereby conserving flash memory on flight controllers. Originally developed as part of the Google Summer of Code program in 2020, this application has demonstrated its effectiveness in enhancing flexibility and resource management. However, there remains room for improvement to further elevate its usability and broaden its appeal, ensuring it meets the diverse needs of an expanding user base.

Some of the problems we observe in the custom build server are as follows:

  • Build failures occur due to the excessive selection of features that cannot fit into the memory of the intended board.

  • Application can become unresponsive due to unexpected exceptions during the build step or any other step in the process.

  • The manual addition of branches is required every time a release is made at

  • The testing environment is inadequate. There is no easy way for a developer to test feature additions and deletions.

Some possible improvements to address these issues can be:

  • Come up with a mathematical algorithm to estimate the approximate size of each feature on a branch. This can be achieved by leveraging the script to measure the size of the binary when each feature is sequentially enabled and disabled. An algorithm should be developed to estimate the size of individual features while accounting for their dependencies. Remember, when a feature is enabled, it also activates any dependent features.

  • Implement containerisation for running the application. By containerising the application, it can also be divided into multiple services, such as the main application and micro-services responsible for tasks such as reporting the status of server builds. Containerization not only enhances application security but also facilitates scalability and ease of deployment.

  • Develop a service responsible for monitoring the GitHub repository ( or for new releases. This service can automatically add relevant entries to the main application, enabling it to serve customised builds for newly released branches. This automation streamlines the process of integrating new releases into the build server.

  • Enhance the build server to support builds from any repository, not just the upstream repository. While implementing this feature, careful consideration must be given to potential complexities and challenges associated with supporting builds from multiple repositories.

Some github issues having feature requests for Custom Build Server:

Remember, these are just suggestions. The contributors can use the application at, read the source code here and suggest any other improvement which they would like to see in the app.

High Altitude Non-GPS Position Estimation

  • Skills required: Python, C++

  • Mentor: Randy Mackay

  • Expected Size: 175h or 350h

  • Level of Difficulty: Hard

  • Expected Outcome: Copter can maintain position at high altitudes without a GPS

ArduPilot copter supports numerous methods of Non-GPS navigation but most are designed for indoor use and do not work at altitudes above about 40m meaning that in practice they are not useful to protect against loss of GPS.

This project aims to allow Copters to maintain an adequate position estimate at altitudes of at least 100m using downward facing camera (in a gimbal).

  • A set of base images will be captured with known Locations (latitude, longitude, altitude, altitude above terrain). These might be taken by the vehicle itself while GPS is operating normally or they could be satellite images of the area

  • A companion computer (e.g. RPI or NVidia Nano) will capture images from a downward facing camera and compare them to the base images to calculate a new latitude, longitude and altitude. Lag is important as the EKF may struggle if the estimates are over 0.25 seconds old.

  • This estimated Location should then be sent to the autopilot using one of these supported mavlink messages

  • Some EKF tuning will likely be required to allow the EKF to expect very noisy position estimates

  • If time permits a GPS/Non-GPS transition Lua script (like this one) could be developed

An important output of the project is to document the setup for future developers and users.

Most of the development can probably be done using SITL, Gazebo and/or Realflight but funding will also be provided for a multicopter frame and camera gimbal if required.

Improve Web Server for file and parameter management

In ArduPilot 4.5.x we have networking support and a web server builtin and we expect quite a few aicraft to use this in the future.

We would like the web server to be extended to allow for:

  • file management, with upload and download of files

  • parameter management, with a nice UI for displaying and editing parameters

the GSoC student for this project would need good JavaScript and HTML skills to create a nice user interface. They would also need to know some lua, although most of the code would be in JavaScript.

Projects Completed in past years

In 2023, students completed the following projects:

In 2022, students worked on these projects:

In 2019, students successfully completed these projects:

  • AirSim Simulator Support for ArduPilot SITL

  • Development of Autonomous Autorotations for Traditional Helicopters

  • Further Development of Rover Sailboat Support

  • Integration of ArduPilot and VIO tracking camera for GPS-less localization and navigation

  • MAVProxy GUI and module development

In 2018, students successfully completed these projects:

  • BalanceBot

  • RedTail integration with ArduPilot

  • Live video improvements for APSync

In 2017, 3 students successfully completed these projects:

  • Smart Return-To-Launch which involves storing the vehicle’s current location and maintaining the shortest possible safe path back home

  • Rework ArduRover architecture to allow more configurations and rover type (see details here)

  • Add “sensor head” operation of ArduPilot, split between two CPUs

You can find their proposals and works on the Google GSoC 2017 archive page