-
Notifications
You must be signed in to change notification settings - Fork 12
Ethercat dual can muscle hand
The SW has been developed and tested on ROS Groovy.
The code for the EDC muscle hand has been branched from the branch F_univ_bi_bimanual_system (of the different stacks involved) into F_ethercat_muscle_hand.
At some point it should be merged into development but this has been delayed as it is a merge that will probably require quite a lot of work, as many changes have been done in this branch and in development since they diverged.
The recommendation is to ship this first muscle hand with these branches of the code
shadow_robot
git clone git@github.com:shadow-robot/sr-ros-interface.git -b F_ethercat_muscle_hand shadow_robot
shadow_robot_ethercat
git clone git@github.com:shadow-robot/sr-ros-interface-ethercat.git -b F_ethercat_muscle_hand shadow_robot_ethercat
sr_visualization
git clone git@github.com:shadow-robot/sr-visualization.git -b F_ethercat_muscle_hand sr_visualization
sr_config
For generic changes (i.e. changes that need to be added for any Ethercat muscle hand), they should be committed to this branch (and then merged into the hand-specific branch) :
git clone git@github.com:shadow-robot/sr-config.git -b F_ethercat_muscle_hand sr_config
For changes to this particular hand (shadowrobot_130501) (i.e. calibration and controller tuning params), they should be committed to this branch:
git clone git@github.com:shadow-robot/sr-config.git -b shadowrobot_130501 sr_config
roscore
In a new terminal:
sudo -s
roslaunch sr_ethercat_hand_config sr_rhand.launch
To run the controllers:
rosrun rqt_gui rqt_gui
and open the plugin:
- Plugins->Shadow Robot->Controllers->Change Muscle Controllers
The FW in the muscle drivers can be reprogrammed by using the plugin
- Plugins->Shadow Robot->EtherCAT->Muscle Driver Bootloader
Be careful to choose the correct .hex file for the muscle drivers.
For the moment two controllers have been written for the EDC muscle hand:
- Valve controller
- Muscle joint position controller
These controllers are loaded as plugins in the controller_manager. The user can load and unload the controllers via a service or via the Change Muscle Controllers GUI plugin (that calls the same services).
The controller_manager is part of the realtime loop, and calls the update() function of the running controllers every millisecond.
They allow a user to drive a valve "manually" by publish a message with the structure:
command[0] command[1] duration[0] duration[1]
where the command is an integer between -4 and 4 (and is the value that the controller will send to the muscle driver in the hand) and the duration is the period in milliseconds during which the specified command will be sent. After this duration period expires, a command of 0 will be sent to that muscle.
In its current state this controller is only useful for debugging and test of the hand. And it could probably be used in the pressure sensors calibration process.
This controller receives a joint position command (float64) in radians.
In the update() function calculates the position error.
For the moment this error is fed into a PID loop (exactly as it was done in the motor hand position controller).
A separate set of PID parameters (in the file sr_config/sr_ethercat_hand_config/controls/host/sr_edc_muscle_joint_position_controllers.yaml) has been created and can be tuned through the Controller tuner GUI plugin.
In the current extremely simplistic approach, the output of this PID loop (that could be interpreted as "how much force do we want to apply to the joint) is used to determine which of the two muscles that control the joint should fill and which should empty.
It's marked with a comment that says
// Here goes the control algorithm
The only output of this controller algorithm is a command for every muscle (although I have called the variable valve[] it should be better muscle, as there's one command for every muscle, and every muscle has 2 valves. E.g. the output could be:
valve[0] = -4;
valve[1] = 4;
which would mean that for the following millisecond, the muscle 0 (the flexor muscle) would open the emptying valve for 4 * 0.25 ms (i.e 1 ms) and keep the filling valve closed, and the muscle 1 (the extensor muscle) would open the filling valve for 1 ms and keep the emptying valve closed.
A problem that will have to be faced is the fact that the emptying rate is faster than the filling rate (due to some filters in the air input) so a muscle deflates faster than it inflates.
The use is very straightforward. Only bear in mind that the options it offers are different if the hand controllers are running or not. If they are not running you are in edit-only mode (it allows you to edit the parameters and save them in the files). If the controllers are running you can also change the parameters of the running controllers and move the joints and plot the controller output.
The hand driver is considered to be finished by now, but in case something arises, I'll explain a bit about the structure.
Bear in mind that sometimes in this page the word driver is used as in "muscle driver" to refer to the PIC controlled boards at the base of the hand that drive the muscles
When the hand launchfile for the hand is launched (roslaunch sr_ethercat_hand_config sr_rhand.launch) one of the main nodes it launches is the ethercat realtime loop (pkg="pr2_etherCAT" type="pr2_etherCAT").
This node checks for etherCAT slaves in the bus, and loads the plugin the matches the Product Code of the slave. The plugin that gets loaded for the EDC muscle hand is SrEdcMuscle (sr_edc_ethercat_drivers/src/sr_edc_muscle.cpp).
The plugin SrEdcMuscle instantiates an object SrMuscleHandLib, that does the actual decoding and encoding of the hand data. (sr_robot_lib/src/sr_muscle_hand_lib.cpp)
SrMuscleHandLib inherits from some other classes
SrMuscleHandLib <- SrMuscleRobotLib <- SrRobotLib
Where SrRobotLib deals with the things that are common to all the hand models (i.e. position sensors and tactiles), and SrMuscleRobotLib deals with things that are specific of a muscle robot (i.e. pressures and valve demands). The SrMuscleHandLib class itself adds a few things for the hand (it instantiates the actuators, reads the mappings, etc).
Some pressure sensors show values that don seem to vary with the pressure. This will be investigated by Dan initially. To show the values:
rxplot -b30 -p30 /sh_ffj3_muscle_position_controller/state/muscle_pressure_0 /sh_ffj3_muscle_position_controller/state/muscle_pressure_1
The version of sr_config that is being used, derives from the one made for the bimanual system. Thus, even if we only have one hand, there still are some directories name "lh" which stands fo left hand. The files in there can be ignores if no left hand is used in the project.
The name chosen "lh" could be anything else, as this really is a n-manual hand. I.e. we could have "hand-2" "hand-3" etc as directory names.