Perception screen added for the SA#969
Conversation
c7d151c to
0b62878
Compare
| catkin_add_gtest(test_writing_ros_controllers test/moveit_config_data_test.cpp) | ||
| target_link_libraries(test_writing_ros_controllers ${PROJECT_NAME}_tools | ||
| catkin_add_gtest(test_reading_writing_config test/moveit_config_data_test.cpp) | ||
| target_link_libraries(test_reading_writing_config ${PROJECT_NAME}_tools |
There was a problem hiding this comment.
this doesn't belong in this pull request, can you separate it please?
There was a problem hiding this comment.
This PR adds a test to the moveit_config_data_test.cpp, so I renamed the test to be sth more generic.
| * Parameters which may be set in the config files | ||
| */ | ||
| struct OmplPlanningParameter | ||
| struct Parameter |
There was a problem hiding this comment.
rename to GenericParameter or something more descriptive
|
|
||
| /** | ||
| * Planning parameters which may be set in the config files | ||
| * Parameters which may be set in the config files |
There was a problem hiding this comment.
"Reusable parameter struct which may be set in various configuration files"
There was a problem hiding this comment.
"Reusable parameter struct which may be used in reading and writing configuration files"
as that is the main usage of this struct, is that okay?
| * | ||
| * @param parameter name | ||
| * @param parameter value | ||
| * @param parameter comment |
There was a problem hiding this comment.
remove 'parameter' from each line
also, either add a real description for each parameter or remove the @param's part as it doesn't serve a purpose currently
| void addParameterToSensorPluginConfig(const std::string& name, const std::string& value = "", | ||
| const std::string& comment = ""); | ||
|
|
||
| /** \brief This Function for clearing the sensor plugin configuration parameter list */ |
There was a problem hiding this comment.
More concise:
"This Function for clearing the..." -> "Clear the..."
| sensor_plugin_field_->setCurrentIndex(0); | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
great work with this file!!
| connect(ssw_, SIGNAL(readyToProgress()), this, SLOT(progressPastStartScreen())); | ||
| connect(ssw_, SIGNAL(loadRviz()), this, SLOT(loadRviz())); | ||
| main_content_->addWidget(ssw_); | ||
| start_screen_widget_ = new StartScreenWidget(this, config_data_); |
There was a problem hiding this comment.
this should really be in a separate PR...
| PassiveJointsWidget* passive_joints_widget_; | ||
| PerceptionWidget* perception_widget_; | ||
| AuthorInformationWidget* author_information_widget_; | ||
| ConfigurationFilesWidget* configuration_files_widget_; |
|
|
||
| // Load sensors_3d yaml file if available -------------------------------------------------- | ||
| fs::path sensors_3d_yaml_path = config_data_->config_pkg_path_; | ||
| sensors_3d_yaml_path /= "config/sensors_3d.yaml"; |
There was a problem hiding this comment.
add note inside the sensors_3d.yaml files that the filename should not be changed or else the MSA will not detect it
| moveit_setup_assistant::MoveItConfigDataPtr config_data_; | ||
| config_data_.reset(new moveit_setup_assistant::MoveItConfigData()); | ||
|
|
||
| boost::filesystem::path setup_assistnat_path(config_data_->setup_assistant_path_); |
0b62878 to
e8ba21c
Compare
|
@davetcoleman Taken care of all the comments, feel free to review :) |
| @@ -0,0 +1,22 @@ | |||
| # This YAML configuration file holds the default values used for configuring 3D sensors. | |||
| # The name of this file shouldn't be changed, or else the Setup Assistant won't detect it. | |||
There was a problem hiding this comment.
If this is the case maybe we need to keep the same name of the yaml file or is it not needed?
There was a problem hiding this comment.
What name do you mean by "same name"?
There was a problem hiding this comment.
The name of the yaml file "sensors_3d.yaml"
There was a problem hiding this comment.
I'm not sure if I understand correctly but the name of the yaml file "sensors_3d.yaml" doesn't change if thats what you're asking.
| * Reusable parameter struct which may be used in reading and writing configuration files | ||
| */ | ||
| struct OmplPlanningParameter | ||
| struct GenericParameter |
There was a problem hiding this comment.
this should actually be a class since it has member functions (see GStyle guide)
There was a problem hiding this comment.
Yes, i'll be working on that 👍
There was a problem hiding this comment.
I think this struct is just passive.
I mean the member functions that uses this struct are addGenericParameterToSensorPluginConfig() and SensorPluginConfig is a member of the moveit_config_data, so if we made a class all it functions will be just get and set functions and the addGenericParamereter function would still be a function in the movit_config_data class.
Same with getSensorPluginConfig().
Did I get it correctly?
There was a problem hiding this comment.
The controllers screen is also ready, but if this one really needs the struct to be class i'll modify it before I open a PR for it.
There was a problem hiding this comment.
I've made two commits, the first one uses a struct and in the second one I've converted it into a class.
| padding_scale: 1.0 | ||
| max_update_rate: 1.0 | ||
| filtered_cloud_topic: filtered_cloud | ||
| - sensor_plugin: occupancy_map_monitor/DepthImageOctomapUpdater |
There was a problem hiding this comment.
Won't have both of them in the same file end up loading both of them?
There was a problem hiding this comment.
Yes, but we don't put this file on the parameter server, we only use it for holding the default values.
e8ba21c to
af46fee
Compare
|
I need a second +1 from someone @mcevoyandy |
* Added Perception screen * perception used calss instead of struct
|
cherry-picked to melodic |
* Added Perception screen * perception used calss instead of struct
| <!-- This file makes it easy to include the settings for sensor managers --> | ||
|
|
||
| <!-- Params for 3D sensors config --> | ||
| <rosparam command="load" file="$(find [GENERATED_PACKAGE_NAME])/config/sensors_3d.yaml" /> |
There was a problem hiding this comment.
Late, but what was the rationale for not using the "robot specific sensor manager" .launch.xml infrastructure used further on in this file to load the .yaml?
This seems to have deviated from how this worked previously, and seems to make [ROBOT_NAME]_moveit_sensor_manager.launch.xml redundant (but that file is still generated by the Setup Assistant).
* Added Perception screen * perception used calss instead of struct
Description
This perception screen works as the following:
if (package has a 3d sensors config file) loads it into the screen
else load the default values from
moveit_setup_assistanat/resources/config/sensors_rgbd.yaml-name is not final-.when the user leaves the screen, saves the new config values to the
sensors_rgbd.yamlto the package, if the user selectednonefrom the plugin type drop down then no config file is saved.Checklist