search

DFKI-NI / mobipick_labs

Other
4 stars 1 forks source link

tables_demo_planning: Make config file location configurable #25

Closed mintar closed 1 year ago

mintar commented 1 year ago

Currently, the location of the config file (moelk_tables_demo.yaml) is hardcoded:

https://github.com/DFKI-NI/mobipick_labs/blob/b06e91113c6b65cd187423080b069892bae1eef3/tables_demo_planning/src/tables_demo_planning/demo_domain.py#L85-L86

For the CIC demo, we need to change this to the cic_tables_demo.yaml in the same folder. It would be nice if the location (both path + filename) could be configured without changing the code.

alexander-sung commented 1 year ago

Yes, agreed. There are basically two issues here. Firstly, the code here for filename is very deep in the software stack, so it would be cumbersome to accept a console parameter. Instead, a ROS param seems more meaningful. Ideally, I think the mobipick bringup should write this parameter. In simulation it would make sense for mobipick_gazebo when spawning the tables but it needs to be written for the real setup as well, obviously. Second point thus is: Would you handle putting the data onto the ROS parameter server and just let me know where to read from? The ROS parameter could be (probably better) the pose contents themselves instead of the filename.

mintar commented 1 year ago

Would you handle putting the data onto the ROS parameter server and just let me know where to read from?

Done in aea6b066. The poses are now under the /mobipick/tables_demo_planning namespace (e.g., /mobipick/tables_demo_planning/poses/base_handover_pose).

alexander-sung commented 1 year ago

Ah that's great! I was only looking into the mobipick repository so far.

I created the according change for reading it and sent you pull request https://github.com/DFKI-NI/mobipick_labs/pull/27. However, the way of using the parameter server needs to be reflected in the symbolic fact generator, so I created a pull request https://github.com/DFKI-NI/symbolic_fact_generation/pull/5 for @marcvinci as well. Thinking further, maybe we need to handle this duplicate implementation in the two repositories. No sure, though, as it might lead to unwanted dependencies or additional repositories.

mintar commented 1 year ago

Closed via #27.