-
Notifications
You must be signed in to change notification settings - Fork 632
Ideas page for MRPT Google Summer of Code 2016
Table of contents
- GSoC2016 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 2016 timeline
- 29th Feb 2016: MRPT got accepted as a GSOC 2016 organization!
- 14th to 25th Mar 2016: 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:
- Midterm (20-27 June 2016): A pull request is requested that...
- Builds, ideally in travis-ci
- Has, at least, stubbed out new functionality
- 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.
- End of summer (23-29 August 2016):
- 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 C++.
- 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 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.
- 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.
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.
At present (Feb-2016), only a minimal part of MRPT functionality is available to ROS users, hence that many of the project ideas are aimed at developing MRPT-powered ROS packages.
List of potential mentors:
- Jose Luis Blanco (jlblancoc)
- Javier G. Monroy (JGMonroy)
- Jesus Briales (jesusbriales)
- Eduardo Fernandez-Moral (EduFdez)
-
Brief description: Design a set of "QR code-like" bidimensional markers suitable for recognition from several meters away, write (or integrate existing? AprilTags?) C++ code to detect and unequivocally identify them by some unique ID numbers in stereo images. A set of non-aligned points (a bidi array of corners?) must be detected with (sub)pixel accuracy to enable the optimization algorithm to converge to a non-degenerate solution. With all these, you can write code for automatically reconstruct the 3D pose (SE3) of all markers and the exact trajectory of the camera. This is called Bundle Adjustment or SLAM, and consists in solving an optimization problem, most of its pieces already implemented in MRPT. Also, once a map of markers is generated, one can run the optimization for the camera poses only, allowing accurate and robust localization, with applications to autonomous vehicle navigation, augmented reality, etc.
-
Expected results:
-
A new C++ class in
mrpt-detectors
for QR-like markers detection. When finished, its integration into OpenCV will be considered. -
Generic new C++ classes in
mrpt-slam
for SLAM and localization with visual markers. -
A working application capable of running the new methods on live or offline stereo visual datasets.
-
The method must work for professional stereo cameras (e.g. Bumblebee2). The organization will provide the student with stereo images of the markers designed by him/her.
-
The method may optionally also work with a pair of consumer-grade webcams, in the case the student wants to print his/her own markers for testing at home.
-
Knowledge prerequisites: C++, computer vision, OpenCV, numerical optimization.
-
Difficulty level: Middle
-
Brief description: Use ROS pluginlib to integrate MRPT TP-Space reactive navigation for autonomous vehicles/robots as a local_planner in
move_base
. Further reading:- http://wiki.ros.org/move_base
- http://www.mrpt.org/Obstacle_avoidance
- There exists at present an independent ROS node for MRPT reactive navigation, mrpt_reactivenav2d, but it is not integrated into
move_base
- Expected results: Being able to launch a navigation command in ROS' RViz so it is firstly processed by existing ROS global planners and the path followed locally by MRPT methods. Writing a good tutorial on ROS Wiki about the process would be also a great outcome.
- Knowledge prerequisites: C++, GNU/Linux, vehicle kinematics.
- Difficulty level: Middle.
Useful for features-based mapping and localization: LIDAR-based corners, visual features from stereo images, etc.
- Brief description: MRPT features C++ classes, a command-line application and a GUI application implementing localization and SLAM for mobile robots (or hand-held cameras/sensors) and features-based maps. Nothing of which is exposed in ROS, and to the best of our knowledge, there exist no other ROS nodes exposing such sensor-agnostic, generic algorithms.
- Expected results: ROS messages and nodes for 2D/3D SLAM and localization. Perhaps different ROS nodes will have to be written for each type of problem. Tutorial and/or demo based on simulator data. Optionally, use real data from LIDAR corner detectors, feature points from stereo camera, etc. to show the algorithm working in real-world conditions.
- Knowledge prerequisites: C++, GNU/Linux.
- Difficulty level: Middle.
-
Brief description: MRPT features RBPF-SLAM with different kinds of map models and sensors. This project consists in creating ROS nodes for some practical cases:
- LIDARs + occupancy grid maps.
- Range-only sensors + beacon maps.
-
Expected results: Working ROS node(s) for, at least:
- SLAM with LIDAR and 2D grid maps / point clouds (user-selectable)
- SLAM with range-only sensors (new ROS messages may have to be defined)
- Localization with range-only / RFID sensors and odometry. All those nodes must be proven to work with simulated data and, where possible, real datasets.
- Knowledge prerequisites: C++, GNU/Linux.
- Difficulty level: Middle / Middle-high.
-
Brief description: Many datasets are available in MRPT Rawlog format or can be imported to it (e.g. Carmen logs). ROS log format (rosbag) is incompatible, so run-time or off-line conversion tools are required if Rawlog datasets want to be used in a ROS application.
- mrpt_rawlog ROS wiki page of existing packages. Very limited set of sensors are implemented at present.
-
Expected results: Being able to view all/most sensory data from a complex Rawlog dataset, e.g. Málaga Urban Dataset, in ROS RViz. It may be done via run-time on-the-fly conversion (easier) or by a new command-line tool capable of converting among
rawlog
androsbag
formats (harder). - Knowledge prerequisites: C++, GNU/Linux.
- Difficulty level: Low / Middle-Low.
-
Brief description:
- During 2005-2008 there existed a complex GUI application with this purpose called
SimpleMapsViewer
, but it was Windows-only (written in Borland C++ Builder!) so it was dropped when MRPT became crossplatform. - It is strongly recommended to have a look at a working snapshot of the old app (from 2008!) to get an idea of the expected basic functionality: SimpleMapsViewer-MRPT-0.5.3-win32.zip Use: Extract the ZIP, execute
SimpleMapsViewer.exe
and load the example map filelocalization_demo.simplemap
. - At present, the only similar app in MRPT is observations2map, which allows generating metric map but without a GUI and without edit possibilities.
- During 2005-2008 there existed a complex GUI application with this purpose called
-
Expected results: A new GUI app should be able to load recent versions of MRPT simple maps as generated from ICP-SLAM or RBPF-SLAM. The app must allow inspecting the raw observations (at least, 2D LIDAR scans and monocular and stereo images) and generate one or more metric maps according to user-given parameters, e.g. 2D point clouds, 2D occupancy grid maps, a 3D octomap, etc.
-
Knowledge prerequisites: C++, GUI design (Qt or wxWidgets).
-
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:
nanoflann
is a children project from MRPT, born as a smaller and faster version of the widely-used (OpenCV, PCL) FLANN C++ library for kd-tree neighbor search.nanoflann
is especially efficient for finding nearest neighbors in 2D/3D point clouds, an operation at the heart of most ICP algorithms for robot SLAM and localization. A key feature missing fromnanoflann
is the ability to support dynamic point clouds: at present, adding just 1 point to a pointcloud of 1e6 points would force rebuilding the kd-tree index, a costly operation. The goal of this project would be, among other minor improvements, the introduction of two dynamic strategies: (a) rebuild threshold, and (b) the logarithm method. In theory, (b) is better, but both should be implemented and benchmarked, among them, and other kd-tree C++ libraries, so we could be an informed decision about which is the most efficient implementation we should use in MRPT and other robotics software. In the way,nanoflann
could be renamed something else, likelibkdt
or anything even more creative! -
Expected results: An improved version of
nanoflann
, capable of handling dynamic datasets efficiently. MRPT ICP, perhaps after modifications, should build against the new kd-tree code. The results of the above mentioned benchmark, along with run-time improvements of ICP runs over public datasets of 3D point clouds. - Knowledge prerequisites: C++, algorithms complexity analysis.
- Difficulty level: Middle.
- Brief description: The goal is writing a C++ class capable of processing a sequence of observations (odometry, LIDAR scans, images, etc.), decide how often to insert new keyframes (robot poses) in a graph-SLAM map, launch loop-closure detectors (based on ICP, gridmap matching, or visual clues) and optimize the global map. It should be capable of handling small and mid-sized SLAM problems, so it would become an invaluable tool for practical roboticists.
Resources: An attempt to create such an engine was already made in 2014 but it was abandoned. The branch was deleted but is still reachable here. Take a look at the files libs/graphslam/include/mrpt/graphslam/GraphSlamEngine.h
, libs/graphslam/include/mrpt/graphslam/deciders.h
, libs/graphslam/include/mrpt/graphslam/f2f_match_icp_2d.h
,... to get an idea of one possible implementation.
Start studing the "C++ code" section in http://www.mrpt.org/Graph-SLAM_maps
Ideally, the framework should use the current graph SLAM implementation in mrpt::graphslam
. Using g2o
may be acceptable as well, but it would introduce new dependencies into MRPT and might complicate building it under Windows, which is a problem for MRPT where we try to support both GNU/Linux and Windows.
-
Expected results: The code should be able to process some datasets with odometry and 2D LIDAR, starting with the simple short loop in
2006-01ENE-21-SENA_Telecom%20Faculty_one_loop_only.rawlog
but also with more complex ones like Kenmore dataset. - Knowledge prerequisites: C++, graphSLAM
- Difficulty level: Middle/High
- Brief description:
- Expected results:
- Knowledge prerequisites:
- Difficulty level: