Alignment is not working correctly ( bug + handling different map formats)

[RemaDaher]

I am trying this example: $ python demo.py --img_src 'map_sample/map_src.png' --img_dst 'map_sample/map_dst.png' -multiprocessing -visualize with my own slam map generated from cartographer (source) and an autocad drawing exported as png (destination). However, the alignment is not working correctly. Is there a specific way I should save my autocad file or my slam map?

[saeedghsh]

Dear @RemaDaher

Thank you very much for your interest in this package.

The maps should follow the conventional Occupancy Grid Map format as you can see here, i.e.:

• occupied = 0
• open = 255
• unexplored = 127

The method have some underlying assumption and not necessarily suited to maps of all types of environments. You can read more about it in this paper (page 2, first column: "By the following set of assumptions..."). Maybe I can help you more if you share with me examples of your maps. If you don't want to share your maps publicly, you can find my contact info here.

Cheers, S.

[RemaDaher]

These are the maps I used. I changed the .dwg file in the zip file to .png and tried to align it with the gridmap. However, it was not working well.

SRB_4thFlr.zip

[saeedghsh]

Dear @RemaDaher

Thank you for your reply.

There are few things to consider:

• You cannot just rename a .dwg file to .png. You will need to use a proper software to convert it.

• I opened your .dwg map with a DWG viewer and it does not seem to have an Occupancy Grid Map (OGM) format (it is a CAD drawing after all). In an OGM, the open space is white, occupied cells are black and unexplored area are colored gray (255, 0 and 127 in gray-scale). The map from "cartographer" that you attached has the correct format (almost! see the next point for the issue with the sensor map).

  

• Your sensor map (from "cartographer") does not fully swipe the open area, and there are patches of gray in the middle of open space. That will be a challenge for method. The method expects the open space to be fully white.

• Your maps do not have "perpendicular principle orientations". After correcting the file/map issues stated above, please set the following parameter from the demo.py script to False before running the script again:

  lnl_config['orthogonal_orientations'] = False

I would love to help you futher. If you manage to correct the maps, I will be more than happy to help you with the setting of the parameters.

Cheers, Saeed.

[RemaDaher]

Thank you so much for your help. I attached the updated maps that I changed as advised by you. The code is still not working with these maps. What is the correct way of converting the files in order for it to work?

The error is: python demo.py --img_src 'map_sample/new_grid.png' --img_dst 'map_sample/SRB_WHITE(work).png' -multiprocessing -visualize /usr/local/lib/python2.7/dist-packages/skimage/transform/radon_transform.py:58: UserWarning: The default of circle in skimage.transform.radon will change to True in version 0.15. warn('The default of circle in skimage.transform.radon ' Traceback (most recent call last): File "demo.py", line 154, in hyp_config) File "/home/yasmine/Map-Alignment-2D/map_alignment/map_alignment.py", line 535, in _generate_hypothese if (src_occ/src_tot) < config['face_occupancy_threshold']: ZeroDivisionError: float division by zero

[saeedghsh]

Dear @RemaDaher,

Thank you for you patience and new updates.

The error is due to a bug, unfortunately, where I forgot to control for ZeroDivisionError. I can't update the repository right now, so meanwhile you can do an adjustment yourself. In the function _generate_hypothese from the file Map-Alignment-2D/map_alignment/map_alignment.py, apply the following changes:

• from:

  if (src_occ/src_tot) < config['face_occupancy_threshold']

  to

  if src_tot> 10 and (src_occ/src_tot) < config['face_occupancy_threshold']

• from

  if (dst_occ/dst_tot) < config['face_occupancy_threshold']

  to

  if dst_tot> 10 and (dst_occ/dst_tot) < config['face_occupancy_threshold']

---

As for the settings, please try these in the demo.py:

lnl_config['peak_detect_sinogram_config'] = [15, 15, 0.10]
lnl_config['orthogonal_orientations'] = False
arr_config['prune_dis_neighborhood'] = 5
arr_config['prune_dis_threshold'] = .15

---

Please bear in mind that while this method should be able to handle maps like yours in theory, the implementation, however, were carried out mostly for "Manhattan-like" maps (i.e. 2 perpendicular principle orientations.) While the method finds an alignment for your maps, it is far from optimal. Addressing this matter requires some update to the core of the implementation that I cannot find the time for right now. Alternatively you can try out this method that builds on top of this one, and optimizes the resulting alignment. Maybe that helps, but I haven't had the time to test it myself yet, and will update with an answer as soon as I try the other method on your maps.

Cheers, Saeed.

PS: I will try to find the time and update the repo, but have no idea when that would happen. Meanwhile, please get back to me if you have any further questions or need any help.

[RemaDaher]

Dear @saeedghsh ,

Thank you so much for your help and quick replies.

I have tried the changes to the program and sit now works as advised. I will do the same changes to this methodhttps://github.com/saeedghsh/Map-Alignment-Nonrigid-Optimization-2D and try it out.

Cheers.

[RemaDaher]

Dear @saeedghsh

I was looking further into the code and I got the arr_match_score of the winning hypothesis and compared it with different examples. The score changes drastically from (0.069 in my example to 0.31 in your example). What could this be due to? and how does this matching score really represent the matching; i.e. is it a percentage of the intersection over union ratio? can you please explain this more to me?

This is not an issue with the code it's just a question; however, I don't have your email to contact you separately. Can you please send me your email so that I can contact you there instead of posting an issue?

Best, Rema Daher

[saeedghsh]

Dear @RemaDaher ,

The arrangement score in this repository is a summation of Intersection Over Union (IOU) score for all associated faces. The face association step identifies pair of face that are best aligned under a given transformation. There are additional constraints to assure a one-to-one face association. Section 3.3 on page 9 of this paper describes the process in more detail.

The reason that the range of match score differs significantly from one example to another is that the match core is normalized to the whole surface area of the arrangement (decomposition). Due to the form of your maps, there are many irrelevant faces produced that do not contribute to the alignment and change the normalized scale. Since the selection of the best match (hypothesis) is based on a comparison between hypotheses in one example, this varying range of match score does not have any impact on the process.

In the other repository (Nonrigid Optimization of Multimodal 2D Map Alignment), however, we employed another way of measuring match score that is based on the alignment of the occupied points. You can read more about this alternative match score here.

You are welcome to send further questions via email (saeed.gh.sh at gmail).

Cheers, S.