as mentioned in osrf/rmf_demos#42

How to recreate:

• I was using https://github.com/osrf/rmf_demos/tree/master/rmf_demo_maps/maps/airport_terminal, but not necessary to use it
• select any vertex
• add field spawn_robot_type, use either Magni, MiR100 or RobotPlaceholder
• add field spawn_robot_name, but leave empty

[gzserver-7] Gazebo multi-robot simulator, version 9.12.0
[gzserver-7] Copyright (C) 2012 Open Source Robotics Foundation.
[gzserver-7] Released under the Apache 2 License.
[gzserver-7] http://gazebosim.org
[gzserver-7] 
[gzclient-8] Gazebo multi-robot simulator, version 9.12.0
[gzclient-8] Copyright (C) 2012 Open Source Robotics Foundation.
[gzclient-8] Released under the Apache 2 License.
[gzclient-8] http://gazebosim.org
[gzclient-8] 
[gzserver-7] terminate called after throwing an instance of 'std::logic_error'
[gzserver-7]   what():  basic_string::_M_construct null not valid
[ERROR] [gzserver-7]: process has died [pid 17682, exit code -6, cmd 'gzserver --verbose -s libgazebo_ros_init.so -s libgazebo_ros_factory.so /home/aaron/workspaces/demos_ws/install/rmf_demo_maps/share/rmf_demo_maps/maps/airport_terminal/airport_terminal.world'].

• would be good if this was caught during the world-building stage

• low priority

Report of potential weirdness with click+drag event handling in KDE: the whole window moves when clicking and dragging, as if you press alt+click+drag. Need to test further.

I am attempting to generate a gazebo world by annotation using traffic-editor and using building_map_gazebo, for a rewrite of a previous tutorial on using RMF. I have annotated a .png file using traffic-editor, but now when i try to run the following command from my project root using the commands:

ros2 run building_map_tools building_map_gazebo ./maps/demo-world/demo-world.yaml ./maps/demo-world/demo-world.world ./maps/demo-world/models

i get the following error:

level L1 scale estimated as 0.002524245376844592
generating model of level L1 in ./maps/demo-world/models/demo-world_L1
  wrote ./maps/demo-world/models/demo-world_L1/model.config
generate_wall_visual_mesh(demo-world_L1, ./maps/demo-world/models/demo-world_L1)
  generating ./maps/demo-world/models/demo-world_L1/meshes/walls.obj
Traceback (most recent call last):
  File "/home/bhan/repos/fleet-adapter-tutorial/ros2/install/building_map_tools/lib/building_map_tools/building_map_gazebo", line 11, in <module>
    load_entry_point('building-map-tools==0.0.0', 'console_scripts', 'building_map_gazebo')()
  File "/home/bhan/repos/fleet-adapter-tutorial/ros2/install/building_map_tools/lib/python3.6/site-packages/building_map_generators/building_map_gazebo.py", line 13, in main
    g.generate_sdf(input_filename, output_filename, output_model_dir)
  File "/home/bhan/repos/fleet-adapter-tutorial/ros2/install/building_map_tools/lib/python3.6/site-packages/building_map/generator.py", line 28, in generate_sdf
    building.generate_sdf_models(output_models_dir)
  File "/home/bhan/repos/fleet-adapter-tutorial/ros2/install/building_map_tools/lib/python3.6/site-packages/building_map/building.py", line 90, in generate_sdf_models
    level.generate_sdf_model(model_name, model_path)
  File "/home/bhan/repos/fleet-adapter-tutorial/ros2/install/building_map_tools/lib/python3.6/site-packages/building_map/level.py", line 304, in generate_sdf_model
    self.write_sdf(model_name, model_path)
  File "/home/bhan/repos/fleet-adapter-tutorial/ros2/install/building_map_tools/lib/python3.6/site-packages/building_map/level.py", line 290, in write_sdf
    self.generate_walls(model_ele, model_name, model_path)
  File "/home/bhan/repos/fleet-adapter-tutorial/ros2/install/building_map_tools/lib/python3.6/site-packages/building_map/level.py", line 214, in generate_walls
    self.generate_wall_visual_mesh(model_name, model_path)
  File "/home/bhan/repos/fleet-adapter-tutorial/ros2/install/building_map_tools/lib/python3.6/site-packages/building_map/level.py", line 149, in generate_wall_visual_mesh
    with open(obj_path, 'w') as f:
FileNotFoundError: [Errno 2] No such file or directory: './maps/demo-world/models/demo-world_L1/meshes/walls.obj'

any idea what could be the problem? I suspected that the w flag for open is insufficient for creating new files that don't yet exist, but i have tried editing it to w+ and it doesn't seem to work.

Error when running building_map_gazebo and building_map_nav on existing maps following merge of #85 .

Error details:

Starting >>> rmf_demo_maps
--- stderr: rmf_demo_maps
Traceback (most recent call last):
  File "/home/rmf_demos_ws/install/building_map_tools/lib/building_map_tools/building_map_gazebo", line 11, in <module>
    load_entry_point('building-map-tools==0.0.0', 'console_scripts', 'building_map_gazebo')()
  File "/home/rmf_demos_ws/install/building_map_tools/lib/python3.6/site-packages/building_map_generators/building_map_gazebo.py", line 20, in main
    options)
  File "/home/rmf_demos_ws/install/building_map_tools/lib/python3.6/site-packages/building_map/generator.py", line 56, in generate_gazebo_sdf
    options + ['gazebo'])
  File "/home/rmf_demos_ws/install/building_map_tools/lib/python3.6/site-packages/building_map/generator.py", line 29, in generate_sdf
    building = self.parse_editor_yaml(input_filename)
  File "/home/rmf_demos_ws/install/building_map_tools/lib/python3.6/site-packages/building_map/generator.py", line 18, in parse_editor_yaml
    return Building(y)
  File "/home/rmf_demos_ws/install/building_map_tools/lib/python3.6/site-packages/building_map/building.py", line 18, in __init__
    self.levels[level_name] = Level(level_yaml, level_name)
  File "/home/rmf_demos_ws/install/building_map_tools/lib/python3.6/site-packages/building_map/level.py", line 46, in __init__
    if yaml_node['fiducials']:
KeyError: 'fiducials

It takes a long time to create walls.

The workflow is currently:

• click edges of the walls to mark vertex
• click on wall to drag the vertex
• in some cases, the vertex can be very far apart and difficult to see when zooming out due to the small vertex
• move the vertex to adjust

To speed up creation of walls, I'd suggest something like a "path tool" from photoshop (1 min)
https://youtu.be/3JhcdVXt1X4?t=58
Where the user would click to create a vertex, click another vertex and the wall would be created in two clicks. This should work on any types of walls.

The suggestion for might look something like this:

• click to create a vertex
• click to create another vertex at an edge
• a wall is created between these two edges
• esc to stop this state (so we don't draw a line unintendedly)
• move vertex to adjust

The only potential "issue" with this is prior planning. The user would need to plan where to draw the vertex before starting to draw. But as the path tool from photoshop, it is faster to do that than to place the vertex then draw the walls.

The users may already have an existing image that they want to trace over. In my case, it's an occupancy grid map which is in png format.

Use various CMake and C++ ifdef tricks to make the depedency on libignition-plugin dependency optional, to simplify packaging and distribution, since the process-flow simulation interface is a niche feature (much like the interface-recording via OpenCV, which is already an optional dependency)

I have received an error for using the script crop.py:

Traceback (most recent call last):
  File "./scripts/crop.py", line 149, in <module>
    white_img_cropped = crop(green_img, white_img)
  File "./scripts/crop.py", line 32, in crop
    mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_NONE)
ValueError: need more than 2 values to unpack

I fixed it by changing the number of outputs from:
_ , contours, _ = cv2.findContours( mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_NONE)
to
contours, _ = cv2.findContours(mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_NONE)

I don't know how to recreate this in general, but I'd been happening to me while using Kubuntu. Any left click on the canvas will cause the window to be dragged around. Clicking on any other widgets seems to work okay.

Having the scripts used to generate the model thumbnails in this repo will be beneficial.

This feature doesn't currently work. It would be helpful when (for example) defining fiducials, because the coordinate system can change and the previously-saved X,Y,scale coordinates can be nonsense.

Should be a quick fix, just need to wrap this loop with a conditional on yaml_node[lifts]:

https://github.com/osrf/traffic_editor/blob/master/building_map_tools/building_map/building.py#L34

Currently the thumbnails live in the source tree, and a QSettings variable needs to be set to identify the source tree on the user's system. This is bad for a few reasons. Among them, this will prevent the thumbnails from working when we generate binary packages (.dpkg, etc) because the thumbnails won't be included. We should add some CMake rules to copy the the thumbnails to the install space.

We would like to use this tool to create lanes and vertices over a normal 'lidar map' png.

For that our workflow would create a new level and use the map as a png, add the vertices and lanes as needed and save the project into a yaml file.

The resulting file will contain the poses of all the vertices in pixel coordinates, however we would need to convert them in map coordinates (in meters). For that we could:

• Add measurements and then use them as reference to calculate the resolution of the file (converting from pixels to meters), however, there is no way to encode the map origin (The 2-D pose of the lower-left pixel in the map). Also, using measurement can be inaccurate unless you do it very carefully.
• When converting the vertices use both the generated yaml files and a (map_server)[http://wiki.ros.org/map_server#YAML_format] yaml file to read the resolution and origin. This solution is not ideal as you need to keep the two files together, and it would be difficult to support multiple levels and match each level to the corresponding map yaml.

A better solution would be to add the resolution and origin properties to a level and have that saved directly on the yaml. For example:

levels:
  Building:
    drawing:
      filename: /full/path/map.png
      origin:
         x: 16.012
         y: 18.052
         yaw: 0
      resolution: 0.1
    elevation: 0

These fields could even added to the Level->Add dialog or use the property editor on the right to add those. The Level->Add dialog could also support reading the map_server yaml and read the map image, resolution and origin from that file.

Is this something that you would consider? Is there already a good mechanism to encode this information in the saved file that we did not see?

Should save backup copies every N minutes somewhere, to reduce risk of catastrophic loss of data and resulting Great Sadness.

simulated doors/plugins do not behave as drawn on traffic_editor, when motion_direction is toggled to -1

Fixes will be added to building_map_tools and door.cpp to make simulated doors behave as expected

For repetitive layouts this would be convenient. The very next request would be "group move" to align those copied layout features.

After following the steps listed on the README.md to start a new project, adding a floor plan using Levels->Add, for example office.png, the floor plan does not show up, nor does the level show up in the levels list.

Only after saving the project (Ctrl + S ), exiting traffic_editor, and opening traffic_editor again, then will the correct floor plan and level be display.

• Attempting to rotate model thumbnails always places them -90 degrees offset from what was desired

User can right-click to prevent the creation of walls and vertex.
But when the user tries to create another wall, the vertex appears in another place.

https://imgur.com/a/9vStM6A

This shouldn't be a high priority

It would be very luxury to have the GUI magically restore location and size on startup. This will be easy to do with QSettings.

When using the 'Level-Add' dialog, if a image name is added using 'Find`, nothing happens when clicking 'OK'.

Suggestion to improve on the result of this issue
#63 (comment)

It is more intuitive for the chain wall creation to start from clicking on "add wall". The user won't have to keep switching from vertex to walls (and vice versa).
Clicking on "Add Wall" would first create a vertex, then we continue with the chain wall creation until the user is done.

It would be nice for the UI to allow vertex deletion, so long as the vertex is not part of an existing edge or polygon.

Currently, when we first load an empty map, any annotations are extremely out of proportion with the current view. This scale issue is fixed on subsequent loads. It would be helpful to have this scaling done automatically.

I followed the instruction in rmf_demos to get all the necessary packages and built ignition according to this file. When launching office demo with ignition support, I got the following errors

[ign-8] [Err] [SystemLoader.cc:101] Failed to load system plugin [slotcar] : system not found in library  [libslotcar.so] from path [/home/makinohara/rmf_demos_ws/install/building_ignition_plugins/lib/libslotcar.so].
[ign-8] [Err] [SystemLoader.cc:101] Failed to load system plugin [slotcar] : system not found in library  [libslotcar.so] from path [/home/makinohara/rmf_demos_ws/install/building_ignition_plugins/lib/libslotcar.so].
[ign-8] [Err] [SystemLoader.cc:101] Failed to load system plugin [door] : system not found in library  [libdoor.so] from path [/home/makinohara/rmf_demos_ws/install/building_ignition_plugins/lib/libdoor.so].
[ign-8] [Err] [SystemLoader.cc:101] Failed to load system plugin [door] : system not found in library  [libdoor.so] from path [/home/makinohara/rmf_demos_ws/install/building_ignition_plugins/lib/libdoor.so].
[ign-8] [Err] [SystemLoader.cc:101] Failed to load system plugin [door] : system not found in library  [libdoor.so] from path [/home/makinohara/rmf_demos_ws/install/building_ignition_plugins/lib/libdoor.so].

Because of these errors, I can now only start the 3D scenario but cannot send requests. I don't know what is causing the problem since the files reporting errors are present.

I am using feature/add_ignition_support branch for rmf_demos and feature/ign_lift_plugin for traffic_editor. Both are built up to date

The intersections between the floor polygons and the scenario regions-of-interest are going to be nontrivial. When generating "world subsets" it looks like Shapely will be a reasonable way to do the geometric calculations.

The vast majority of models are expected to be static, but sometimes we actually want a dynamic model so that robots can interact with objects to load into carts, etc.

In order to delete the walls and vertex faster, I can suggest a sort of "click and drag" feature. The user can select the area and delete all the walls and vertex in that area.
It would help if there was a sort of "boundry box" thingy so that the user can estimate which areas would be deleted.
This would increase workflow (especially for my current task where there are a lot of old walls and vertex)

Not sure if it's intentional. But seems like in level.py (line 54), you might be missing an if statement for the key floors.

One would need to make sure floors are defined in the yaml file generated by the traffic-editor as of the current "version" of traffic-editor.

Currently when creating a door, the default is single hinged. To change the type in the Properties dialog box, the user needs to know the correct character string. A drop down of available options would be very helpful!

So, I've been trying to compile with colcon build --symlink-install.

building_map_tools fails with the error message:

stderr: building_map_tools error: can't copy 'building_map_generators/textures/blue_linoleum.png': doesn't exist or not a regular file

I'm really not sure what symlinks do to .pngs It somehow corrupts the pngs?

Below is the screenshot of the .pngs after I run a colcon build --symlink-install

Just running colcon build WITHOUT --symlink-install works fine tho.

After any modification is made to the .building.yaml file using the traffic editor, running building_map_nav on same `.building.yaml' file raises the below error.

  File "/home/yadu/ws_rmf_demos/install/building_map_tools/lib/building_map_tools/building_map_nav", line 11, in <module>
    load_entry_point('building-map-tools==0.0.0', 'console_scripts', 'building_map_nav')()
  File "/home/yadu/ws_rmf_demos/install/building_map_tools/lib/python3.6/site-packages/building_map_generators/building_map_nav.py", line 12, in main
    g.generate_nav(input_filename, output_dir)
  File "/home/yadu/ws_rmf_demos/install/building_map_tools/lib/python3.6/site-packages/building_map/generator.py", line 40, in generate_nav
    building = self.parse_editor_yaml(input_filename)
  File "/home/yadu/ws_rmf_demos/install/building_map_tools/lib/python3.6/site-packages/building_map/generator.py", line 18, in parse_editor_yaml
    return Building(y)
  File "/home/yadu/ws_rmf_demos/install/building_map_tools/lib/python3.6/site-packages/building_map/building.py", line 9, in __init__
    self.name = yaml_node['building_name']
KeyError: 'building_name'

Undo is a feature that all elite software has nowadays.

how to add level?
there is no menu called 'Level'.

Depending on the scale of the image, this can make it impossible to click-to-select a door in between two vertices, because the clicks call within the vertices "capture radius," so you only select vertices, not the door edge between them.

Ticket to keep track of some issues I've come across after #132, especially with regards to backward compatibility of older building.yaml files.

1. Not an issue but just want to highlight that the new model thumbnail directory needs to be set to ~/.traffic_editor/assets/thumbnails. This can be done viaEdit->Preferences in the main toolbar.
2. Opening pre-#132 building.yaml files will not have models populated on the map. This is due to model names being namespaced with OpenRobotics/ in the model list. This can be fixed by manually adding OpenRobotics/ to the names of the model in the building.yaml file.
3. Once model names are manually prepended with OpenRobotics/ in the building.yaml file, the generated .world file contains uri elements with the same namespace for model include blocks. However for demos in rmf_demos for example, the models are stored in rmf_demo_assets/ and not rmf_demo_assets/OpenRobotics/. Hence, these models are not loaded in simulation.

A follow up on #190
First of all, thanks @tanyouliang95 for the fast fix in #191 .
I am facing this error when using both the python script and the plugins directly running with --verbose

[Err] [RenderEngine.cc:538] EXCEPTION: Unable to load Ogre Resources.

Most other models are fine, but those using <script> for <material> will fail.

• Gzserver version: 9.13.1
• OpenCV version: 3.2.0
• Software used to generate the COLLADA file: 3ds max

I have included an example link to download (Not done by me). It works fine in Gazebo World
Here is the link

Updated:
There is also a segfault problem at the end of script. It will be great if that can be resolved.

The ability to "snap to grid" to get straight lines is very useful when creating fresh new layouts or traffic lanes or even when we're tracing to get higher quality layouts.

The feature should ideally include a grid size selection as well so a finer gradient can be used for smaller layouts.

It would be helpful to add ability to sort the list alphabetically or implement that as a default. Currently it appears it is sorted alphabetically within the batches of files as they were added

It would be helpful to allow a character for wild card search or enable it automatically so the relevant models appear at the top of the selection window. Currently it appears to search the exact character sequence

Bug Report

@methylDragon I think this is a small bug to fix
I notice that when I build traffic editor in my pipeline the first time without downloading any models (hence, no ~/.gazebo or ~/.ignition). It will give me the following error.

Starting >>> test_maps
--- stderr: test_maps                              
BUILDING WORLDFILE WITH COMMAND: ros2 run building_map_tools building_map_generator gazebo /home/.../rmf_ws/src/traffic_editor/test_maps/maps/door_madness/door_madness.building.yaml /home/.../rmf_ws/build/test_maps/maps/door_madness/door_madness.world /home/.../rmf_ws/build/test_maps/maps/door_madness/models
Traceback (most recent call last):
  File "/home/.../rmf_ws/install/building_map_tools/lib/building_map_tools/building_map_generator", line 11, in <module>
    load_entry_point('building-map-tools==0.0.0', 'console_scripts', 'building_map_generator')()
  File "/home/.../rmf_ws/install/building_map_tools/lib/python3.6/site-packages/building_map_generator/building_map_generator.py", line 51, in main
    lower=True
  File "/home/.../rmf_ws/install/building_map_tools/lib/python3.6/site-packages/pit_crew/pit_crew.py", line 153, in get_missing_models
    use_dir_as_name=use_dir_as_name, ign=ign
  File "/home/.../rmf_ws/install/building_map_tools/lib/python3.6/site-packages/pit_crew/pit_crew.py", line 245, in get_local_model_name_tuples
    "Path given must be a directory that exists!"

I can work around it by setting NO_DOWNLOAD_MODELS or create a ~/.gazebo directory, but I think it's best this can be addressed properly.

I tried to use thumbnail generator from the traffic editor to add some gazebo models. When I ran

./scripts/crop.py model_list.yaml -o images/cropped -g images/green -w images/white

I got the following message

./scripts/crop.py model_list.yaml -o images/cropped -g images/green -w images/white
generating images/cropped/Nate Koenig/cabinet.png
green image size: 2000x2000
cropped to 124x124

It seems a cropped thumbnail image should have been generated, but when I went to /images/cropped/ the folder was empty. By the way I was able to generate images with green and white backgrounds. I am wondering what went wrong for the cropping step

The current file format is just a random splat of structures to YAML. This was just done to get up and running quickly.

Suggestion by @ablakey to move to GeoJSON seems reasonable due to its use in many existing tools, such as QGIS. At the end of the day we just need to represent some spatial shapes and annotations in some file format.

That will require using JSON parsers in C++ (for the current "offline" Qt GUI) and Python (for the generators). I'm sure there are many options. This one looks nice for C++: https://github.com/nlohmann/json but the goal is to pick one that is already packaged up in Ubuntu 18, so we don't have to do it ourselves, or add another source dependency.

ros2 service call get_building_map building_map_msgs/GetBuildingMap > test.txt => no doors in the output.

Hello!

Would it be possible to model automatic doors ( doors that open on motion detection )? Quite a few doors behave like that, and it might be possible to implement certain scenarios without requiring a "hook" into RMF.

In ticket #125, @webvenky reports that door generation occurs only at z=0 regardless of the Z height of the level it lives in. @aaronchongth can you have a look? Thanks!

Re-use existing polygon tool for floors.