Project

General

Profile

Cooperation Manipulation Control » History » Revision 9

Revision 8 (Kévin Desormeaux, 2021-06-15 16:16) → Revision 9/11 (Kévin Desormeaux, 2021-06-15 16:27)

h1. Cooperation Manipulation Control 

 h2. Franka_ros 

 To operate the pandas it is necessary to have real-time kernels on the machines running the control stacks. It is the case with the *kukarm* and *truyere* workstation. 
 You should have ROS (melodic version ideally) installed. You will need to also to install *franka_ros* and *libfranka* . 

 <pre> 
 sudo apt-get install ros-melodic-franka-ros 
 sudo apt-get install ros-melodic-libfranka 
 </pre> 

 You are strongly advised to read the franka documentation to begin with. See https://redmine.laas.fr/projects/dual_arm_exp/wiki/Franka_documentation_and_operating_the_Pandas and https://frankaemika.github.io/docs/franka_ros.html. 

 !ros-architecture.png! 

 Basically franka_ros is a collection of package integrating libfranka into ros_control. There is packages for hardware abstraction, to control the grippers, for robots description etc. 

 *Important* : libfranka must have the same versions running on the workstations (kukarm, truyere etc) and on the panda controllers (FCI). Otherwise there will be compatibility issues. 

 h2. CM2C 

 h3. Installation 

 Once franka_ros is installed you can create a catkin workspace in your home directory to install CM2C. See http://wiki.ros.org/catkin/Tutorials/create_a_workspace. 
 CM2C is available here on the mp2_ros repository: 

 https://redmine.laas.fr/projects/m2p2/repository 

 Then you only have to compile your catkin workspace and CM2C can be launched.  
 You might need to install different ROS packages missing on the system.  
 *Important* : your catkin workspace must be built in release mode! By default it might be in debug mode, and CM2C might not be able to run at the desired frequency for real time usage. 

 <pre> 
 catkin build -DCMAKE_BUILD_TYPE=Release 
 </pre> 

 Information on how to use CM2C can be found a bit further in the wiki: https://redmine.laas.fr/projects/dual_arm_exp/wiki/Control_API_functions_description  


 h3. The code 

 All the important code is located in a single file: admittance_joint_trajectory_controller_impl.h. This is where you will find the admittance control law implementation etc. 

 h3. CM2P Inputs 

 CM2C spawns follow_joint_trajectory action servers with the following names: 

 <pre> 
 /panda_1_controller/follow_joint_trajectory 
 /panda_2_controller/follow_joint_trajectory 
 </pre> 

 CM2P send the trajectories to these servers via the dual_arm_controller_api class. 

 h3. Admittance parameters Inputs 

 Those are initialized in admittance_joint_trajectory_controller_impl.h:  

 <pre> 
 // initialize admittance controller parameters 
 admittance_translational_mass_ = 10.0; 
 admittance_translational_mass_target_ = 10.0; 
 admittance_translational_damping_ = 700. 
 admittance_translational_damping_target_ = 700.0; 
 admittance_translational_spring_ = 500.0; 
 admittance_translational_spring_target_ = 500.0; 
 admittance_rotational_mass_ = 50.0; 
 admittance_rotational_mass_target_ = 50.0; 
 admittance_rotational_damping_ = 50.0; 
 admittance_rotational_damping_target_ = 70.0; 
 admittance_rotational_spring_ = 50.0; 
 admittance_rotational_spring_target_ = 70.0; 
 </pre> 

 as well as in a configuration file, admittance_pose_param.cfg in the cfg repository. 
 Originally it was possible to set them dynamically via a rqt_reconfigure GUI, however it was very bugged. 
 You can set them dynamically by using the Admittance_pose_param/set_parameters service. However it will update it to both arms, so you might need to create a dedicated service for each arm. 


 h3. From admittance_joint_trajectory_controller to simple joint_trajectory_controller 

 You might want to not use the admittance gains, and only run a simple joint_trajectory_controller. This can be done by commenting the admittance gains in those 3 lines and compiling after: 

 <pre> 
 desired_state_.position[i] = desired_state_.position[i];// - q_dc_[i]; 
 desired_state_.velocity[i] = desired_state_.velocity[i];// - dq_dc_[i]; 
 desired_state_.acceleration[i] = desired_state_.acceleration[i];// - ddq_dc_[i]; 
 </pre> 

 A reason for that is that we had issues running a place() with the admittance gains. Without it works fine. 

 h3. External forces estimation 

 The admittance control law uses the external forces measurements on the end effector to compute the admittance gains for each joint. 

 h4. The fusedSensorData structure 

 I created this structure to hold all the data from the F/T sensors. This structure is declared in admittance_joint_trajectory_controller.h. 

 !fused_sensor_data.png! 

 <pre> 
 Those are the last values coming from F/T sensors.  

   std::vector<Eigen::Vector3d> O_forces_k; // Those are the forces on the end effector expressed in the base frame. 
   std::vector<Eigen::Vector3d> O_torques_k; // Those are the torques on the end effector expressed in the base frame. 
   std::vector<Eigen::Vector3d> k_forces_k; // Those are the forces on the end effector expressed in the end effector frame. 
   std::vector<Eigen::Vector3d> k_torques_k; // Those are the forces on the end effector expressed in the end effector frame. 
 </pre> 


 This structure contains a fifo to stock the last values coming from the F/T sensors. We use a fifo to get an average on a sliding window and remove some noise. 

 h4. Force/Torque sensors integration 

 For now we use the pandas Force/Torque sensors (FTS) to estimate the forces and torques at the end effector (EEF). The pandas have FTS at the joints, so the forces at the EEF are estimates.  
 If the results are okay, it would be better to dispose of a real FTS placed at the EEF. Those FTS are available at LAAS, we did most of the integration but didn't finish it.  
 You will find a wiki page with all the information regarding these FTS here: https://wiki.laas.fr/robots/Panda 
 From an hardware point of view this is done. The wires have been extended and 3d printed support have been printed to integrate it. You can find the .stl models of these supports by following the link above.  

 From a software point of view we have a C++ library developed by Matthieu, the icub-libs. See https://git.openrobots.org/projects/icub-libs. 
 I developed a ROS wrapper of this library that you can find here: https://redmine.laas.fr/projects/icub_fts_wrapper. 
 You can put the wrapper in your catkin workspace and build it along with CM2C. Obviously you will have to install the library beforehand. 

 You can launch the wrapper like so in a terminal: 

 <pre> 
 rosrun icub_fts_wrapper icub_fts_wrapper 
 </pre> 

 The wrapper will publish on the topic "/icub_fts_wrapper/fts_data" the force/torque sensor data. *As you can see the problem here is that it was made for a single arm and need to be extended to dual arm* by having different topic names etc. A way to do this is to use a launch file with the name of the arm as an argument, and use it to initialize the topic.  

 The work on the wrapper is mostly done but there is a bug regarding the resolution on the Y axis to correct as well as the projection of the forces from the FTS frame to the EEF frame. The translation part is trivial but the orientation part might require more efforts. 

 The wrapper is almost integrated into CM2C. The data structure fusedSensorData implemented in admittance_joint_trajectory_controller.h dispose of a active_sensor variable. By default the active sensor is "Franka", hence we use the pandas sensors. But you can set it after launching CM2C via the service /admittance_joint_trajectory_controller/setFTS. As you can see here again you will need to change the services names as for now we have 1 service for both arms. So instead you will need something like this: 

 /panda_1_controller/setFTS 
 /panda_2_controller/setFTS 

 You will also need in the function update() to read FTS data on the fts_wrapper topics, so for example: 

 <pre> 
 "/icub_fts_wrapper_panda_1/fts_data" 
 "/icub_fts_wrapper_panda_2/fts_data" 
 </pre> 

 and to update the fusedSensorData with it. In the code you can see only the data coming from franka sensors are updated.  

 !fts_cm2c.png! 

 So it is needed here to read the data from the icub_wrapper and to add them to the fusedSensorData structure, fts_Data. Those data must be calibrated into the EEF frame. You can do that either in the wrapper or directly here in the update function but it must be done somewhere.