1、How to get Jacobian matrix when the external force is not on the end-effector ?

（Q）Hello everyone,

I am working on robot anti-disturbance test. Could anyone give me some guidance how to get Jacobian matrixwhen the external force is not on the end-effector, e.g. on the elbow joint or any part of robot arm except on the end-effector?

Thank you.kind regards,John

（A）Hi John! Anti-disturbance tests, fantastic! You may find this tutorial (http://sdk.rethinkrobotics.com/wiki/Baxter_PyKDL) on the Wiki useful. It introduces the baxter_pykdl package, which calculates Baxter's forward and inverse kinematics, and Jacobian. That repo's package can be found here (https://github.com/rethink-kmaroney/baxter_pykdl).

Inside the baxter_pykdl package, there is the baxter_pykdl.py python script that actually calculates the Jacobian matrix for a given kdl chain. You could modify the baxter_kinematics class' self._tip_link from the current self._tip_link = limb + '_gripper' to the link you desired to act upon with an external force. Then simply call the baxter_kinematics class' member function jacobian to return your desired jacobian matrix.

（Q）Hi Ian,Thank you for your useful information that will help me carry on my test on baxter robot.

I want to get the jacobian equation when the external force is not on the end-effector, that is, on the other point of baxter arm. so that I can estimate which joint is disturbed without visual feedback or contact sensors.

Do you have related papers on jacobian equation derivation that's not based on end-effector?

Thank you!Kind regards,John

（A）Hi John,If I understand your requirements correctly, it seems that you are interested in the robot's joint torques. To find a disturbed link, you could take the difference between every joint's commanded torque and measured torque to determine which joints are being affected by an external force. If that approach makes sense, I recommend reading through the Joint Torque Control tutorial (http://sdk.rethinkrobotics.com/wiki/Joint_Torque_Springs_Example) and code walkthrough (http://sdk.rethinkrobotics.com/wiki/Joint_Torque_Springs_-_Code_Walkthrough). You will likely want to use the Interfaces of Limb.set_joint_torques(<double>) to set your desired joint torque. Then you can subscribe to Baxter's /robot/joint_states topic to get the current torque of each joint. The torques are labeled "effort" inside that topic. The beauty of Baxter being a series elastically actuated robot is that these efforts are joint torques rather than motor efforts!

I hope this helps!

~ Ian

（Q）As for the torque control mode, is it based on feedforward control or computed torque control?

（A）Hi John,Our implementation of torque control is based on directly measured torque. We have a magnetic spring deflection circuit embedded within the spring that links the motor and output. The deflection of the spring is measured and then the torque controller attempts to deliver enough current to the motor to make the deflection sensor match the desired output torque. Using this torque control mode comes with the caveat that both collision avoidance (robot arm vs robot arm/head) and collision detection (robot arm vs environment) are disabled since you are intentionally commanding a torque (see http://sdk.rethinkrobotics.com/wiki/Arms#Joint_Torque_Control for the control flowchart).Hope this helps!

（Q）Hi Ian,I tried to move Baxter robot arm joints to a desired position in the torque control mode, but the result is not desirable. e.g. I reset start_angle['right_w1']=1.2 as the start_angle, run the example torque control : rosrun baxter_example joint_torque_control.py -l right. the feedback of current_angle=1.26, and cmd['right_w1']=-0.125. if start_angle['right_w1']=0, current_angle=0.578, cmd['right_w1']=-1.568 Only I run the example torque control without any changing, it can keep its position with about 0.001 error, and the command torque is almost 0. Could you give me any suggestion on the improvement of position precision during torque control mode especially in continuous position trajectory. I hope it can implement 'position playback function' in the torque control mode so that I can control stiffness at the same time.BTW, according to http://sdk.rethinkrobotics.com/wiki/Arms#Joint_Torque_Control , the feedback joint effort[joint] = (cmd[joint]+gravity_compensation_torque[joint])*Scaling， is it right?

Thanks so much.Looking forward to your help.Kind regards,John

（A）Hi John,Glad to see you're making progress with using torque control. I am not sure I understand your question. From what you're telling us, it seems you're able to command the arm to stay in the default position in the package baxter_examples/scripts/joint_torque_springs.py, but as soon as you change the starting angle it no longer gives the necessary torque to maintain its position. Is this correct?Can you share some of your code, and give us an idea of what you intend your code to accomplish?Thanks!~ Ian

If you'd like to implement position control using the torque controller, perhaps consider an approach using a PID loop that checks the positions of the joints and applies a torque based on their displacements at each interval.

FROM:https://groups.google.com/a/rethinkrobotics.com/forum/#!searchin/brr-users/collision$20detection$20baxter|sort:date/brr-users/4xKm_yKyTz4/Eagrwj9e6A8J

2、Is there a topic where Baxter publishes when a collision/exceeded torque/any-thing-related occurs?

Q:rostopic list

$ rostopic list

(let us know if you have any questions in particular here)

Collision Avoidance

/robot/limb/<left/right>/collision_avoidance_state

of message type baxter_core_msgs/CollisionAvoidanceState

Collision Detection

/robot/limb/<left/right>/collision_detection_state

of message type baxter_core_msgs/CollisionDetectionState

使用：rostopic echo /robot/limb/left/collision_detection_state测试灵敏度不高！！！

查看API:http://sdk.rethinkrobotics.com/wiki/API_Reference声呐点云生成？

3、URGENT - Torque control and collision detection

Q:Hi,Today we make a experiment with the real Baxter and now I'm not sure if the automatic collision avoidance (and the other safety stuff) works with all the control modes or only with position control? Our experiment was to send a zero (actually was 0.1) torque (using the example file joint_torque_springs.py) to all right arm joints using the torque control mode. Then the arm went crazy and actually almost hit the Baxter head / display (we hit the red button just before that). We could see that Baxter was invading the "collision force field" because it was very hard to find a way to hold the cuff to reposition the arm again (the cuff was too near the display and behaved avoiding collision after re enable).

A:HI Ricardo,Torque control mode is an advanced control mode. This control mode uses a very lightweight interface by which it directly passes torques (within limits) to the joint controller boards (JCBs). By doing this it does not get passed through the same channels by which we add, or modify the input signal, to apply collision avoidance. This mode should be used with caution for obvious reasons.As for why arm is drifting when only applying gravity compensation torques, please see this previous answer thread.

Q:The actual torques for the arm to stand in a still position are not zero, as you might have guessed. Try rostopic echo /robot/joint_states to get a feel for how much torque each joint has in a neutral still position before doing torque control.

A:Hi Pedro,Maybe I was not clear in my exposition. When I said the arms "went crazy" I meant the arms start to behave like zero gravity or negative gravity with turbulence :)I wrote an "URGENT" in the post subject because I didn't know that using torque control the safety would be disabled automatically (or I have found a bug).I was expecting that sending zero torque to all joints the arms:

1) should rest just like when the robot is disabled or

2) the arms should keep the same position (gravity compensation)

Q:Hi Mo,This was very helpful indeed. Thanks! Regarding the gravity compensation torques, is there a way to read them?

As of the 0.7 release, the gravity compensation torques are now available on the topic '/robot/limb/<left/right>/gravity_compensation_torques' of message type baxter_core_msgs/SEAJointState.

The fields of this message:

position: commanded position

velocity: commanded velocity

effort: commanded effort - in torque control mode this will be the torques you command. In position control mode this is the integral effort applied achieving the goal positions.

gravity_model_effort: gravity compensation torques commanded

hysteresis_model_effort: spring compensation torques commanded

crosstalk_model_effort: crosstalk compensation - minimal value I previously failed to mention, compensating for joint s1 crosstalk.Are the joint efforts (returned from Limb.joint_efforts) the total efforts applied by the motors?These are the total efforts applied as *measured* by the SEA - torque measured. This is in addition to the *measured* joint positions, absolute encoders at the joints, as well as the calculated velocities given the measured positions.The total *commanded* position/velocity/torques are available on the topic '/ref/joint_states'.Let's say the limb is following a trajectory during which I push the limb. Are the joint efforts the ideal torque computed by the dynamics to follow the trajectory or they are the addition torques applied by me to the limb body? Hope I am clear, please let me know?I believe the above answers your question (let me know if this is not true). You have available all of the efforts/positions commanded and measured.

Hope this helps!

4、Torque control is not commanding the right torques

Q:Hi all,I'm trying to control the torque usign the torque control mode but I'm facing some difficulties. I report two different situations I tried.

1 --- Gravity compensation OFF, I specified all torques equal to zero. Via rostopic echo robot/limb/<left/right>/gravity_compensation_torques' , I can see that the commanded_effort are all equal to zero ( what I want) --> PERFECT!

2 ---Gravity compensation ON, I specified all torques equal to zero. Via rostopic echo robot/limb/<left/right>/gravity_compensation_torques' , I can see that the commanded_effort are not all equal to zero, but they assume other values. I should read under commanded_effort the torque I am specifying to the joints (or the gravity compensation model torques), instead here I'am reading totally different values. --> WHY?How is it possible?

Thanks,Stefano

A:Stefano,I am also using Baxter and tried using torque control. I too had similar findings. Unfortunately, I couldn't get any satisfoactory response from Baxter team as well. It seems that Baxter Torque Control is bit complex. Also, the inertia matrix and other parameters are not exactly same. I also noticed that the spring hysteresis coefficients aren't same, which was generating different torques for each arm.I did long analysis on each parameter and compared with input torques as well. unfortunately, I couldn't conclude much. Although few things match with Gazebo simulator but it doesn't work well in the real robot.I hope to hear something positive here.

Cheers!

A:I have been doing torque control on the real robot successfully. You should definitely run the arm calibration scripts, and importantly, make sure you level the robot with an external level (the bubble level built-into the back of the robot is meaningless).

Note that you will not see the same compensation for each arm, as they will have slight differences based on the calibration. If your arm is poorly calibrated it's hopeless, and you'll see some unintended behavior.

If you try to send zero torque, it's very likely the arm will start to drift around. This is due to errors in the gravity compensation, and given the limits of getting a good gravity model with the encoder noise and spring approximation, you will likely not be able to get a stationary arm by passing zero torque. You will need at least a low-gain position controller to keep it at rest.

I've found that I can get slightly better gravity compensation by hacking it a bit: I just scale the computed gravity compensation by some factor, and manually tune that factor until I get the behavior I want. This seems to overcome some calibration error, but you have to retune it if you recalibrate.

A:Hi Adam,Thanks for your reply.

I already followed the calibration and tare procedure, running those scripts, and also levelled the robot. I know the are problems releated to the gravity compensation model that is not perfect, so commanding zero torques the robot will start to drift around. My question is related to the fact that when I'm commanding certain values of torque, via rostopic echo robot/limb/<left/right>/gravity_compensation_torques' I see other values under commanded_effort (not the torques that I want to command), when the gravity compensation model is ON. How is it possible? I'm aspecting that the commande_effort (by definition) is always equal to the torque I want to provide.

For example if I want to command all torque equal to zero, then I'm aosecting to read all zeros under command_effort in rostopic echo robot/limb/<left/right>/gravity_compensation_torques' , but I tried and it is not true, why?

Can you please try to specify on your Baxter some torques and check in rostopic echo robot/limb/<left/right>/gravity_compensation_torques' the values of the commanded_effort?

Thanks,Stefano

A:Anyone able to explain why the rostopic message is not returning the values of the torque I am actually commanding?

Q:Hi all,I fixed the issues with the torque commanded with and without the gravity compensation, in the sense that the commanded torques are the specified one now!

I would like to implemente a force control (a kind of impedence control) controlling the torques of the joints. For that, I cannot implement a position control (P, PI, PID) because I want the end-effector to exert a certain force, not to reach a certain pose at each iteration step. The point is that the torque control is not precise (the gravity compensation model is not perfect, the joint present variable friction inside, ...) so when I'm commanding a certain torque the result is not what I am aspecting.

The torques are obtainign premultipling the desired Wrench with the jacobian transpose.

FROM:https://groups.google.com/a/rethinkrobotics.com/forum/#!topic/brr-users/NP5sP5Muz0k

baxter官网：Joint Torque Control

Joint torque control mode is an advanced control mode. In torque control mode, we specify joint torques at which we want the joints to simultaneously achieve. Typically this will be consist of seven values, a commanded torque for each of the seven joints.

JointCommand.msg mode: TORQUE_MODE

This joint command is then subscribed to by Baxter's Motor Controller. The motor controller processes this joint torque command and expected behavior by making the following modifications, taking special note of the absence of collision avoidance and detection modules:

Note: As shown in the above image, joint torque commands are applied in addition to gravity and spring compensation torques. This default can be disabled by publishing an std_msgs/Empty message on the topic: /robot/limb/right/suppress_gravity_compensation at a rate > 5Hz.

Warning: Advanced Control Mode. When commanding in torque control mode, access is granted to the lowest control levels. This puts much responsibility on the control program and can be dangerous. Please use with caution.

6、gravity compensation torque

Q:Hi,

I am interested in getting and analyzing torque data of Baxter robot. According to my knowledge torque data can be output using the two rostopics "/robot/joint_sates" and "/robot/limb/side/gravity_compensation_torques". I am wondering what is the relationship between the effort from first rostopic (/joint_states) to commanded_effort, actual_effort, gravity only from rostopic(/gravity_compensation_torques).

Any help would be highly appreciated.

Sincerely,

Anirban

A:Hi Anirban,probably these two topics could help you (here and here). (见7和8)

7、Commanded torque and measured torque

A:Hi all,

I'm trying to develop a fault diagnosis scheme based on observators on Baxter, thus I need the input and output measurements of the joints. I read this discussion https://groups.google.com/a/rethinkrobotics.com/d/msg/brr-users/d5xEVsdws5g/a6pasrQzBZoJ where the torque measurements are explained, but I remained a bit confused. Referring to the figure below, I need to know the value τc which is the torque computed by the JCB and commanded to the joint. If I understood well, this value is available through the topic /robot/ref_joint_states, while the measured torque τmis available through the topic /robot/joint_states. Am I right or I'm missing something?

Q:Hi Daniel,You are correct in saying that τm always available on the /robot/joint_states topic. τc is a bit more nuanced in that it depends on your control mode:

In Position Control (and raw Position Mode) mode, τc is composed of a Feed Forward Torque (computed at the MotorController level) and the Feedback Torque (computed at the JCB level). The Feedback Torque is not supplied to the user, and only the Feed Forward Torque from the MotorController is available via the /robot/limb/<left/right>/gravity_compensation_torques topic: http://sdk.rethinkrobotics.com/wiki/Gravity_Compensation

When you are using Torque Control Mode, no additional Feedback Torque is added at the JCB level, and τc can be computed from your JointCommand over ROS and the Gravity Compensation (Feed Forward Torques).

Hope this helps!

~ Ian

A:Thank you Ian for the reply, you've been very helpful. In position control mode the feedback (unknown) and feedforward (known) terms are only added, i.e. τc = τff + τfb? Or are there also other operations, like a scaling factor?

FROM:https://groups.google.com/a/rethinkrobotics.com/forum/#!msg/brr-users/bnMX_ggTsHY/QWzkiYW_AAAJ

8、PID gains

Q:Hi all,I wonder if there is a way to read/write the PID gains for the low-level joint (velocity/position) controllers? are we able to modify them from the SDK side through ros?

Thanks,--M

A:Hi Mo,Communication works like so, dev_station->on-board computer->JCBs(Joint Controller Boards). The JCB gains for position control are not shared/adjustable. Integrating velocity to position space is how velocity is commanded to the JCBs and in turn the motors.Can you explain your needs/desire why to do this?Another alternative is to use joint torque control to write your own controllers giving you free reign over all of this.

I hope this helps!

Kyle

A:Thanks Kyle. We are developing a control at the high level (dev workstation) for which we need to play with (loosen) the low-level controller gains.As you also suggested and after posting my question, we tried the joint torque control today (thanks to the new 0.7 SDK which facilitates this). It seems to work OK. However, we noticed that when we send zero torque, certain joints still keep moving. I suppose it is because of off dynamics not doing a good gravity compensation job? am I right?
Thanks,--M

A:Hi Mo,

Thanks Kyle. We are developing a control at the high level (dev workstation) for which we need to play with (loosen) the low-level controller gains.

Interesting! I will speak with our low level controls engineers to discuss this use case.

As you also suggested and after posting my question, we tried the joint torque control today (thanks to the new 0.7 SDK which facilitates this). It seems to work OK. However, we noticed that when we send zero torque, certain joints still keep moving. I suppose it is because of off dynamics not doing a good gravity compensation job? am I right?

Great! When commanding zero torques, by default, only the gravity compensation torques are applied. This consists of torques applied due to the inertial properties of the limb (KDL gravity compensation), as well as torques applied to compensate for the S1 spring (large external black springs attached to joint S1 which themselves passively compensates for the limb mass).

This current gravity compensation model is not perfect, and we are currently working on making this better. I suspect you are seeing some slow drift on a few joints from what you would expect. This is due to slight imperfections in our torque measurements (noise) and calibration. To get the best results out of gravity compensation, please run the calibration routine: calibrate_arm.py, reboot, tare.py, reboot. This will get the torque measurements/spring compensation in their best state and should provide the best results (you should still expect some drift). Overall, this drift should be relatively minor, having a low impact on your position/velocity controllers.

Also available to you is the ability to disable gravity compensation completely by publishing an std_msgs/Empty message to 'robot/limb/<left/right>/suppress_gravity_compensation topic at a rate > 5Hz:

$ rostopic pub -r 10 /robot/limb/left/suppress_gravity_compensation std_msgs/Empty

I hope this helps!

Regards,

A-AND-Q:Hi Mo,

This was very helpful indeed. Thanks! Regarding the gravity compensation torques, is there a way to read them?

As of the 0.7 release, the gravity compensation torques are now available on the topic '/robot/limb/<left/right>/gravity_compensation_torques' of message type baxter_core_msgs/SEAJointState.

The fields of this message:

position: commanded position

velocity: commanded velocity

effort: commanded effort - in torque control mode this will be the torques you command. In position control mode this is the integral effort applied achieving the goal positions.

gravity_model_effort: gravity compensation torques commanded

hysteresis_model_effort: spring compensation torques commanded

crosstalk_model_effort: crosstalk compensation - minimal value I previously failed to mention, compensating for joint s1 crosstalk.

Are the joint efforts (returned from Limb.joint_efforts) the total efforts applied by the motors?

These are the total efforts applied as *measured* by the SEA - torque measured. This is in addition to the *measured* joint positions, absolute encoders at the joints, as well as the calculated velocities given the measured positions.

The total *commanded* position/velocity/torques are available on the topic '/ref/joint_states'.

Let's say the limb is following a trajectory during which I push the limb. Are the joint efforts the ideal torque computed by the dynamics to follow the trajectory or they are the addition torques applied by me to the limb body? Hope I am clear, please let me know?

I believe the above answers your question (let me know if this is not true). You have available all of the efforts/positions commanded and measured.

Hope this helps!

Kyle

Q:Wonderful! Yes, that answered all my questions. Thanks again for your time.

9、Several problems about Baxter torque mode

Hi，all !

Though there are already several questions about torque mode in google group, I still encountered some problems about this.

1. In torque mode, if I suppress the gravity compensation(by constantly publishing a empty msg to the associated topic), is it true that both gravity and S1 spring compensation are turned off?

2. Since I want to apply my adaptive control algorithm to the manipulator(asuming that the loads held by the hand may be variable),i prepare to build a dynamic model of the manipulator,which contains M(q) C(q,qdot) G(q) matrices. But i don't know how to compensate the S1 spring by myself. Can i leave the gravity compnsation on and use only M(q) C(q,qdot) matrix in my dynamic model? And is the inertia tensor in URDF expressed in the body attached frame?

3.If i am true,S1 spring compensation is done only by add a torque T = T(q_S1),the torque is a function of only S1 angle.(because i find that there is an item called hystersis_model in seajoint_states msg,this item is a something like [0 torque_s1 0 0 0 0 0]) But it seems that S0 is also affected by the S1 spring?

4.After i turned off the gravity compensation, then i send zero-torque vector to jointcommand topic, the limb should be static.However,it moves. In torque mode, I am confused that isn't it true that T = T_jointcmd +T_grav_compen + T_S0_compen,where T is the total reference joint torques for SEA ,T_jointcmd is the torques by joint_command topic,the last two represent the compensation torques of gravity and S1 spring.

5.By testing,in torque mode, the torques published ref_joint_states topic is just T_jointcmd, not T. So i just don't know how to acquire T.

6.Since the torques in torque mode are just applied to be a reference inputs for the joints,I want to know that if it is possible to control the motors directly in all the 7 joints.

7.Anybody use matlab/simulink to control Baxter? The seajoint_states msg-type in matlab is the old version,and I cannot change the items inside,so in simulink I cannot subscribe to /robot/limb/left/seajoint_states topic.I want to know how to change the msg-type.

Thank you!（无回复）

Robot Subscriber	Effect of Publishing std_msgs/Empty at >= 10 Hz
suppress_collision_avoidance	Prevents self-collision bubble torques from being applied
suppress_cuff_interaction	Prevents enabling ZeroG mode when the cuff is grabbed
suppress_gravity_compensation	Prevents adding torques to counteract the force of gravity
suppress_contact_safety	Prevents motion-interruption when any impact is detected
suppress_hand_overwrench_safety	Prevents motion-interruption when a large wrench is experienced w.r.t. the endpoint frame

10、Inverse dynamics API

Hi Nathan,

You have several insightful questions here. I will answer them inline:

From what I gather, the joint_trajectory_action.py code uses inverse dynamics with position control by publishing position commands on

/robot/limb/<right|left>/joint_command

with mode = JointCommand.RAW_POSITION_MODE,

while simultaneously publishing inverse dynamics commands on

/robot/limb/<right|left>/inverse_dynamics_command

If I'm interpreting that right, it seems like those contributions are combined by the lower level subscribing controllers in Baxter's realtime loop. Is that correct?

Yes, the realtime_loop is listening to both the joint_command and inverse_dynamics_command topics when in RAW_POSITION_MODE. Both topics (with joint_command<pos> and inverse_dynamics_command<vel,accel>) are required for RAW_POSITION_MODE to move the arms fluidly.

Can multiple control commands be combined this way in general? For instance, in joint_trajectory_action.py, the position_w_id mode uses position control with inverse dynamics, but it's common to also use velocity terms as well. Is it possible to add a velocity term by simultaneously publishing velocity commands?

The inverse_dynamics_command only affects movement in RAW_POSITION_MODE. Velocities are supplied for the Inverse Dynamics calculation. VELOCITY_MODE is independent of this mode, and only uses the velocity portion of joint_command.

Is the inverse dynamics functionality usable independent of position control? For instance, can it be combined with torque control?

Inverse Dynamics functionality it is only ever used in RAW_POSITION_MODE. Torque control mode is unaffected by inverse dynamics commands.

Or, more generally, is there a way to leverage the build in inverse dynamics while running torque control if we have a corresponding desired acceleration signal? Or do we need to use KDL or another library for that? (I saw mention on a separate thread of some comparisons between KDL gravity compensation calculations and the internal gravity compensation calculations, so it sounds like some are using that anyway.)

You could build an Inverse Dynamics controller with Torque control mode. You would calculate the Inverse Dynamics commands with respect to a desired Torque, and then pass this as a command to the realtime_loop as a Torque command. I anticipate this would require a fair amount of work (and tuning), but I'd be incredibly interested in trying the resulting code.

I noticed it uses JointTrajectoryPoint messages, and the joint_trajectory_action.py code fills in its positions, velocities, and accelerations fields. Is it right to assume that this computes torque = inverse_dynamics(positions, velocities, accelerations) and isn't using positions/velocities as set points in any way?

That is correct. If you are in RAW_POSITION_MODE and joint_command and inverse_dynamics_commands are not in sync, you'll see the arms move as you commanded in joint_command, but the movement will be very jerky (because the inverse_dynamics calculation is off). When they are in sync, the trajectories are smoothly executed.

Also, the code sets the "time_from_start" field. How is that used internally? It's odd that these are given a time_from_start but the position commands aren't? (It looks like it's actually being used to measure the time delta from the last knot point of the spline in this particular server.)

Even though I populate it in the python JTAServer, time_from_start is actually not used by the realtime_loop. Only the velocity and acceleration fields are used, and only if the arm is in RAW_POSITION_MODE. Both joint_command and inverse_dynamics_command must be received within 0.05 seconds from one another, otherwise the Inverse Dynamics commands are not used.

Also, there's an extra "effort" entry in JointTrajectoryPoint messages unused by the code. Can that be used to send a bit of extra feed forward torque? Or is it ignored by the underlying realtime controller?

This is ignored by the realtime_loop.

And just one more question. It seems like the /robot/limb/<right|left>/inverse_dynamics_command topic is ignored by the simulator by default. Is there a way to turn it on?

Aha, I have not implemented Inverse Dynamics in baxter_simulator. In fact, baxter_simulator's "RAW" position mode is just position mode. I would gladly take this as a pull request improvement.

I hope this helps clear up some of your questions. Let me know if pieces are still unclear.

Best,~ Ian

11、baxter torque control and need calibration?

Q：Hi there,

I begin to do some torque control researches on baxter. But when I just use the command (set_joint_torques) to give the zero values to all joints (s0,s1,...,w2=0) , the baxter will begin to move.Why?

My thought:

In the topic (/robot/limb/right/gravity_compensation_torques) I find that the actual effort is not equal to the gravity_model_effort .

Do we need some calibrations on the controller (adjust some gains like PID)?

Or do we need to write a controller (like PID controlled using errors between actual_effort and gravity_model_effort ) ourselves to keep limb static?

Could we get the code about joint position controller?
So we can use the code to get value of the commanded torque, which can keep the limb stay?

Thanks.
Kind regards,
Patrick

A:Hi Patrick,
There are a couple of things to watch out for with Torque Control mode.

The first is to make sure that you've got a good calbration model for Baxter. This is accomplished by leveling the robot using the screw feet on its base, then running the Calibrate and Tare programs. Torque control depends on accurate calibration of the Spring Deflection Sensors - http://sdk.rethinkrobotics.com/wiki/Arm_Calibration
Next, make sure to publish joint torque commands at a minimum interval of 0.2 sec or Baxter will automatically switch back into position control mode: http://sdk.rethinkrobotics.com/wiki/Arm_Control_Modes#Joint_Control_Fundamentals
You'll likely want to publish as fast as possible to get your controller to behave smoothly ~800Hz->1KHz

It would not be surprising that even after these steps, you still have the arms drift up when commanding 0 torques on every joint. One possible cause could be an inexact Gravity Compensation Effort model. You can disable these torques, but the arm will become heavy under its own weight. Instructions for doing are here:
http://sdk.rethinkrobotics.com/wiki/Gravity_Compensation
Alternatively, you can do this programmatically using rospy:

 import rospyfrom std_msgs.msg import Emptyside = 'left'rospy.init_node("disable_gravity")print("Suppressing Gravity compensation for the {} arm...".format(side))gravity_topic='/robot/limb/{}/suppress_gravity_compensation'.format(side)gravity_pub = rospy.Publisher(gravity_topic, Empty, queue_size=10)gravity_msg = Empty()start = rospy.Time.now().to_sec()def suppress_gravity_compensation(event):gravity_pub.publish(gravity_msg)rospy.Timer(rospy.Duration(0.1), suppress_gravity_compensation)

If you still experience movement when commanding zero torques, even with gravity compensation disabled, then it is likely that some of the spring deflection sensors are reporting zero torques when experiencing non-zero torques. In order to account for these sensor offsets, you'll need to write a position control loop around your torque control. For some ideas on how you might implement a position or velocity controller around torque control, I'd recommend looking at the joint_torque_springs example in baxter_examples: http://sdk.rethinkrobotics.com/wiki/Joint_Torque_Springs_-_Code_Walkthrough
I hope this helps!
~ Ian

Baxter robot 碰撞检测相关问题集合（自己学习用）相关推荐

解决vue的所有相关问题集合
解决vue的所有相关问题集合第一步:配置path npm config get prefix 复制得到的路径信息,去到桌面>右键计算机>属性>高级系统设置>环境变量在系统变 ...
【LWIP】LWIP协议|相关知识汇总|LWIP学习笔记
这里作为一个汇总帖把,把以前写过的LWIP相关的博客文章汇总到一起,方便自己这边查找一些资料. 收录于: [LWIP]LWIP协议|相关知识汇总|LWIP学习笔记 LWIP协议 [LWIP]LWIP网 ...
Java8种Stream流相关操作——集合的筛选、归约、分组、聚合
过滤.筛选 filter skip /*** 过滤筛选*/@Testpublic void test2(){List<String> list = Arrays.asList(&qu ...
Baxter的应用（转载）---个人学习
1.Introduction(Baxter与数学,图像处理在MATLAB中完成) Robots that can draw are cool. Robots that can understand w ...
关于 Oracle ACFS 相关知识的简单学习
作者 | JiekeXu 来源 | JiekeXu之路(ID: JiekeXu_IT) 转载请联系授权 | (微信ID:xxq1426321293) 大家好,我是 JiekeXu,很高兴又和大家见面了 ...
sql语句集合里有集合_学习SQL：集合论
sql语句集合里有集合 The set theory is very important in order to understand data and databases. While you co ...
安卓音频处理相关资料集合贴
## 1 音频处理基础知识 ### 1.1 文件格式和编码之间的关系首先需要说明的是,文件格式和编码之间的关系如同碗与烹饪手法之间的关系. 文件格式只代表一个容器,这个容器可以包含视频或者音频,以及 ...
基于API的ArrayList集合之学习记录
提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档文章目录一.arraylist集合的出现对象数组的使用对象数组的缺点为了弥补对象数组的缺点,出现了arraylist集合二. ...
SSH框架相关准备与入门学习
最近开始学习java web开发,记录一下学习的过程. 主要分为三个步骤: 1.基础:java.Mysql入门学习. 2.中级:html.css.javascipt.servlet.jsp入门学习,推 ...

Baxter robot 碰撞检测相关问题集合（自己学习用）

1、How to get Jacobian matrix when the external force is not on the end-effector ?

2、Is there a topic where Baxter publishes when a collision/exceeded torque/any-thing-related occurs?

3、URGENT - Torque control and collision detection

4、Torque control is not commanding the right torques

baxter官网：Joint Torque Control

6、gravity compensation torque

7、Commanded torque and measured torque

8、PID gains

9、Several problems about Baxter torque mode

10、Inverse dynamics API

11、baxter torque control and need calibration?

Baxter robot 碰撞检测相关问题集合（自己学习用）相关推荐

最新文章

热门文章