search

MRPT / GSoC2016-discussions

See README for instructions
7 stars 2 forks source link

Design and developement of a full graph-based SLAM strategy in mrpt (By: bergercookie) #2

Closed jlblancoc closed 8 years ago

jlblancoc commented 8 years ago

Initial description The proposal at hand describes the working plan for developing a graph-based SLAM algorithm using the mrpt toolkit in the following summer. The suggested strategy builds upon the ideas developed by (Olson, 2009) for the data association and robust loop closing parts, while using already implemented schemes (mrpt version of Levenberg Marquardt, iSAM solver) for dealing with the optimization part. The result by the end of summer should be a fully functional, robust and usuable graph-based SLAM algorithm ready to be used by researchers and roboticists. We provide an overal timeline, with intermediate milestones to make sure that we meet the goals of the project. The proposal begins with an introduction to the graph-based formulation and lists already implemented and successful graphSLAM strategies. The following two sections (implementation details, timeline) describe the graphSLAM algorithm that we suggest. The final section provides with general information about the author and his background in simultaneous localization and mapping and open-source programming projects

Progress: All comments below reflect the interactions between the GSoC student and the mentor(s).

Final results:

jlblancoc commented 8 years ago

Student: Nick Koukis @bergercookie Mentor: @EduFdez Backup mentor: @jlblancoc

bergercookie commented 8 years ago

Hi @EduFdez, @jlblancoc,

Once again thanks for the opportunity of working together in this project.

In order to prepare myself for the upcoming coding part I was thinking of studying the uploaded book of yours on mrpt. Is this a good idea, or do you think I would be better off studying the online documentation?

EduFdez commented 8 years ago

Hi @bergercookie,

My name is Eduardo Fernandez-Moral (aka Edu) and I'll be your mentor in this project. I am a post-doc in Inria Sophia-Antipolis (France), though I'll be in sabbatical during the time of this GSoC. I work on localisation, mapping and SLAM for mobile robots. You can see some info about my work in my site: https://sites.google.com/site/efernandezmoral/

I am very excited about this project and this mentor experience, and I hope you'll learn and enjoy with it! :-)

EduFdez commented 8 years ago

About your question @bergercookie, have the mrpt book as reference but you don't need to study it. Besides I think the online documentation is more complete/updated than the book, isn't it @jlblancoc?

My advice for you to start is to download and compile MRPT, and then try to browse the different datasets available in http://www.mrpt.org/robotics_datasets with the RawlogViewer app. These datasets will give you an idea about the sensor types and data you may use later in your project for testing.

jlblancoc commented 8 years ago

Hi @bergercookie, you are welcome!

You could start with the mrpt-book, but it's fairly incomplete so you'll better continue after it with example code. I would recommend starting playing with the apps graph-slam, icp-slam and the graph-slam example.

bergercookie commented 8 years ago

Ok, got it. I have already downloaded and compiled mrpt on my system so in the next couple of days I wil try to familiarise myself with the the datasets and the applications specified. Thanks!

bergercookie commented 8 years ago

Hey @jlblancoc ,

This is not a development oriented question but I decided to post it in gh nonetheless.. I intend to change my "display name" in GSoC from bergercookie to "Nikos Koukis". I wanted to ask you first on this. Is there something else, other than email gsoc-support@google.com, needed?

Thanks,

jlblancoc commented 8 years ago

Sure, go on, no problem at all!

bergercookie commented 8 years ago

Ηι @jlblancoc @EduFdez

Sorry for not being so vocal the last couple of days. I have studied the proposed paper (https://april.eecs.umich.edu/pdfs/olson2009ras.pdf) once again and I have reviewed the basic tools for the project.

More specifically I:

I think I have understood a fair amount of the proposed, in the paper, strategy however there are some parts that still need revision. More specifically:

It would be really valuable if either one of you could take a look at the proposed paper so that we can discuss it e.g, in Skype during the week.

Thanks in advance, Nikos

On 25/04/16 16:27, Jose Luis Blanco-Claraco wrote:

Sure, go on, no problem at all!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-214327474

Nikos Koukis National Technical University of Athens School of Mechanical Engineering nickkouk@gmail.com +30 6985827375

jlblanco commented 8 years ago

Dear Sir,

I believe this email was not intended to me.

Sincerelly, J.L. Blanco-Murillo

2016-05-09 14:14 GMT+02:00 Nikos Koukis notifications@github.com:

Ηι @jlblanco @EduFdez

Sorry for not being so vocal the last couple of days. I have studied the proposed paper (https://april.eecs.umich.edu/pdfs/olson2009ras.pdf) once again and I have reviewed the basic tools for the project.

More specifically I:

  • Made a thorough introduction in CMake, Make, Doxygen and Git (which I was already fond of) to the point that I can confidently use them when needed.
  • Took a look into some of the important MRPT libraries such as graphslam, slam, system as well as the previous graphslam_engine implementation and the rawlog format.
  • Studied the relevant to the application parts of the mrpt book.

I think I have understood a fair amount of the proposed, in the paper, strategy however there are some parts that still need revision. More specifically:

  • How should I initially (before the search for loop closures) insert nodes in the graph? Do I use odometry or should I use ICP and align the measurements?
  • In the paper the Dijkstra projection algorithm is used to find the minimum uncertainty path between two nodes in the graph. Pseudocode for its implementation is provided in the paper so it would be fairly easy to implement it in mrpt. Should I try implementing this myself or is there a native mrpt method for computing this?

It would be really valuable if either one of you could take a look at the proposed paper so that we can discuss it e.g, in Skype during the week.

Thanks in advance, Nikos

On 25/04/16 16:27, Jose Luis Blanco-Claraco wrote:

Sure, go on, no problem at all!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-214327474

Nikos Koukis National Technical University of Athens School of Mechanical Engineering nickkouk@gmail.com +30 6985827375

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-217848007

EduFdez commented 8 years ago

Hi @bergercookie, @jlblancoc

I'm glad to hear from you :-)

Regarding the initialization of the nodes, you can assign a pose relative to a previous observation given by odometry, ICP, or any other method that allows you to have an estimate of the pose. The 1st pose in the graph is normally assigned to the origin of coordinates (zero translation rotation). Then you can add as many edges as you have when you have a relative pose between 2 nodes (whether it comes from loop closure or not, and you can have several edges for a pair of nodes). So, if you have two edges between a pair of nodes, one from odometry and another from ICP you should put both in the graph, and you can initialize the node with either of them. Imagine the nodes in 3D space as 3D points which are interconnected with nearby ones through springs (the edges), and the strength of each spring is given by the uncertainty of the relative pose. Then, the optimal position of the nodes in the graph corresponds to the minimum energy of the system, which can be solve with an optimizer like g2o.

My advice is that you start with a simple flow scheme (first in paper) to solve the graph-SLAM problem in 2D with measurements from 2D laser observations. You can then create a new example in your branch of MRPT and code it (this example should be latter an application in MRPT, but you can start with an example which I think will be easier to create). Do this in your own branch of MRPT, you can call it graph-SLAM or as you prefer.

We can talk through skype tomorrow and we could discuss these and other questions. I'll tell you my user and my availability through e-mail. I'm in Costa Rica during the coming weeks, but I guess we can have a conversation at reasonable hours :-)

Cheers, Eduardo

bergercookie commented 8 years ago

Great, thanks for the advice @EduFdez. I'll start thinking of a potential implementation of the algorithm

Until tomorrow then, :)

Cheers, Nikos

On 10/05/16 11:48, Eduardo Fernandez-Moral wrote:

Hi @bergercookie https://github.com/bergercookie, @jlblancoc https://github.com/jlblancoc

I'm glad to hear from you :-)

Regarding the initialization of the nodes, you can assign a pose relative to a previous observation given by odometry, ICP, or any other method that allows you to have an estimate of the pose. The 1st pose in the graph is normally assigned to the origin of coordinates (zero translation rotation). Then you can add as many edges as you have when you have a relative pose between 2 nodes (whether it comes from loop closure or not, and you can have several edges for a pair of nodes). So, if you have two edges between a pair of nodes, one from odometry and another from ICP you should put both in the graph, and you can initialize the node with either of them. Imagine the nodes in 3D space as 3D points which are interconnected with nearby ones through springs (the edges), and the strength of each spring is given by the uncertainty of the relative pose. Then, the optimal position of the nodes in the graph corresponds to the minimum energy of the system, which can be solve with an optimizer like g2o.

My advice is that you start with a simple flow scheme (first in paper) to solve the graph-SLAM problem in 2D with measurements from 2D laser observations. You can then create a new example in your branch of MRPT and code it (this example should be latter an application in MRPT, but you can start with an example which I think will be easier to create). Do this in your own branch of MRPT, you can call it graph-SLAM or as you prefer.

We can talk through skype tomorrow and we could discuss these and other questions. I'll tell you my user and my availability through e-mail. I'm in Costa Rica during the coming weeks, but I guess we can have a conversation at reasonable hours :-)

Cheers, Eduardo

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-218096069

Nikos Koukis National Technical University of Athens School of Mechanical Engineering nickkouk@gmail.com +30 6985827375

jlblancoc commented 8 years ago

Hi Nikos, @bergercookie

Good to hear you are making progress!

Some comments on your doubts:

Hope this helps keeping you "on track"! :-)

bergercookie commented 8 years ago

Hi @EduFdez, @jlblancoc

As was advised by @EduFdez over our Skype call the other day, I tried implementing a basic class that is able to parse a LaserScans file. The class builds an initial CNetworkOfPoses2D graph using the odometry information and by registering a new node (and corresponding constraint with the previous one) after some fixed distance or angle threshold has been exceeded. My implementation can be found here: https://github.com/bergercookie/mrpt/tree/master/graphslam-engine/ (Try running the program from inside the build folder so that it finds the .rawlog file successfully).

Along with the laserScans parsing method of the GraphSlamEngine_t class I also implemented the following:

I tried to closely follow the mrpt coding style ( https://github.com/MRPT/mrpt/blob/master/doc/MRPT_Coding_Style.md) as well as the Google C++ coding style as instructed in the latter link. Feedback on my programming is greatly appreciated!

Unless advised otherwise, the following days I will implement another method for matching nearby keyframes using the ICP algorithm as well as a visualization method so that we can validate that the overall approach does work.

With regards,

On 10 May 2016 at 13:30, Jose Luis Blanco-Claraco notifications@github.com wrote:

Hi Nikos, @bergercookie https://github.com/bergercookie

Good to hear you are making progress!

Some comments on your doubts:

-

Dijkstra projection is indeed the easiest way to find an estimation of uncertainty and the relative pose between two nodes. There is no need to implement it, since it's already into MRPT, please see:

Hope this helps keeping you "on track"! :-)

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-218119372

EduFdez commented 8 years ago

Hi @bergercookie It´s good to see your progress! I saw a bit your code, but I couldn´t see it in detail, compile it or test it. My laptop broke down 2 days ago (the motherboard fried) and using my cellphone for that is not practical at all. Hopefully I´ll get a new laptop next week. Some remarks:

Regards

bergercookie commented 8 years ago

Hey @EduFdez,

On 17/05/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie It´s good to see your progress! I saw a bit your code, but I couldn´t see it in detail, compile it or test it. My laptop broke down 2 days ago (the motherboard fried) and using my cellphone for that is not practical at all. Hopefully I´ll get a new laptop next week. Ouch, sorry about that..

Some remarks:

  • Try to have a look at the graph-slam app and other applications when arranging and deciding the architecture of your application.
  • Take into account that the code that you write will be modified along the GSoC to add flexibility to the application, and to operate with different kind of ensor/observations. This will come little by little. -And try to figure out the visualization of the graph so that you can have some feedback as soon as you´re implementing new things. Ok, I'll have a go in the vizualization part of it first and keep you updated on my progress. Just as a reference, what should I be targeting at? A GUI window that runs along the rawlog parsing algorithm and displays the robot trajectory while it moves as well as the registered keyframes and edges?

Regards

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-219877281

With regards,

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

jlblancoc commented 8 years ago

@bergercookie Just a quick note: You can inspire / reuse / copy part of this code for the visualization part.

As @EduFdez said, it's fundamental to get visual feedback of what's going on to detect possible errors as soon as possible.

@jlblanco Hola tocayo :-) I think you are still receiving updates from this thread because of the mistake while mentioning me... to stop receiving mails, please come back to this page and click on "Unsubscribe" button.

bergercookie commented 8 years ago

Hi @jlblancoc

On 18/05/16, Jose Luis Blanco-Claraco wrote:

@bergercookie Just a quick note: You can inspire / reuse / copy part of this code for the visualization part.

As @EduFdez said, it's fundamental to get visual feedback of what's going on to detect possible errors as soon as possible. Thanks for the advice! I 'll look into the specified file and see what I can get out of this!

@jlblanco Hola tocayo :-) I think you are still receiving updates from this thread because of the mistake while mentioning me... to stop receiving mails, please come back to this page and click on "Unsubscribe" button.

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-219963416

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

bergercookie commented 8 years ago

Hola mentors,

During the previous couple of days I added visualization capabilities to the module so that the user can inspect the graph building procedure. I simply used the graph_tools::graph_visualize method every time a node is added in the graph (it may be an overkill to redraw the whole graph every time a node is added but the visualization runs pretty smoothly nonetheless). It's still in an immature phase but I will be improving it in the following ways:

I also improved the fixed-intervals graph building procedure so that the edges include the uncertainty of the path between the relating nodes (previously I just used the node mean position difference as the edge).

Where should I go next? Since the first part is the adaptive node registration scheme, should I be searching the related SLAM literature on this? Is there any particular paper/method that you can suggest?

P.S. As advised by @EduFdez, I updated the timeline that I had provided in the initial proposal. The timeline can be found here: https://www.evernote.com/l/AMzIqsxnHG9P7ZYQ1C2FoyFuOUI0I9SXu7g

Thanks in advance, Nikos

On 18/05/16, Nikos Koukis wrote:

Hi @jlblancoc

On 18/05/16, Jose Luis Blanco-Claraco wrote:

@bergercookie Just a quick note: You can inspire / reuse / copy part of this code for the visualization part.

As @EduFdez said, it's fundamental to get visual feedback of what's going on to detect possible errors as soon as possible. Thanks for the advice! I 'll look into the specified file and see what I can get out of this!

@jlblanco Hola tocayo :-) I think you are still receiving updates from this thread because of the mistake while mentioning me... to stop receiving mails, please come back to this page and click on "Unsubscribe" button.

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-219963416

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

EduFdez commented 8 years ago

Hi Nikos, I would suggest you to try to optimize the graph now. Since you have measurements from odometry and laser scans (poses are estimated by ICP) you have already some small loops which are somehow accurate (redundant information). You can for example test runing the graph optimizer every time a new node is added, then you can transfer this calculation to a parallel thread (so that graph building and optimization are run in different threads). And you can also have a switch in your visualizer to show the graph optimized/unoptimized.

PS. I like the modifications you did to the timeline.

Cheers

bergercookie commented 8 years ago

Hi @EduFdez, @jlblancoc

During the previous week I worked towards adding ICP constraints in the graph-building procedure and finally close the loop and correct the trajectory of the robot. I also enhanced the overall visualization so that it contains:

All my changes can be accessed from my forked repository and an overview of each can be given by the corresponding commit message (@jesusbriales thanks for sharing the git-commit guidelines.. they are really helpful).

I tested the current code mostly with the 20060121-Teleco_Faculty_Malaga_laser_only.rawlog dataset as well as the kenmore dataset available at MRPT dataset repository. In both datasets it seems to be correcting the graph at loop closure events, given that the threshold goodness_to_accept an ICP alignment is set correctly (0.60 yields satisfactory results). A problem that needs fixing now is which nodes to check ICP against. I currently check against all other registered nodes which is inefficient and slows the procedure down after many nodes have been registered. I plan to change it so that it checks against nodes that are inside a certain radius of the current position only.

I would also like to ask of your opinions on the following matters:

As always, it would be really valuable if either could take a look at my code and provide suggestions / modifications that need to be done.

P.S. I have attached an image of the visualization window in case you don't have time to run it. graph_building_procedure

With regards,

On 21/05/16, Eduardo Fernandez-Moral wrote:

Hi Nikos, I would suggest you to try to optimize the graph now. Since you have measurements from odometry and laser scans (poses are estimated by ICP) you have already some small loops which are somehow accurate (redundant information). You can for example test runing the graph optimizer every time a new node is added, then you can transfer this calculation to a parallel thread (so that graph building and optimization are run in different threads). And you can also have a switch in your visualizer to show the graph optimized/ unoptimized.

PS. I like the modifications you did to the timeline.

Cheers

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

jlblancoc commented 8 years ago

Hi @bergercookie !

wow, I'm impressed how far have you reached in such short time, congratulations! :+1:

I was able to build and test your code without problems.

Just taking a high-level picture of your code, I have some recommendations (below, answers to your doubts):

On your doubts:

  • Is there a 2D rawlog file with ground truth data available. It would be really valuable so that I make sure that the algorithm works correctly. I searched on the MRPT dataset repository but to no avail

Nope... but you can generate your own, which I would strongly suggest you to debug loop closure errors, etc. Start with an almost null odometry error and try making it worst once the easy case works!.

See the tutorial: https://www.youtube.com/watch?v=ud9b3Z77Cbo

  • I studied the icp-slam app, where the CMetricMapBuillderICP class is used to build a map of the environment. Should I be targeting at building a map as well after having corrected the robot trajectory?

Not needed at this moment. Notice that, if you save at the end a CSimpleMap, there are other tools already capable of generating such global maps: http://www.mrpt.org/list-of-mrpt-apps/application-observations2map/

To visualize them in real time, one easy and cool solution would be to represent each keyframe with a mrpt::opengl::CSetOfObjects, then inserting a CSimplePointsMap (via getAs3DObject()) in which the LiDAR observations were previously inserted. Let me know if you need help understanding this part, I know it may be hard to follow!

  • How often should I be using the dijkstra_nodes_estimate() function? I currently use it every time I am about to test ICP against 2 nodes, so that I have an initial estimate of the distance between them

This is the hardest question!

For now, keep doing it, but we should think about the possibility of "caching" such Dijkstra trees so the cost doesn't grow as fast...

All in all... you're doing a very good job!! :+1:

bergercookie commented 8 years ago

Thanks @jlblancoc for the tips. They were quite explanatory. I shall modify my code accordingly to align with your suggestions.

With regards,

On 29/05/16, Jose Luis Blanco-Claraco wrote:

Hi @bergercookie !

wow, I'm impressed how far have you reached in such short time, congratulations! 👍

I was able to build and test your code without problems.

Just taking a high-level picture of your code, I have some recommendations (below, answers to your doubts):

• The cmd-line app: It may be useful to add an optional cmdline argument to select a dataset, overriding the one in the config files (as already done in some mrpt apps). In this way, the same config file can be quickly reused for many other datasets ;-)

• The structure of directories, etc: It's a good practice in Git (or any other VCS) not to commit any text or binary file which may be generated from sources. So, the build directory should be removed from your repo, even if you keep it in your local machine, of course.

• Not necessarily now, but in some moment, your code should be integrated along the rest of MRPT apps & libraries. I think this distribution would be OK:

  □ Reusable C++ classes => [MRPT]/libs/graphslam. Right now, that library
    is header-only (does not generate a .so). To change it, edit the
    define_mrpt_lib_header_only(...) declaration in [MRPT]/libs/graphslam/
    CMakeLists.txt after comparing it with another non-header-only lib
    (like mrpt-detectors; skipping the OpenCV stuff which you don't need).

• The cmd line app => [MRPT]/apps/. It's recommended (per Debian & Ubuntu standards) to use all lowercase letters to name libraries and executables (we kept some exceptions for backwards compatibility, but all new ones should comply).

• The map obtained from the Teleco_Faculty_Malaga_laser_only dataset is not correct yet (but it's impossible for you to know without knowing the actual place! :-) ). Here's a video of the correct map: https://www.youtube.com/ watch?v=i8lQdK6oRn0

On your doubts:

  □ Is there a 2D rawlog file with ground truth data available. It would be
    really valuable so that I make sure that the algorithm works correctly.
    I searched on the MRPT dataset repository but to no avail

Nope... but you can generate your own, which I would strongly suggest you to debug loop closure errors, etc. Start with an almost null odometry error and try making it worst once the easy case works!.

See the tutorial: https://www.youtube.com/watch?v=ud9b3Z77Cbo

  □ I studied the icp-slam app, where the CMetricMapBuillderICP class is
    used to build a map of the environment. Should I be targeting at
    building a map as well after having corrected the robot trajectory?

Not needed at this moment. Notice that, if you save at the end a CSimpleMap, there are other tools already capable of generating such global maps: http:// www.mrpt.org/list-of-mrpt-apps/application-observations2map/

To visualize them in real time, one easy and cool solution would be to represent each keyframe with a mrpt::opengl::CSetOfObjects, then inserting a CSimplePointsMap (via getAs3DObject()) in which the LiDAR observations were previously inserted. Let me know if you need help understanding this part, I know it may be hard to follow!

  □ How often should I be using the dijkstra_nodes_estimate() function? I
    currently use it every time I am about to test ICP against 2 nodes, so
    that I have an initial estimate of the distance between them

This is the hardest question!

For now, keep doing it, but we should think about the possibility of "caching" such Dijkstra trees so the cost doesn't grow as fast...

All in all... you're doing a very good job!! 👍

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

EduFdez commented 8 years ago

Hi @bergercookie

Congratulations on your progress!!!

I will just add a little comment to @jlblancoc 's answer:

How often should I be using the dijkstra_nodes_estimate() function? I currently use it every time I am about to test ICP against 2 nodes, so that I have an initial estimate of the distance between them

As Jose Luis said, you can keep computing Dijkstra for all the nodes, but in the future it would be useful to introduce the concept of sub-mapping on the graph-map, so that there is a global map which contains submaps, and you are all the time localized in a single submap as well, see the @jlblancoc 's paper Consistent Observation Grouping for Generating Metric-Topological Maps that Improves Robot Localization. Thus, when looking for "local edges" you may check ICP only in the current submap plus the one-connected submaps (i.e. neighbour submaps), or another option would be to check ICP in the one-connected (or two-connected) poses of the previous pose (i.e. poses that are not more separated by only 1 / 2 edges or less). This is just a simple heuristic to check for "local" edges.

But the interest of loop closures is to find those which are not in the local submap, and that's what Dijkstra's distance is for actually!!! That's where the concept of sub-mapping plays the game, you can just check Dijkstra with only one pose per submap (group of poses), and if the distance is close enough you can then check the rest of poses inside that submap. My advice is that you read the paper to keep the idea to apply in the future and you ask if something is unclear for you.

Also, the paper above will give you another interesting concept: the Sensed-Space-Overlap (SSO), that you can use to include a new edge in the graph instead of the 0.6 residual of ICP, which will give you a lot better results :-)

Keep enjoying :D

bergercookie commented 8 years ago

Hi @EduFdez,

I have read some papers on submaps usage and map partitioning in SLAM. I hadn't considered this option before for dealing with graph-based SLAM, it sounds interesting though. I am going to study the paper suggested and incorporate its ideas in the overall design.

With regards, Nikos

On 30/05/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

Congratulations on your progress!!!

I will just add a little comment to @jlblancoc 's answer:

How often should I be using the dijkstra_nodes_estimate() function? I
currently use it every time I am about to test ICP against 2 nodes, so that
I have an initial estimate of the distance between them

As Jose Luis said, you can keep computing Dijkstra for all the nodes, but in the future it would be useful to introduce the concept of sub-mapping on the graph-map, so that there is a global map which contains submaps, and you are all the time localized in a single submap as well, see the @jlblancoc 's paper Consistent Observation Grouping for Generating Metric-Topological Maps that Improves Robot Localization. Thus, when looking for "local edges" you may check ICP only in the current submap plus the one-connected submaps (i.e. neighbour submaps), or another option would be to check ICP in the one-connected (or two-connected) poses of the previous pose (i.e. poses that are not more separated by only 1 / 2 edges or less). This is just a simple heuristic to check for "local" edges.

But the interest of loop closures is to find those which are not in the local submap, and that's what Dijkstra's distance is for actually!!! That's where the concept of sub-mapping plays the game, you can just check Dijkstra with only one pose per submap (group of poses), and if the distance is close enough you can then check the rest of poses inside that submap. My advice is that you read the paper to keep the idea to apply in the future and you ask if something is unclear for you.

Also, the paper above will give you another interesting concept: the Sensed-Space-Overlap (SSO), that you can use to include a new edge in the graph instead of the 0.6 residual of ICP, which will give you a lot better results :-)

Keep enjoying :D

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

bergercookie commented 8 years ago

Hi @EduFdez, @jlblancoc,

I wanted to let you know that I have an exam to take on Tuesday in my university, for which I will have to take some time off to prepare towards the end of the week.

For the project at hand now, I converted the graphslam-engine (from a sample) to an application. I also tried using a debugger for that application (so that I can later test it in a more sane / automated way), however even after building mrpt from source with the CMAKE_BUILD_TYPE set to Debug, I couldn't include debugging symbols into the executable. How can this be done either for an application or for an independent sample?

I also reread the mrpt coding style guidelines and formatted my existing code to use tabs for indentation. I have currently set up Vim to replace two consecutive spaces to a tab. Is this the suggested way of coding?

Thanks in advance,

On 31/05/16, Nikos Koukis wrote:

Hi @EduFdez,

I have read some papers on submaps usage and map partitioning in SLAM. I hadn't considered this option before for dealing with graph-based SLAM, it sounds interesting though. I am going to study the paper suggested and incorporate its ideas in the overall design.

With regards, Nikos

On 30/05/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

Congratulations on your progress!!!

I will just add a little comment to @jlblancoc 's answer:

How often should I be using the dijkstra_nodes_estimate() function? I
currently use it every time I am about to test ICP against 2 nodes, so that
I have an initial estimate of the distance between them

As Jose Luis said, you can keep computing Dijkstra for all the nodes, but in the future it would be useful to introduce the concept of sub-mapping on the graph-map, so that there is a global map which contains submaps, and you are all the time localized in a single submap as well, see the @jlblancoc 's paper Consistent Observation Grouping for Generating Metric-Topological Maps that Improves Robot Localization. Thus, when looking for "local edges" you may check ICP only in the current submap plus the one-connected submaps (i.e. neighbour submaps), or another option would be to check ICP in the one-connected (or two-connected) poses of the previous pose (i.e. poses that are not more separated by only 1 / 2 edges or less). This is just a simple heuristic to check for "local" edges.

But the interest of loop closures is to find those which are not in the local submap, and that's what Dijkstra's distance is for actually!!! That's where the concept of sub-mapping plays the game, you can just check Dijkstra with only one pose per submap (group of poses), and if the distance is close enough you can then check the rest of poses inside that submap. My advice is that you read the paper to keep the idea to apply in the future and you ask if something is unclear for you.

Also, the paper above will give you another interesting concept: the Sensed-Space-Overlap (SSO), that you can use to include a new edge in the graph instead of the 0.6 residual of ICP, which will give you a lot better results :-)

Keep enjoying :D

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

EduFdez commented 8 years ago

Hi @bergercookie

No problem with your exam, you're developing at a very good pace.

To use debugging symbols, besides setting CMAKE_BUILD_TYPE to Debug, you will need the auxiliary libraries that you use in your application in debug mode. When you installed / compiled the prerequisite libraries for MRPT (see http://www.mrpt.org/Building_and_Installing_Instructions). You see that you installed many libraries ending by -dev (i.e. libxxx-dev), the debug version normally ends by -dbg (i.e. libxxx-dbg). Same for the auxiliary libraries that you may have compiled like OpenCV.

You're right about the coding style, the tab is used for indentation and it is represented as 4 blank spaces.

Cheers.

bergercookie commented 8 years ago

Hi @EduFdez, @jlblancoc

I took the university exam today, so from now on I will be concentrating solely on the project again. With regards to last week's progress I added the following capabilities to the application:

A more detailed view of the above can also be found here, (https://github.com/bergercookie/mrpt/commits/master)

@EduFdez, given that the period of the first evaluation is getting closer, it would be really valuable if we could host one more Skype call in one of the following days so that I can focus my attention and work towards the matters that matter most for the application.

With regards,

On 01/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

No problem with your exam, you're developing at a very good pace.

To use debugging symbols, besides setting CMAKE_BUILD_TYPE to Debug, you will need the auxiliary libraries that you use in your application in debug mode. When you installed / compiled the prerequisite libraries for MRPT (see http:// www.mrpt.org/Building_and_Installing_Instructions). You see that you installed many libraries ending by -dev (i.e. libxxx-dev), the debug version normally ends by -dbg (i.e. libxxx-dbg). Same for the auxiliary libraries that you may have compiled like OpenCV.

You're right about the coding style, the tab is used for indentation and it is represented as 4 blank spaces.

Cheers.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

EduFdez commented 8 years ago

Hi @bergercookie

I'll spend some time today testing your application and going a bit through your code. I'll also write here again in a few hours to comment on your work.

So, maybe we can skype later tonight or in a couple days (tonight I'll fly back to Spain).

Cheers

bergercookie commented 8 years ago

Hi @EduFdez,

On 10/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

I'll spend some time today testing your application and going a bit through your code. I'll also write here again in a few hours to comment on your work.

That's great! I 'll be waiting for your feedback.

So, maybe we can skype later tonight or in a couple days (tonight I'll fly back to Spain). OK, whatever suits you best.

Cheers

With regards, — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

bergercookie commented 8 years ago

Also @EduFdez , I realized I hadn't included the graphslam-engine/CFixedIntervalsNRD_impl.h file in the previous commit of mine, which would cause compilation problems for the application. I corrected this in my latest commit (a57d55b23fe995f9776693bb4caa92a8983e4f52) so I suggest that you pull from that in case you want to run it.

EduFdez commented 8 years ago

OK @bergercookie , I'll pull again.

EduFdez commented 8 years ago

Hi @bergercookie

I had a deeper look at your code and I see that you should put the application inside apps (like the app graph-slam, you can still call it "graphslam-engine" to differentiate it from the former "graph-slam"). This is required for the final result of this project and it's more practical to do it now. But this is easy to do. You can still keep external projects like your "experimental" or "prev_graphslam" for your own tests.

In fact I couldn't compile "graphslam-engine" since there were some mistakes in the its CMakelists.txt, for instance, it couldn't find MRPT. I corrected this CMakelists.txt in my local copy but then there were some other includes not found. The easiest way to avoid this problem is also to make "graphslam-engine" an application inside MRPT (instead of outside). When you have this done I'll test your application and I'll give you further guidelines on the features to complete for the mid-term evaluation.

One little remark: you don't need to use the Doxygen comment style in classes defined in examples or applications because these are not focused to be reused by other programs and thus other developers are not likely to look for this documentation, but the code directly (e.g. like the changes you made in commits SHA-2c39d579fa04c290be8439bacabb69995cdcdfd7 or SHA-90e429e88d32a0f7f6a59f4f7a1139b8174abb75. And the // comment style allows to write less lines.

bergercookie commented 8 years ago

Hi @EduFdez,

On 11/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

I had a deeper look at your code and I see that you should put the application inside apps (like the app graph-slam, you can still call it "graphslam-engine" to differentiate it from the former "graph-slam"). This is required for the final result of this project and it's more practical to do it now. But this is easy to do. You can still keep external projects like your "experimental" or "prev_graphslam" for your own tests.

In fact I couldn't compile "graphslam-engine" since there were some mistakes in the its CMakelists.txt, for instance, it couldn't find MRPT. I corrected this CMakelists.txt in my local copy but then there were some other includes not found. The easiest way to avoid this problem is also to make "graphslam-engine" an application inside MRPT (instead of outside). When you have this done I'll test your application and I'll give you further guidelines on the features to complete for the mid-term evaluation. Until now I was developing graphslam-engine as an independent sample (and not as an MRPT application) so that it would be easier to compile and test. I will format it as an application during the following week and notify you when this is done.

One little remark: you don't need to use the Doxygen comment style in classes defined in examples or applications because these are not focused to be reused by other programs and thus other developers are not likely to look for this documentation, but the code directly (e.g. like the changes you made in commits 2c39d579fa04c290be8439bacabb69995cdcdfd7 or 90e429e88d32a0f7f6a59f4f7a1139b8174abb75. And the // comment style allows to write less lines.

Ok, I'll have it in mind. I try to write the graphslam-engine as generic as possible so that parts of it can potentially be integrated in the mrpt libs, as @jlblancoc mentioned in an earlier comment.

With regards,

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

bergercookie commented 8 years ago

Hi @EduFdez, @jlblancoc,

During the last couple of days I worked mostly towards the structure of the overall project:

Currently all the code resides in the app/graphslam-engine directory. Since the graphslam-engine brings new capabilities to the MRPT project I think it is logical that at some point certain files (CgraphSlamEngine_, C_RegistrationDecider) should be moved into the /lib/graphlsam directory.

@EduFdez, I think that the application can now be successfully compiled. If not, let me know so that we can fix it.

Looking forward to your feedback, Nikos

On 11/06/16, Nikos Koukis wrote:

Hi @EduFdez,

On 11/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

I had a deeper look at your code and I see that you should put the application inside apps (like the app graph-slam, you can still call it "graphslam-engine" to differentiate it from the former "graph-slam"). This is required for the final result of this project and it's more practical to do it now. But this is easy to do. You can still keep external projects like your "experimental" or "prev_graphslam" for your own tests.

In fact I couldn't compile "graphslam-engine" since there were some mistakes in the its CMakelists.txt, for instance, it couldn't find MRPT. I corrected this CMakelists.txt in my local copy but then there were some other includes not found. The easiest way to avoid this problem is also to make "graphslam-engine" an application inside MRPT (instead of outside). When you have this done I'll test your application and I'll give you further guidelines on the features to complete for the mid-term evaluation. Until now I was developing graphslam-engine as an independent sample (and not as an MRPT application) so that it would be easier to compile and test. I will format it as an application during the following week and notify you when this is done.

One little remark: you don't need to use the Doxygen comment style in classes defined in examples or applications because these are not focused to be reused by other programs and thus other developers are not likely to look for this documentation, but the code directly (e.g. like the changes you made in commits 2c39d579fa04c290be8439bacabb69995cdcdfd7 or 90e429e88d32a0f7f6a59f4f7a1139b8174abb75. And the // comment style allows to write less lines.

Ok, I'll have it in mind. I try to write the graphslam-engine as generic as possible so that parts of it can potentially be integrated in the mrpt libs, as @jlblancoc mentioned in an earlier comment.

With regards,

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

EduFdez commented 8 years ago

Hi @bergercookie

Good job :) You forgot to commit the graphslam-engine's CMakelists.txt

While I test your app and review your code you could start adapting graphslam-engine to work with other input sensors, I suggest you to start with RGBD images (like those from Kinect). There are already datasets with groundtruth in rawlog format and it is straightforward to adapt: http://www.mrpt.org/Collection_of_Kinect_RGBD_datasets_with_ground_truth_CVPR_TUM_2011. Then you can use your class templates - CNodeRegistrationDecider_t, CEdgeRegistrtatioDecider_t - to code new implementations. Afterwards, you could move these generic classes to the graph-slam library.

The adaptation to other input sensors was an optional part of the project, while the loop closure strategy is a requirement, but since you are developing at a good pace I would do at least the adaptation to Kinect first. It will give you more ideas of how to create generic classes, it will be more motivating for you and you'll see nicer visualizations.

Cheers, Eduardo

bergercookie commented 8 years ago

On 17/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

Good job :) You forgot to commit the graphslam-engine's CMakelists.txt Indeed, there was a wrong entry in my .gitignore file. I included the application CMakelists.txt in my latest commit.

While I test your app and review your code you could start adapting graphslam-engine to work with other input sensors, I suggest you to start with RGBD images (like those from Kinect). There are already datasets with groundtruth in rawlog format and it is straightforward to adapt: http:// www.mrpt.org/Collection_of_Kinect_RGBD_datasets_with_ground_truth_CVPR_TUM_2011 . Then you can use your class templates - CNodeRegistrationDecider_t, CEdgeRegistrtatioDecider_t - to code new implementations. Afterwards, you could move these generic classes to the graph-slam library.

The adaptation to other input sensors was an optional part of the project, while the loop closure strategy is a requirement, but since you are developing at a good pace I would do at least the adaptation to Kinect first. It will give you more ideas of how to create generic classes, it will be more motivating for you and you'll see nicer visualizations. Great! I'll start working towards that direction then.

Lastly, there seems to be a considerable decrease of speed in the execution of my application in the last couple of commits which I noticed yesterday. I'll find out what's causing this and correct it. EDIT: The decrease in speed was due to the compilation of mrpt in Debug mode.

Cheers, Eduardo

With regards, Nikos

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

bergercookie commented 8 years ago

Hola @EduFdez, @jlblancoc,

During the past week I worked on the following parts of the application:

Just to let you know, I finished my part of the mid-term evaluation. I will continue working on the RGB-D part to enhance its performance and fix any remaining bugs.

With regards, Nikos

On 17/06/16, Nikos Koukis wrote:

On 17/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

Good job :) You forgot to commit the graphslam-engine's CMakelists.txt Indeed, there was a wrong entry in my .gitignore file. I included the application CMakelists.txt in my latest commit.

While I test your app and review your code you could start adapting graphslam-engine to work with other input sensors, I suggest you to start with RGBD images (like those from Kinect). There are already datasets with groundtruth in rawlog format and it is straightforward to adapt: http:// www.mrpt.org/Collection_of_Kinect_RGBD_datasets_with_ground_truth_CVPR_TUM_2011 . Then you can use your class templates - CNodeRegistrationDecider_t, CEdgeRegistrtatioDecider_t - to code new implementations. Afterwards, you could move these generic classes to the graph-slam library.

The adaptation to other input sensors was an optional part of the project, while the loop closure strategy is a requirement, but since you are developing at a good pace I would do at least the adaptation to Kinect first. It will give you more ideas of how to create generic classes, it will be more motivating for you and you'll see nicer visualizations. Great! I'll start working towards that direction then.

Lastly, there seems to be a considerable decrease of speed in the execution of my application in the last couple of commits which I noticed yesterday. I'll find out what's causing this and correct it.

Cheers, Eduardo

With regards, Nikos

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

EduFdez commented 8 years ago

Hi @bergercookie , @jlblancoc

I just submitted the mid-term evaluation. As you'll see I suggested to establish some kind of milestones for the pending assignments up to this project's completion. My idea is that when a important issue is tackled and achieved there is an example to test it indicating which dataset has been tested and the full command line invocation for the application. One of these important issues could be the visualization, the adaptation RGB-D observations, or the loop closure solution, which is the most challenging part of this project in my opinion and thus it was left for after the mid-term.

The point of indicating which dataset and the full command line invocation would have helped me to evaluate the progress on the project and to see quickly which config file correspond to which dataset. See for instance "Application: icp-slam-live" in http://www.mrpt.org/category/apps/ Note also that updating http://www.mrpt.org/category/apps/ with "graphslam-engine" is a requirement for the completion of this GSoC. To follow the project it would also be useful if you create a readme.txt inside /.../config_files/graphslam-engine/ to add the datasets that you have validated, e.g.:

./bin/graphslam-engine -g .../mrpt_nikos/share/mrpt/datasets/graphslam-engine-demos/observation_only_map2/range_030_bearing_015.rawlog.GT.txt -r /.../mrpt_nikos/share/mrpt/datasets/graphslam-engine-demos/observation_only_map2/range_030_bearing_015.rawlog -i /.../mrpt_nikos/share/mrpt/config_files/graphslam-engine/laser_odometry.ini ............. and so on.

About the graphslam-engine's CMakelists.txt, @bergercookie I think you could standardize it to the style of the other MRPT apps so that it's more simple and easier to read. And you have to remove the line: set(MRPT_DIR, "/home/bergercookie/mrpt_build_dir/").

I don't know which IDE's you use @bergercookie and @jlblancoc . I like QtCreator and I have the problem that "graphslam-engine" is not shown as part of MRPT's apps. It compiles and runs in a terminal window but it's not recognized by QtCreator. I tried rewriting the graphslam-engine's CMakelists.txt to make it the similar as in other apps but it didn't solved my problem. @jlblancoc do you have any idea on why this happens?

@bergercookie you are right RGBD rawlog datasets that cannot be downloaded, @jlblancoc can you fix the broken link of sourceforge? please.

Cheers, Edu

bergercookie commented 8 years ago

command_line_args Hi @EduFdez, @jlblancoc,

On 24/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie , @jlblancoc

I just submitted the mid-term evaluation. As you'll see I suggested to establish some kind of milestones for the pending assignments up to this project's completion. My idea is that when a important issue is tackled and achieved there is an example to test it indicating which dataset has been tested and the full command line invocation for the application. One of these important issues could be the visualization, the adaptation RGB-D observations, or the loop closure solution, which is the most challenging part of this project in my opinion and thus it was left for after the mid-term.

The point of indicating which dataset and the full command line invocation would have helped me to evaluate the progress on the project and to see quickly which config file correspond to which dataset. See for instance "Application: icp-slam-live" in http://www.mrpt.org/category/apps/

Indeed, I was concentrated more on the actual development of the code rather than provide example usages for it, which turned out to be wrong. To deal with this, I added command line arguments so that the user can choose which Node/Edge registration decider class to use as well as arguments for displaying the list of available deciders (see attached screenshot for example on this). I also enhanced the docstrings of the .ini files on the cases that each one has (and therefore can) be used (b5b5a1cbf6d8d051b08b3e75b8e1917794de8cf0). Finally I added README.txt which summarizes the purpose of the application, and contains explanations on the cmd line arguments as well as full commands that have been tested and worked successfully (869f7828d1c87a3717f3f88ce5cc68a9621e04fb). I placed README.txt in apps/graphslam-engine/ directory since all the application READMEs are placed in their corresponding application directory as well (e.g. hmt-slam, pf-localization). However, let me know if you still want this to be placed in the config_files/ directory.

Note also that updating http://www.mrpt.org/category/apps/ with "graphslam-engine" is a requirement for the completion of this GSoC. To follow the project it would also be useful if you create a readme.txt inside /.../config_files/graphslam-engine/ to add the datasets that you have validated, e.g.:

        ./bin/graphslam-engine -g .../mrpt_nikos/share/mrpt/datasets/
        graphslam-engine-demos/observation_only_map2/
        range_030_bearing_015.rawlog.GT.txt -r /.../mrpt_nikos/share/mrpt/
        datasets/graphslam-engine-demos/observation_only_map2/
        range_030_bearing_015.rawlog -i /.../mrpt_nikos/share/mrpt/
        config_files/graphslam-engine/laser_odometry.ini
        ............. and so on.

About the graphslam-engine's CMakelists.txt, @bergercookie I think you could standardize it to the style of the other MRPT apps so that it's more simple and easier to read. And you have to remove the line: set(MRPT_DIR, "/home/ bergercookie/mrpt_build_dir/").

Ok, I removed the custom messages as well as the MRPT_DIR directive from the CMakeLists.txt file (see fc75d82e6b285785fae9d3fb99a1c508f04a10ba).

I don't know which IDE's you use @bergercookie and @jlblancoc . I like QtCreator and I have the problem that "graphslam-engine" is not shown as part of MRPT's apps. It compiles and runs in a terminal window but it's not recognized by QtCreator. I tried rewriting the graphslam-engine's CMakelists.txt to make it the similar as in other apps but it didn't solved my problem. @jlblancoc do you have any idea on why this happens? I use Vim for pretty much all of my editing so I have no clue on this.

@bergercookie you are right RGBD rawlog datasets that cannot be downloaded, @jlblancoc can you fix the broken link of sourceforge? please.

Cheers, Edu With regards to the RGB-D datasets at the moment I can successfully read and visualize the ground truth information (@jlblancoc the ground truth is in quaternion form right?). I have tried adding (2D) constraints in the graph using the following 2 ways:

  • First convert the 3D point cloud into its corresponding 2D cloud using the CObservation3DRangeScan::convertTo2DLaserScan method and then try and align the 2D point clouds as in the native CObservation2DRangeScans case.
  • Align the 3D point clouds and fetch the corresponding 2D constraint from the CPose3D result of the alignment.

None of these ways seems to make the robot trajectory follow the ground truth trajectory, which is kind of awkward since the goodness of the ICP operation is , at most times, relatively high >0.95 and I use the same strategy with the native 2DRangeScans case. Given the large_with_loop, large_no_loop datasets I will revisit this problem and let you know of the outcome.

@EduFdez please let me know if there's any other modification that I should make before the mid-term pull-request.

With regards, Nikos

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

EduFdez commented 8 years ago

Hi @bergercookie

Thank you for the changes in the .ini files and the README.txt with the run examples. The README file is well placed in apps/graphslam-engine/ All in all I consider that you are doing a good job, I should have tell you before to specify the run commands to check the same tests you are carrying out, but we're just here after one month of coding which is quite good.

With regards to the RGB-D datasets, I think the mismatch between GT and estimated trajectory comes from different reference systems among them. I believe the MRPT reference system is: X -> Forward; Y -> Left; Z -> Upward (very common in robotics) while I think the reference system in the GT is: X -> ; Right -> Downward; Z -> Forward (very common in computer vision) So you would just have to transform the reference system. Tell me if you have any difficulty on this. And please, tell me which command you run to execute your app on the RGBD dataset, so that I can see how it looks like.

There was nothing else to do for the midterm evaluation. Now you can concentrate on making your app work with RGB-D images and adding the next features specified in the timeline of your project for 15th August.

Regards, Edu

bergercookie commented 8 years ago

Hi @EduFdez

On 26/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie

Thank you for the changes in the .ini files and the README.txt with the run examples. The README file is well placed in apps/graphslam-engine/ All in all I consider that you are doing a good job, I should have tell you before to specify the run commands to check the same tests you are carrying out, but we're just here after one month of coding which is quite good.

With regards to the RGB-D datasets, I think the mismatch between GT and estimated trajectory comes from different reference systems among them. I believe the MRPT reference system is: X -> Forward; Y -> Left; Z -> Upward (very common in robotics) while I think the reference system in the GT is: X -> ; Right -> Downward; Z -> Forward (very common in computer vision) So you would just have to transform the reference system. Tell me if you have any difficulty on this. And please, tell me which command you run to execute your app on the RGBD dataset, so that I can see how it looks like.

That's interesting, thanks! I'll modify the code accordingly and let you know on this. The command to run the algorithm for an RGB-D dataset is the following: graphslam-engine -i MRPT/share/mrpt/config_files/graphslam-engine/rgbd_datasets.ini -r MRPT/share/mrpt/datasets/graphslam-engine-demos/rawlog_rgbd_dataset_freiburg2_pioneer_slam2/rgbd_dataset_freiburg2_pioneer_slam2.rawlog --node-reg CICPGoodnessNRD --edge-reg CICPGoodnessERD -g MRPT/share/mrpt/datasets/graphslam-engine-demos/rawlog_rgbd_dataset_freiburg2_pioneer_slam2/groundtruth.txt

The previous command requires that the rgbd_dataset_freiburg2_pioneer_slam2 dataset is placed in graphslam-engine-demos directory. I haven't uploaded this to my github account due to its size so you'll have to download it from the RGB-D repository page manually.

P.S. You'll notice that the GT poses are displaced so that their starting pose matches the origin. This is done by subtracting the first GT pose from all the following.

There was nothing else to do for the midterm evaluation. Now you can concentrate on making your app work with RGB-D images and adding the next features specified in the timeline of your project for 15th August. Ok, should I make a pull-request now, or wait until the 15th of August to do so?

Regards, Edu

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

EduFdez commented 8 years ago

Hi @bergercookie There is no need to do a pull request for the mid-term evaluation. The pull request should be done when your graph-slam application is working and documented (at least in the most basic features). The graph-slam application still requires the implementation of the loop closure strategy and thus, the pull request should be done after this is done. Then several pull request could be done with new improvements of working and documented code.

bergercookie commented 8 years ago

bug_in_robot_turns available_keystrokes

Hi @EduFdez, @jlblancoc,

Since my last update I have been working on the following changes in the graphslam-engine application:

With regards to the registration algorithm of the CICPGoodnessNRD class, it was observed that even though it successfully tracks the ground truth most of the times, it fails to do so when dealing with turns in the trajectory. Since this is the same class handling RGB-D datasets it practically comes down to the same problem. The tested RGB-D datasets mostly contained rotations of the robot with small straight paths and I think that is the reason the decider does not work there too. A picture of the problem is included.

@jlblancoc just as a kind reminder, it would be really valuable to fix the broken links in the RGB-D dataset repository so that I can verify the previous assumption of mine.

@EduFdez, could we set up a Skype call during the next days to discuss our approach for the final part of the program?

Thanks in advance, Nikos

On 30/06/16, Eduardo Fernandez-Moral wrote:

Hi @bergercookie There is no need to do a pull request for the mid-term evaluation. The pull request should be done when your graph-slam application is working and documented (at least in the most basic features). The graph-slam application still requires the implementation of the loop closure strategy and thus, the pull request should be done after this is done. Then several pull request could be done with new improvements of working and documented code.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

Nikos Koukis School of Mechanical Engineering National Technical University of Athens nickkouk@gmail.com +30 6985827375

jlblancoc commented 8 years ago

Add support for decider/optimizer classes to add keystrokes in the CDisplaywindow and get feedback for any keystroke that they might be ...

Good! I like that generic, thinking of the future, coding style :+1:

On the RGB-D dataset, if you refer to this link it works now. I had a problem with the server today and had to do some internal hacks... Otherwise, please refresh me on what's the broken link!

Cheers, and keep up the good work!

bergercookie commented 8 years ago

@jlblancoc, The following links still don't seem to be working:

http://downloads.sourceforge.net/project/mrpt/Datasets%20%28Rawlogs%29/Datasets/RGBD-datasets/rawlog_rgbd_dataset_freiburg2_large_no_loop.tgz http://downloads.sourceforge.net/project/mrpt/Datasets%20%28Rawlogs%29/Datasets/RGBD-datasets/rawlog_rgbd_dataset_freiburg2_large_with_loop.tgz http://downloads.sourceforge.net/project/mrpt/Datasets%20%28Rawlogs%29/Datasets/RGBD-datasets/rawlog_rgbd_dataset_freiburg2_flowerbouquet.tgz http://downloads.sourceforge.net/project/mrpt/Datasets%20%28Rawlogs%29/Datasets/RGBD-datasets/rawlog_rgbd_dataset_freiburg2_teddy.tgz http://downloads.sourceforge.net/project/mrpt/Datasets%20%28Rawlogs%29/Datasets/RGBD-datasets/rawlog_rgbd_dataset_freiburg2_pioneer_slam.tgz

jlblancoc commented 8 years ago

Unbelievable! It's an error in the hosting+mirroring service of SourceForge.net, they seem to have lost the files!!

@JGMonroy @MarianoJT88 @famoreno Do you know of any local copies in UMA's servers / computers of the RGBD Freiburg2 datasets as rawlogs?

EduFdez commented 8 years ago

Hi @bergercookie We can do the skype tomorrow about 18h, or after tomorrow. I had a very bad internet connection this last week, sorry. I'll be reviewing a bit the project during the weekend and then I hope to give you some feedback. Cheers

bergercookie commented 8 years ago

Hi @EduFdez tomorrow 18:00 (that's UTC right?) is fine for me.

with regards, Nikos

On July 16, 2016 12:08:04 AM GMT+03:00, Eduardo Fernandez-Moral notifications@github.com wrote:

Hi @bergercookie We can do the skype tomorrow about 18h, or after tomorrow. I had a very bad internet connection this last week, sorry. I'll be reviewing a bit the project during the weekend and then I hope to give you some feedback. Cheers

You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/MRPT/GSoC2016-discussions/issues/2#issuecomment-233070383

jlblancoc commented 8 years ago

Hi @bergercookie,

Just a quick / formal reminder about the most important tasks regarding GSoC2016:

Happy coding!