-
Notifications
You must be signed in to change notification settings - Fork 632
Ideas page for MRPT Google Summer of Code 2018
Table of contents
- 1. Important information for Students
- 2. Students interested in applying
- 3. Ideas list for this year GSoC
- GSoC website. It is fundamental to read all rules and documents from Google before writing a proposal.
- GSoC mailing list: You can ask general questions here.
- GSoC timeline
- TBD: Students can apply in this period only!
Being accepted as a GSoC student is a quite competitive process. Please, if you wish to submit a proposal, consider becoming familiar with the involved technologies first. Simply copying and pasting from this page will not be accepted.
Student projects will be paid only if:
- 1st phase (June 11-15): A pull request is requested that...
- Builds, ideally in travis-ci
- Has, at least, stubbed out new functionality
- 2nd phase (July 9-13): A pull request is requested that...
- Same as above, plus:
- Code has appropriate Doxygen documentation
- Has a stubbed out example/tutorial/ROS launch file that builds/runs without errors
- It observes the recommendations in "How to contribute", which include C++ style suggestions.
- Final phase (August 6-14):
- A complete pull request that builds, full Doxygen documentation, unit test if applicable, complete functionality.
- A video (e.g. on YouTube) demonstrating your code.
- You must already be proficient in the main language of the corresponding project (C++, JavaScript, ...).
- Take your time to learn about MRPT. Try watching some YouTube videos, reading tutorials, downloading it and launching demo applications, for example. Getting familiar with ROS and MRPT ROS packages would be a plus.
- Take a look at the projects in the "GSoC ideas page". Discuss those of your interest, or your own ideas, in the MRPT forum/mailing list.
- Read carefully about Google's student eligibility rules.
- Sign up in GSoC and post your project proposal to the MRPT Organization. Your proposal should include:
- A coding portfolio of past/current projects.
- Your GitHub/GitLab/... username.
- A detailed description of your project proposal, including initial plans for research directions and a list of key and optional features to be coded as time permits.
- Will you be working full-time on the project during the summer? Will you have other commitments too (a second job, classes, etc)?
- Why do you feel motivated to undertake this particular project? :-)
Rules say that all communications between students and mentors should happen in public: please, use the MRPT mailing list or GitHub comments in pull-requests or commits whenever possible, before and during GSoC.
Update: We have created a slack channel for answering questions and providing feedback during the GSoC period. You can sign up using https://mrpt-gsoc.herokuapp.com/
MRPT provides developers with portable and well-tested applications and C++ libraries covering data structures and algorithms employed in common robotics research areas. ROS (Robot Operating System), supported by the OSRF, 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.
List of potential mentors (pairing of projects to mentors will be done when Google decides the number of slots assigned to MRPT):
- Jose Luis Blanco (@jlblancoc)
- Hunter Laux (@jolting)
- Javier G. Monroy (@JGMonroy)
- Jesus Briales (@jbriales)
- Eduardo Fernandez-Moral (@EduFdez)
- Francisco Ángel Moreno-Dueñas (@famoreno)
- Nikos Koukis (@bergercookie)
- Panagiotis Vlantis (@maxchaos)
-
Brief description: Robots are quickly becoming part of the Internet of Things. Naturally, a web-based UI is ideal for an Internet connected robot. The additional mrpt-web library will be developed as a separate library to compliment the current mrpt-2.0 libraries. It will provide additional functionality for sending MRPT data-structures between the c++ and html5. Boost has recently released beast, which implements http(s) and websockets. The library must utilize boost beast without exposing too many details of boost to the rest of mrpt. Additionally there must include a front-end web application written in VueJS capable of visualizing 3D data in real time over a websocket. It is highly recommended that you use VueJS for your web development and use the example as a starting point. Bonus: Make it capable of driving around and controlling a real robot.
-
Expected results:, At least two applications. The applications may be web-based clones similar to a current wxwidget applications. At least one application must be able to render robot poses, observations and maps in 3D using real-time data.
-
Knowledge prerequisites: C++, WebSockets, REST, MVC, JavaScript(e.g. VueJS, socket.io), WebGL
-
Difficulty level: Middle
-
Brief description: MRPT offers C++ classes under
mrpt::gui
for easily prototyping command-line apps capable of 2D and 3D rendering, without having to worry about message loops, multithreading, etc. All this runs behind scenes. At present, MRPT classes built upon wxWidgets GUI components. However, there exist other nice Qt alternatives, especially for 2D plots, so porting the code to Qt would be a great improvement.- See also: https://github.com/MRPT/mrpt/issues/107
-
Expected results:
mrpt::gui
should build with wxWidgets or Qt, and the user API should be unaffected by the underlying GUI library. All existing examples and apps should compile with the new Qt GUI and run without problems. - Knowledge prerequisites: C++, Qt.
- Difficulty level: Easy
-
Brief description: Using a combination of several sensors in a robotic platform is a common approach to obtain relevant information of the robot environment. This information is put into a common frame of reference by means of the extrinsic calibration of the sensor system, i.e. the relative 3D poses of the different sensors. An well known example is the construction of panoramic images from a set of images with overlapping field of views. The objective of this project is to build a GUI application to estimate the extrinsic calibration of different types of visual and range sensor systems from their observation of a generic scene. In order to obtain the extrinsic calibration, a cost function is usually minimized depending on geometric restrictions using scene features (like points, lines and/or planes) Perez-Yus et al.; or sensor ego-motion, where the motion of each sensor is estimated independently and their trajectories are matched to obtain the extrinsic calibration, as described in the papers by Brookshire and Teller and Taylor and Nieto.
-
Expected results: The student taking this project is expected to integrate several algorithms described in research papers including methods based on geometric restrictions and ego-motion, and develop a GUI application that allows the user to compare and/or combine different techniques. The GUI application must open a rawlog file containing a sequence of observations from several sensors (e.g.: a set of range cameras, a set of 2D range sensors (LiDARs), or a RGB and a range camera). The student will have to implement (or re-implement) methods for feature extraction and matching (like e.g. Bermudez-Cameo et al. already implemented in Matlab) and for pose estimation. The uncertainty of the sensor models and observations must be taken into account to compute the calibration. The app must show 2D and 3D reconstructions of the scene using the computed calibration (when possible). The app must also allow the user to switch the calibration method, when several calibration methods can be applied to a particular sensor system, to compare visually their results.
-
Knowledge prerequisites: C++, OpenCV, GUI design (Qt or wxWidgets), and optionally geometry libraries like PCL or CGAL
-
Difficulty level: High
Project #4: Add gtsam as an external dependency to MRPT
- Brief description:
Georgia Tech Smoothing and Mapping (gtsam) is a library of C++ classes that implement smoothing and mapping (SAM) in robotics and vision, using factor graphs and Bayes networks as the underlying computing paradigm rather than sparse matrices.
gtsam ofers quite a sophisticated list of algorithms on factor-graph optimization which should be quite useful in MRPT.
-
Expected results: A student taking up this project is expected to work on the following:
- CMake-configure gtsam as an optional, external dependency for MRPT
- Implement the appropriate conversion methods MRPT <-> gtsam types (poses, edges/constraints, graphs etc.)
- Wrap existing gtsam optimizers as a GSO class to be used in the existing graphslam-engine MRPT application. gtsam offers a wide variety of optimizers / frameworks to use (iSAM, iSAM2, Dogleg, GaussNewton, ConjugateGradient etc.)
- Add detailed instructions, doxygen documentation on how a user can setup gtsam
- Write the necessary unittests where applicable (see GTest)
It is important that gtsam is introduced as a generic tool in MRPT that can easily and intuitively be used as an optimization framework in later works. The student taking up this project should have this in mind and offer sane APIs and develop code that is maximally reusable.
-
Relevant material:
- Chapter 3.2 of this document
- graphslam-engine app
- mrpt_graphslam_2d ROS wrapper
- graphslam-engine demo
- graphslam-engine in multi-robot SLAM
- Discussion on integration of 3rd party optimization framework
-
Knowledge prerequisites: CMake, C++, git, SLAM, graph-based SLAM
-
Difficulty level: Medium
- Brief description: Port a set of existing MRPT navigation/SLAM algorithms to the V-REP simulator.
V-REP is a simulation framework for robotic applications offering simulation capabilities for a wide variety of sensors and robotics platforms. There are multiple ways of extending the simulator capabilities via either embedded scripts
, plugins
, or its remote API
. The method to be used is up to the student to decide. We'll refer to the final result (either if it's a plugin, its remote API etc.) as the extension
. The extension should not depend on the ROS wrappers of MRPT and should be able to run independent of that (direct communication MRPT<->V-REP
The objective of this project is to use one of these options to port the functionalities of existing MRPT algorithms to be used in V-REP. Student may also make use of the already implemented ROS wrappers for MRPT (e.g., mrpt-slam or mrpt-navigation)
-
Expected results:
- V-REP extensions for at least 2 different mrpt algorithms (e.g., icp-slam, graphslam)
- Detailed instructions on porting an MRPT algorithm to V-REP.
- Continuous-Integration script with either Travis CI or Jenkins that verifies the successful compilation/running of the extension.
- Write the necessary unittests where applicable (see GTest)
-
Notes:
- Students interested in this should reason about the strategy that is to be followed for communicating with V-REP, i.e., it should not be picked at random.
- Take your time to familiarize with V-REP and other projects that extend its capabilities. Make a plan with explicit deadlines on what algorithms/features are to be ported and how.
-
Relevant links:
-
Knowledge prerequisites: CMake, C++, V-REP, ROS (Optional)
-
Difficulty level: Medium
- Brief description: XXX
- Expected results: XXX
- Knowledge prerequisites: XXX
- Difficulty level: XXX