Skip to content

GSoC_2019

Fabien Spindler edited this page Feb 6, 2019 · 11 revisions

Project page for ViSP Google Summer of Code 2019 (GSoC 2019)

General Information

Date Main events
February 6 Mentoring organization application deadline
February 26 List of accepted mentoring organizations published
March 25 Student application period opens
Mai 6 Accepted student proposals announced
May 27 Coding officially begins
Work Period Students work on their project with guidance from Mentors
June 24 Mentors and students can begin submitting Phase 1 evaluations
June 28 Phase 1 Evaluation deadline
Work Period Students work on their project with guidance from Mentors
July 22 Mentors and students can begin submitting Phase 2 evaluations
July 26 Phase 2 Evaluation deadline
Work Period Students continue working on their project with guidance from Mentors
August 19 Final week: students submit their final work product and their final mentor evaluation
August 26 Mentors submit final student evaluations
September 3 Final results of Google Summer of Code 2019 announced

Resources

How you will be evaluated if you are an accepted student

Student projects to be paid only if:

  • 1st phase (May 27 - June 24, 2019): The student submits a pull request that...
    • Builds, works with build bot (travis-ci)
    • Has, at least, stubbed out new functionality
  • 2nd phase (June 28 - July 22, 2019): The student submits a pull request with...
    • Same as above, plus:
    • Code has appropriate Doxygen documentation
    • Has a stubbed out example/tutorial that builds/runs without errors
    • It observes the recommendations in "How to contribute", which include C++ style suggestions.
  • Final phase (July 26 - August 26, 2018):
    • A full pull request
      • Fulfilling all required objectives described in the corresponding project
      • Full Doxygen documentation
      • A tutorial if appropriate
      • A working example or demo
    • Create a video (e.g. on YouTube) that demonstrates your results

For students interested in applying

  1. For software development skills, please refer to the project description
  2. Take your time to learn about ViSP, watching some YouTube videos, reading tutorials, downloading it and launching tutorials or example.
  3. Ask to join the ViSP GSoC 2019 Forum List
    • Discuss projects below or other ideas with us between now and April 9
  4. ViSP team propose a set of enhancements that correspond to small projects that students can contribute to. Contributing to ViSP through these small projects is a good way for mentors to evaluate the student skills and motivation
  5. Between end of March and April 9, go to the GSoC site and sign up to be a student with ViSP
  6. Post the title of the project (from the list below or a new one if we have agreed) on the mailing list [email protected]
    • Include name, email, age
    • Include how you think you are qualified to accomplish this project (skills, courses, relevant background)
    • Include country of origin, school you are enrolled in, Professor you work with (if any)
    • Include a projected timeline and milestones for the project
    • Precise which 3rd party libraries you plan to use
  7. If ViSP gets accepted as GSoC organisation this year and you’ve signed up for a project with us in Mai
    • We will dispatch the students and projects to the appropriate mentors
    • Accepted students will be posted on the GSoC site in May (and we will also notify the accepted students ourselves).

2019 project ideas

List of potential mentors (pairing of projects to mentors will be done when Google decides the number of slots assigned to ViSP):

Project #1: Porting ViSP to Android devices

  • Brief description:

    • ViSP is already packaged for iOS. Community is asking a version for Android
    • Last year GSoC 2017 allow us to start porting ViSP to android.
    • The objective of this project is to continue porting ViSP to Android in order to propose to the community a more complete SDK for Android and new tutorials for beginners.
  • Getting started: Since ViSP architecture is very similar to the one adopted by OpenCV, student interested by this project could

    • Follow all the tutorials proposed by OpenCV in order to become familiar with Android and the tools
    • Understand how OpenCV Android SDK is build from the source code using an Android toolchain
    • Understand and identify which part of ViSP was ported to Android reading the dedicated GSoC 2018 wiki page
    • Follow ViSP for java tutorial
    • Follow ViSP for Andoid tutorial
  • Expected results:

    • To develop...
  • Application instructions: Student should precise which device is used for the development and which Android version it is running.

  • Knowledge prerequisites: C++, Android studio, Android NDK

  • Difficulty level: High since ViSP developpers are not familiar with Android development yet.

Project #2: Extend markerless model-based tracker CAD model editing tools

  • Brief description:

    • The markerless model-based tracker (see tutorial) uses our home-made CAD model file format (.cao) to describe the object to track (see examples). Only simple primitives, which correspond to object visible contours, can be tracked (lines, circles, cylinders). Currently, this means that the creation of this home-made file has to be made by hand. This is a big drawback as most of the time the 3D model of the object to track comes from a CAD software, modeled by complex meshes (.obj, .stl).
    • In GSoC 2017 we were able to develop minimalistic Blender plugins to edit and convert from classical 3D file format (for example .obj) to our home-made CAD model file format. We designed also a very simple CAD model viewer based on Qt.
    • The goal of this project is to extend the capabilities of the Blender plugins and of the Qt CAD model viewer
  • Getting started:

    • Start with Markerless generic model-based tracking using a color camera tutorial. Read and understand the tutorial.
    • Calibrate your camera following this tutorial.
    • Then find a simple object (typically a box) that you want to track. Create all the setting files corresponding to your object; create the corresponding CAD model <object>.cao file that should be similar to our teabox.cao, create a <object>.init file similar to teabox.init, create <object>.xml that should be a copy of teabox.xml and update inside this file the values of the camera parameters that you got during calibration. Then run the tracker using tutorial-mb-generic-tracker-live.cpp
    • In http://visp-doc.inria.fr/download/mbt-model/ we provide the material (.obj, .cao, .xml, .init) and videos to test the tracker on CubeSAT satellite or mmicro object (see model-based tracker use-case). You have also your <object>.cao file that could be used for testing.
    • Continue with Markerless model-based tracker CAD model editor - GSoC 2017 project tutorial and understand what was done by the student. You have also your .cao file for testing.
    • Concentrate first on the Blender plugins to import/edit/export .cao files and understand the python code that is behind
    • Then continue with the Qt CAO viewer app to import/edit/export .cao files.
    • Modify <object.cao> to create a hierarchical .cao model where <object>.cao includes <object-face1>.cao up to <object-face6>.cao to model in separate files a face of the object.
  • Expected results:

    • General
    • If during the getting started existing ViSP documentation, examples or tutorials were not clear enough, propose a PR to https://github.com/lagadic/visp to improve them.
    • The student working on this project has to fork https://github.com/lagadic/visp_cao_editor and propose a PR once a new feature is implemented. In the same time the wiki page should also be updated with new or updated tutorials
    • Concerning Blender plugins, modify the importer code to be able to read a hierarchical .cao CAD model. Each face of your hierarchical <object> is imported with a name that corresponds to the name of the file (ie for face 1, the name would be object-face1).
    • Modify the code to be able to export a hierarchical .cao CAD model. Each face that has a name is exported in a hierarchical file. For example, a face with name object-face1 is exported in object-face1.cao file. A parent .cao file is also exported and includes object-face1.cao.
    • Concerning the Qt cao viewer, introduce first a CMakeLists.txt file that allows to build qt-cao-editor. Create a tutorial to explain how to build the Qt viewer.
    • Finish remaining tasks mentioned in PR#23.
    • Modify the code to be able to read a hierarchical .cao CAD model. Each face of your hierarchical <object> is imported with a name that corresponds to the name of the file (ie for face 1, the name would be object-face1).
    • Modify the code to be able to save a hierarchical .cao CAD model. Each face that has a name is exported in a hierarchical file. For example, a face with name object-face1 is exported in object-face1.cao file. A parent .cao file is also exported and includes object-face1.cao.
  • Knowledge prerequisites: C++, Python, Qt, Blender

  • Difficulty level: Middle