-
Notifications
You must be signed in to change notification settings - Fork 286
GSoC_2019
Fabien Spindler edited this page Feb 6, 2019
·
11 revisions
- GSoC 2019 site
- Timelines:
- Important dates:
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 |
- ViSP Developers Site
- ViSP User’s Site
- Source Code can be found at GitHub
- To get the source code, point your git client to git://github.com/lagadic/visp.git
git clone git://github.com/lagadic/visp.git
- To get user contributions go to: https://github.com/lagadic/visp_contrib
git clone git://github.com/lagadic/visp_contrib.git
Future GSoC developments will also be available as contributions. - Here are the instructions to build visp and visp_contrib together. There is also the tutorial.
- To get the source code, point your git client to git://github.com/lagadic/visp.git
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
- A full pull request
- For software development skills, please refer to the project description
- Take your time to learn about ViSP, watching some YouTube videos, reading tutorials, downloading it and launching tutorials or example.
- Ask to join the ViSP GSoC 2019 Forum List
- Discuss projects below or other ideas with us between now and April 9
- 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
- Between end of March and April 9, go to the GSoC site and sign up to be a student with ViSP
- 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
- 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).
List of potential mentors (pairing of projects to mentors will be done when Google decides the number of slots assigned to ViSP):
-
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.
-
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:
- If during the getting started existing documentation, examples or tutorials were not clear enough, propose a PR to improve them
- 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 beobject-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 inobject-face1.cao
file. A parent .cao file is also exported and includesobject-face1.cao
.
-
Knowledge prerequisites: C++, Python, Qt, Blender
-
Difficulty level: Middle