Audit of topics to ensure no cheating allowed

[osrf-migration]

Original report (archived issue) by clalancette (Bitbucket: clalancette, GitHub: clalancette).

---

This issue is to track an audit of the available topics in the SRC to ensure that none of the available topics can be used to cheat.

[osrf-migration]

Original comment by clalancette (Bitbucket: clalancette, GitHub: clalancette).

---

As of today (May 19, 2017), here is the list of topics published/subscribed by the /gazebo node, along with the services in SRC (output from rosnode info /gazebo):

Node [/gazebo]
Publications: 
 * /gazebo/model_states [gazebo_msgs/ModelStates]
 * /multisense/imu [sensor_msgs/Imu]
 * /gazebo/parameter_descriptions [dynamic_reconfigure/ConfigDescription]
 * /task1/checkpoint2/satellite [srcsim/Satellite]
 * /multisense/camera/right/parameter_updates [dynamic_reconfigure/Config]
 * /leftTorsoImu/imu [sensor_msgs/Imu]
 * /multisense/camera/right/image_raw [sensor_msgs/Image]
 * /multisense/lidar_scan [sensor_msgs/LaserScan]
 * /multisense/camera/left/parameter_updates [dynamic_reconfigure/Config]
 * /multisense/camera/right/camera_info [sensor_msgs/CameraInfo]
 * /rosout [rosgraph_msgs/Log]
 * /multisense/camera/left/parameter_descriptions [dynamic_reconfigure/ConfigDescription]
 * /multisense/joint_states [sensor_msgs/JointState]
 * /gazebo/parameter_updates [dynamic_reconfigure/Config]
 * /multisense/camera/left/camera_info [sensor_msgs/CameraInfo]
 * /multisense/camera/left/image_raw [sensor_msgs/Image]
 * /pelvisRearImu/imu [sensor_msgs/Imu]
 * /multisense/camera/right/parameter_descriptions [dynamic_reconfigure/ConfigDescription]
 * /srcsim/finals/task [srcsim/Task]
 * /gazebo/link_states [gazebo_msgs/LinkStates]
 * /pelvisMiddleImu/imu [sensor_msgs/Imu]
 * /clock [rosgraph_msgs/Clock]

Subscriptions: 
 * /multisense/set_fps [unknown type]
 * /gazebo/set_link_state [unknown type]
 * /multisense/fps [unknown type]
 * /valkyrie/harness/detach [unknown type]
 * /multisense/set_spindle_speed [unknown type]
 * /srcsim/finals/task [srcsim/Task]
 * /valkyrie/harness/velocity [unknown type]
 * /gazebo/set_model_state [unknown type]
 * /clock [rosgraph_msgs/Clock]

Services: 
 * /gazebo/apply_joint_effort
 * /gazebo/get_physics_properties
 * /gazebo/set_link_state
 * /gazebo/set_joint_properties
 * /pelvisMiddleImu/imu_service
 * /gazebo/set_model_configuration
 * /leftTorsoImu/imu_service
 * /gazebo/set_logger_level
 * /multisense/camera/right/set_parameters
 * /gazebo/reset_world
 * /gazebo/get_world_properties
 * /gazebo/set_parameters
 * /gazebo/spawn_sdf_model
 * /gazebo/set_model_state
 * /gazebo/unpause_physics
 * /multisense/camera/left/set_camera_info
 * /gazebo/set_physics_properties
 * /srcsim/finals/start_task
 * /gazebo/get_loggers
 * /gazebo/spawn_gazebo_model
 * /gazebo/pause_physics
 * /pelvisRearImu/imu_service
 * /gazebo/reset_simulation
 * /gazebo/delete_model
 * /multisense/camera/left/set_parameters
 * /gazebo/spawn_urdf_model
 * /gazebo/set_link_properties
 * /gazebo/get_joint_properties
 * /gazebo/apply_body_wrench
 * /multisense/camera/right/set_camera_info
 * /gazebo/get_link_state
 * /gazebo/clear_body_wrenches
 * /gazebo/get_link_properties
 * /gazebo/get_model_state
 * /gazebo/clear_joint_forces
 * /gazebo/get_model_properties

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I guess we could probably narrow it down further to topics published by or subscribed by the gazebo node. I think the IHMC controller doesn't have any secret knowledge. I think the main thing we are concerned about is gazebo. I forgot to mention services too; we may want to limit those.

[osrf-migration]

Original comment by Víctor López (Bitbucket: Victor Lopez).

---

I agree with @scpeters that only the topics and services published or subscribed by gazebo should be blacklisted. And not all of them, obviously /clock and the srcsim topics are required. I don't believe that anything ihmc topic publishes anything on the simulation that would not be available on the real robot.

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Out of the topics coming out of Gazebo, the /valkyrie/harness ones should be blocked for the finals. Note that there will be topics created as tasks progress, but I can't think of any which should be blocked.

[osrf-migration]

Original comment by Jeremy White (Bitbucket: knitfoo).

---

Wait - aren't we going to be shortly set up to be able to use the harness messages, if we skip a checkpoint? (ala issue #170).

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

Two types of re-harnessing will be supported:

1. When skipping to a checkpoint
2. When restarting the current checkpoint

The mentioned harness topics allow re-harnessing to any pose at any time, for debugging purposes only.

[osrf-migration]

Original comment by clalancette (Bitbucket: clalancette, GitHub: clalancette).

---

I've now restricted my work to only look at topics that the /gazebo nodes pubs/subs/services.

Looking at the publications, it all seems pretty reasonable, with the exception of:

• /task1/checkpoint2/satellite [srcsim/Satellite]
• /srcsim/finals/task [srcsim/Task]
• /gazebo/link_states [gazebo_msgs/LinkStates]

Looking at the list of subscriptions, it looks fairly reasonable with the exception of:

• /valkyrie/harness/ ( @chapulina has already said these should be blocked)
• /srcsim/finals/task [srcsim/Task]
• /gazebo/set_model_state [unknown type]

Finally, looking at the list of services, the ones that are potentially problematic:

• /gazebo/reset_world (is this something teams should be able to do?)
• /gazebo/set_parameters (what kinds of parameters does this set?)
• /gazebo/set_link_properties (same?)
• /gazebo/set_link_state (same?)
• /gazebo/set_joint_properties (same?)
• /gazebo/set_model_configuration (same?)
• /gazebo/set_physics_properties (could teams change the world physics with this?)
• /gazebo/delete_model (could teams delete obstacles and make life easier with this?)
• /gazebo/spawn_urdf_model (could teams spawn ramps or other things to make life easier with this?)

@chapulina , @scpeters , which of the above topics/services should we block? Once I have your input on these, I'll come up with a final list of topics/services that we need to block for now.

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

• Teams should be able to subscribe to /srcsim/finals/task (not sure if this is possible, but it would be nice to not allow them to publish to it)
• I think anything which starts with /gazebo should be blocked

[osrf-migration]

Original comment by clalancette (Bitbucket: clalancette, GitHub: clalancette).

---

All right, so with the feedback, the following should be blocked:

Publications:
* /gazebo/model_states [gazebo_msgs/ModelStates]
* /gazebo/parameter_descriptions [dynamic_reconfigure/ConfigDescription]
* /gazebo/parameter_updates [dynamic_reconfigure/Config]
* /gazebo/link_states [gazebo_msgs/LinkStates]

Subscriptions: 
* /gazebo/set_link_state [unknown type]
* /valkyrie/harness/detach [unknown type]
* /valkyrie/harness/velocity [unknown type]
* /gazebo/set_model_state [unknown type]

Services:
* /controller_manager/load_controller
* /controller_manager/reload_controller_libraries
* /controller_manager/switch_controller
* /controller_manager/unload_controller
* /gazebo/apply_joint_effort
* /gazebo/get_physics_properties
* /gazebo/set_link_state
* /gazebo/set_joint_properties
* /gazebo/set_model_configuration
* /gazebo/set_logger_level
* /gazebo/reset_world
* /gazebo/get_world_properties
* /gazebo/set_parameters
* /gazebo/spawn_sdf_model
* /gazebo/set_model_state
* /gazebo/unpause_physics
* /gazebo/set_physics_properties
* /gazebo/get_loggers
* /gazebo/spawn_gazebo_model
* /gazebo/pause_physics
* /gazebo/reset_simulation
* /gazebo/delete_model
* /gazebo/spawn_urdf_model
* /gazebo/set_link_properties
* /gazebo/get_joint_properties
* /gazebo/apply_body_wrench
* /gazebo/get_link_state
* /gazebo/clear_body_wrenches
* /gazebo/get_link_properties
* /gazebo/get_model_state
* /gazebo/clear_joint_forces
* /gazebo/get_model_properties

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I wondered if we could just not use the libgazebo_ros_api_plugin.so plugin, which provides topics we don't want, but it provides the /clock topic, which we definitely do want, so it wouldn't be that simple.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I had forgotten that we also spawn valkyrie dynamically using the gazebo_ros API's, specifically the spawn_model script, which uses:

• model_states topic
• gazebo_interface python library, which uses the spawn_urdf_model service

[osrf-migration]

Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).

---

• set component to "cloud"

[osrf-migration]

Original comment by Dirk Thomas (Bitbucket: Dirk Thomas, GitHub: dirk-thomas).

---

If https://osrf-migration.github.io/srcsim-gh-pages/#!/osrf/srcsim/pull-requests/83/add-ros-subscriber-to-force-current/diff gets merged its topic needs to be disabled for the competition.

[osrf-migration]

Original comment by Víctor López (Bitbucket: Victor Lopez).

---

Also all /controller_manager services need to be blacklisted.

We asked at the beginning of the challenge (https://osrf-migration.github.io/srcsim-gh-pages/#!/osrf/srcsim/issues/51/custom-controller (#51)) if we could load our own controllers and the answer was no.

So I believe that to be fair to all competitors who have adapted to use IHMC controller those services should be blacklisted.

[osrf-migration]

Original comment by Deanna Hood (Bitbucket: d_hood).

---

@j-rivero added ros-simulation/gazebo_ros_pkgs#585 to disable most /gazebo topics and services which might be useful to you here. For ARIAC we needed a subset of them enabled (e.g.spawn_urdf_model, unpause physics), so we have a custom branch of gazebo_ros_packages being built in our dockerfiles. from a comment above it sounds like you might have the same requirements for SRC

[osrf-migration]

Original comment by clalancette (Bitbucket: clalancette, GitHub: clalancette).

---

@d_hood Thanks. SRC has the same problem as ARIAC in that most of the topics/services want to be disabled, but not all of them. @j-rivero and I hammered out a proposal to have a blacklist of topics and services that can be specified at runtime, but neither of us has had time to implement it.

[osrf-migration]

Original comment by Jose Luis Rivero (Bitbucket: Jose Luis Rivero, GitHub: j-rivero).

---

From today's gazebo meeting we agree on thinking that is too late to modify the runtime code for SRCSim (dry-run was last week). The approach to detect cheating is going to be different. I will mail you privately @clalancette