In the URDFs it is correct but not in the semantic map.

@airballking Can we get rid of this dependency please? If I just want to use the ground map, rosdep install doesn't work anymore because of this iai_cad_downloader dependency. I don't think such a commonly used package as this should introduce any new dependencies.

When manipulating the drawers (based on their joints) in the kitchen and trying to place objects onto them, they just fall through the drawer.

The drawers thus do not count as collision objects.

It would be nice to have some (very simple for the beginning) bounding boxes as collision objects in the URDF of the new semantic map, so that we could use the map in CRAM for visualization and collision checking, generate fake laser scans in Gazebo, etc.

Generate the COLLADA files of the models added to iai_maps/iai_kitchen/meshes/racks/BoxyToolholder/

The collision environment requires correct object dimensions in the semantic map to properly populate MoveIt!'s internal planning scene. Both, the MoveIt! controllers and (perspectively) Giskard rely on that for collision avoidance (and detection, thereof).

Right now, only selected counter tops have dimensions defined. See the attached image for details:

Green is correctly defined, red and grey are not.

This can evolve into a potential show-stopper. @bbrieber, how's your schedule? Would you be able to fill these details in? Alternatively, can you help, @gaya-?

Currently, the semantic map that is loaded by the semantic map utils Prolog package is hardcoded. This should be parameterizable, e.g. using the room's address or by giving a specific map instance as argument.

• kitchen_island object should have holes in front where the drawers are.
• oven_area_area should have a holes in the front where the drawers and the over is, otherwise a robot cannot put anything into the oven.
• oven_area_left_drawer_main and oven_area_right_drawer_main should have no side walls otherwise one cannot put anything into that drawer.
• sink_area should have no front wall, otherwise one cannot put things into the dishwasher

this is how it looks when generating marker from within knowrob:

The sink components are not appropriately modeled:

• tap has as parent side_B, it should be sink
• there is a rotational joint between tap and sink (the tap can be rotated)
• the tap has a handle component, there is a joint between handle and tap
• the parent of sink is side_B. should it be island_countertop instead?

the link coffee_table_drawer has no handle child, and the handle is not baked into the mesh.
I suppose this is an error?

• i created an urdf for tool_holder and spoon_adapter and wanted to visualize them on rviz.
• it turned out that the mesh of the tool_holder is bigger than the meshes of the whole iai kitchen
• could you please double check the scale of the meshes

The robot state publisher doesn't support tf_prefix anymore, but there is a pr open to add it back ros/robot_state_publisher#139.
The pr doesn't add a / anymore, so you need to add the / to the tf_prefix in the launch files, if you are using the pr.

• Each window should have its own frame and mesh
• parent frame is the wall
• if we ever want to open a window with a robot, the joints of the windows should be modeled too

And they are crucial for operating this thing. e.g. opening only via pressing the button

Generate the COLLADA files of the models added to iai_maps/iai_kitchen/meshes/racks/BoxyToolholder/

See noetic migration notes here and an issue here

xacro doesn't allow un-prefixed keywords anymore. Until noetic, xacro merely printed deprecation notes, which now causing failures. E.g. the iai_kitchen_defs/room/room.urdf.xml doesn't work with xacro anymore.

Todo

• Add xmlns:xacro="http://www.ros.org/wiki/xacro" to the variables at the top of the xml
• Add xacro: in front of every macro
• Check file translations into urdf with xacro any.urdf.xml

For sink_area and island_area in the kitchen OWL file add a link of type CounterTop, which should be a child of SupportingPlane from the knowrob.owl ontology.

Currently shelves and e.g. mounting bars are not modeled in URDF.
Some of the shelves where drawers are placed might be irrelevant in most cases,
but some that can serve as putting down location should be modeled.
Also the mounting bar of the wardrobe where the jackets go.

@gaya- @artnie
After updating iai_maps repo, the kitchen seems visualized wierdly in openEASE. May that be because of recent changes in colladas?

the urdf library used by knowrob cannot handle xacro statements, thus the apartment.urdf file must be compiled by xacro.
either the file should be uploaded into github, or we do it compile-time.

side-note: shouldn't have the apartment.urdf file have the ending "xacro"?

the handles should be modeled separated from the door.
currently they are backed into door model and don't have their own TF frame.

The representation of joints in the old and new maps is completely different.
The old maps had more information, such as min and max joint angles etc.:
https://github.com/code-iai/iai_maps/blob/master/iai_semantic_maps/owl/room.owl#L392
It would be nice to have that in the new map as well.
In the new map the only information about joints is the succeedingJoint property, which does not specify to which link the joint actually connects:
https://github.com/code-iai/iai_maps/blob/master/iai_semantic_maps/owl/kitchen.owl#L67

• move all meshes from this repository into "cad_models"
• use the service (Benjamin and Daniel know about) to automatically download the needed ones

This is still a rosbuild package. Does it make sense to catkinize this? It looks like it's build some prolog code and depends on a package ias_knowledge base. So I cannot really judge what's going on and the state..

@bbrieber Just putting it here for you to tick out when you're done, so others (me :) ) also get a notification.

e.g. the armchair can be moved around. It would be good to mark where it should be according to the URDF to avoid problems when objects were moved.

it seems the collada meshes lack color information

The maps have names such as "map", "map2" or "map_restricted" that do not say much about their content or the date at which they were recorded.

• cooktop should have 4 children, one for each hotplate
• it should have parent island_countertop, but it has side_B as parent

There is a dishwasher_drawer_middle frame. But there does not seem to be a model of the dishwasher yet.

Is the dishwasher really gonna fit in the drawer? Or is it a drawer used in the dishwasher?