JuliusSustarevas commented 2 years ago

Hi I believe this question was asked before but I just want to check if there are any updates. The joint state feedback coming from xarm is still 10Hz max? Is there any way to make it faster or any plans to make it faster ?

https://github.com/xArm-Developer/xarm_ros/issues/55

penglongxiang commented 2 years ago

Hi, now you can specify argument report_type:=dev when launching the real-arm applications, to boost the feedback rate to 100Hz. Please note the joint velocity may not be very accurate with 100Hz report, we will try to optimize this later.

JuliusSustarevas commented 2 years ago

Whats the nature of inaccuracy? Just small over/under reporting? Or something more significant? No large spikes i hope? and no latency?

On Fri, Jan 21, 2022 at 8:36 AM penglongxiang @.***> wrote:

Hi, now you can add report_type:=dev at launching the real-arm applications, to boost the feedback rate to 100Hz. Please note the joint velocity may not be very accurate with 100Hz report, we will try to optimize this later.

— Reply to this email directly, view it on GitHub https://github.com/xArm-Developer/xarm_ros/issues/96#issuecomment-1018292586, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7P7DHDZA5LCB5QGZRLSQDUXELHDANCNFSM5MKBMB3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

JuliusSustarevas commented 2 years ago

Hi So I just want to understand whats happening here:

I just updated to the current git commit. I am recording joint states just coming from the service-based hw-interface read function. And joint command I'm sending via velocity controller. In the plot - red line is the velocity command on joint 1. Blue line is velocity joint_state of joint 1.

My questions is:

Why is there a 0.2 rad steady state overshoot on the joint velocity? So I command 0.1rad/s and it goes at 0.12.
Why there are 0,4 rad dips in the joint state velocity? you cans ee blue signal drop from 0.12 to 0.8.
Why is there noise on the steady signal? I assume that's the inaccuracy you have from encoders? its about 0.02rad amplitude wave
i can see a PID overshoot and that's fine its just weird why its going for 0.12

JuliusSustarevas commented 2 years ago

The under/overshoots aare quite severe on velocity. Also not sure why they are growing. I suspect you put your gains too high in order to overcome initial friction at low velocities?

penglongxiang commented 2 years ago

Hi @JuliusSustarevas , to answer all the questions, we need more information to confirm and reproduce these outputs.

what is the version of your controller firmware?
what was the full xarm_ros launching command you use, was it specified with report_type:=dev?
Just to confirm what was the source of data marked blue (joint1 feedback velocity)? Was it from velocity field of topic /joint_states? Or was it calculated (in 100Hz?) from the service-based read() joint angles?
What was the unit of the horizontal axis (time) on the diagram?
Is it possible to send us the log package downloadable from xArm Studio?

Thanks.

penglongxiang commented 2 years ago

Currently the /joint_states velocity information is just digital differentiation from the position report. Which may have spikes and oscillations especially at high frequency. We are trying to find a better way to get more accurate velocity feedback, like filtering, or use the controller reported joint velocity (but only available at 5Hz now).

JuliusSustarevas commented 2 years ago

xarm is on firmware 1.7.1 and github commit hash: 9d59340503a48afbc2e3ea8095b9828d2d955a5a
This experiment was done with report type normal. I load up the driver and a combined hardware interface (other parts of the robot). The driver is loaded as follows:


<group if="$(arg xarm_on)" ns="xarm">
            <param name="xarm_robot_ip" type="str" value=" <ip>" />
            <param name="velocity_control" value="<true>" />
            <param name="xarm_report_type" type="str" value="<normal>" />
            <rosparam file="$(find as_control)/config/joint_limits.yaml" command="load" />
            <node name="xarm_driver" pkg="xarm_api" type="xarm_driver_node" output="screen" />
</group>

A combined hardware interface is loaded up too. The controllers acting on xarm are velocity controller and joint state controller


xarm_joint_velocity_controller:
    type: velocity_controllers/JointGroupVelocityController
    joints: 
      - xarmjoint1
      - xarmjoint2
      - xarmjoint3
      - xarmjoint4
      - xarmjoint5
      - xarmjoint6
joint_state_controller:
  type: joint_state_controller/JointStateController
  publish_rate: 50

Im adding a picture to explain better. xarm_driver is the xarm_driver. armstone_driver is the combined hw interface that does the read. The experiment in previous post blue line is the msg.velocity[0] of sensor_msgs/JointStates msg from "/as_control/joint_states" topic (which is generated by the joint_state_controller loaded by hardware interface). I can see hw_interface still subscribes to xarm_states but the data is coming from the read().

4. horizontal axis is seconds from start ye. 
5. yes

studio-log.tar.gz

penglongxiang commented 2 years ago

Hi @JuliusSustarevas , thanks for the detailed information. From the log I actually saw received velocity commands are constantly varying at 50Hz, however from your diagrams the commands are updated far less often. I have not used velocity_controllers/JointGroupVelocityController before, but it's supposed to be just a forward-command-controller and no pid control loop needed.

We may need more time to identify the cause, since we do not have the exact code, it would be more helpful if you could check the command sent to robot through write(). Also, your velocity feedback seems to change at more than 5Hz under normal report, please help to confirm. Thanks.

Another question is: was your application cpu heavy or IO consuming? We are not quite sure if the velocity can calculate well if network is heavy or system delay occurs now and then.

penglongxiang commented 2 years ago

Hi @JuliusSustarevas , here are some updates about our reproduction of the issue.

Controller firmware version: v1.7.1, and xarm_ros is the latest commit.

load the single joint velocity controller as: (just test for joint 1)

joint1_velocity_controller:
type: velocity_controllers/JointVelocityController
joint: joint1

controller manager updates at 100Hz as we currently do.

send velocity command using command line like:

rostopic pub -1 /xarm/joint1_velocity_controller/command std_msgs/Float64  0.1

observe the joint velocity calculated at driver_node at: https://github.com/xArm-Developer/xarm_ros/blob/9d59340503a48afbc2e3ea8095b9828d2d955a5a/xarm_api/src/xarm_driver_node.cpp#L63 Which is supposed to be published to /joint_states velocity field.
Here is the plot of joint velocity observation from step 5, the velocity command sent are(rad/s): 0.05, 0.2, -0.15, -0.12, 0.1, 0.0. The time unit of horizontal axis is also 'seconds'.

Screenshot from 2022-01-26 18-08-04

As can be seen the overshoot and oscillations are not as severe as from your side. Moreover, the velocity controller behaves as expected, the command sent to xArm is at 100Hz, but value will not change as long as no new command sent by command line in step 4.

It says the velocity_controllers/JointGroupVelocityController is just a group version of velocity_controllers/JointVelocityController used in this test and they should behave the same. I will continue to test on JointGroupVelocityController later.

JuliusSustarevas commented 2 years ago

Hi thanks so much for this. My setup was pretty much identical.

To answer previous questions:

My setup is this https://github.com/JuliusSustarevas/ArmStone (see as_control) but ofc its for a specific robot. But you can see what I'm calling. should be normal dev type.
Yes it seems with normal report type I'me getting 50hz . i presume because from current commit its actually called the service from the driver so this is expected.

Clarifications:

Did i understand correctly that from data from the arm you see that the velocity command was oscillating?
From your previous post the velocity command is actually generated in the write() ... but seems the write is actually calling something in the driver? and that just sets a new joint position by integrating velocity?

I'll try to dive again in write/read and interactions with the driver. I'm beginning to think that I should not use the hw_interface as it just wraps the drive. the services for joint state feedback and velocity commands are probably exposed directly right? I can just call those directly.

Given that on your side it is not reproducable - this suggests that its the hardware interface messing up its cycles? If you try with all joint controller - that would mean calling 6 services instead of 1 every cycle. maybe that will cause more deterioration? In my case I have extra 4 motors being cycled through.

penglongxiang commented 2 years ago

Hi @JuliusSustarevas , for your clarifications:

Yes, as the controller log indicates: velocity command was sent in 100Hz, but the value changes (oscillates) at 50Hz. I will post a small part from the log for your reference: log_part.txt

The command is not generated in the write(), but in the update() method in ros-controller loaded by controller_manager, in your case, should be velocity_controllers/JointGroupVelocityController . I kind of suspect the controller actually running is not a forward-command-controller, but some other one using PID feedback control. Since feedback from JointStateController is supposed to operate at 50Hz. Please help checking the loaded controller by:

rosservice call /[your namespace]/controller_manager/list_controllers

my output is like this:


controller: 
- 
name: "joint_state_controller"
state: "running"
type: "joint_state_controller/JointStateController"
claimed_resources: 
  - 
    hardware_interface: "hardware_interface::JointStateInterface"
    resources: []
- 
name: "joint_velocity_controller"
state: "running"
type: "velocity_controllers/JointGroupVelocityController"
claimed_resources: 
  - 
    hardware_interface: "hardware_interface::VelocityJointInterface"
    resources: [joint1, joint2, joint3, joint4, joint5, joint6, joint7]


3. In the meantime, I tried the JointGroupVelocityController and control 7 joints together, the feedback still behaves normally (calculated in 5Hz under normal report), similar to my previously posted diagram. I am not sure if the oscillation of the feedback velocity is related to the oscillating command on your side. The only thing I do not understand now is why your velocity from `/joint_states` can vary at more than 5Hz, I will dig more into it.

penglongxiang commented 2 years ago

I just noticed JointStateController will also publish to joint_states topic if it is running, in the frequency specified in its config (50Hz here). And the velocity it publishes is indeed oscillating with severe overshoot, this may be the actual data source of you blue line. A way to identify the state published by our driver from the same topic is: the frame_id is "joint-state data" rather than empty.

I captured some frames of the JointStateController published data:

---
header: 
  seq: 2303
  stamp: 
    secs: 1643269768
    nsecs: 316697469
  frame_id: ''
name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7]
position: [-0.9359999895095825, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.46799999475479126]
velocity: [-0.11922166652689098, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05961083326344549]
effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---
header: 
  seq: 2304
  stamp: 
    secs: 1643269768
    nsecs: 327934714
  frame_id: ''
name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7]
position: [-0.9372000098228455, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.46860000491142273]
velocity: [-0.11801686956336851, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05900843478168426]
effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---
header: 
  seq: 2305
  stamp: 
    secs: 1643269768
    nsecs: 357517282
  frame_id: ''
name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7]
position: [-0.9399999976158142, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4699999988079071]
velocity: [-0.07913817827940021, 0.0, 0.0, 0.0, 0.0, 0.0, 0.03956908913970011]
effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---
header: 
  seq: 2306
  stamp: 
    secs: 1643269768
    nsecs: 368871543
  frame_id: ''
name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7]
position: [-0.9412000179290771, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4706000089645386]
velocity: [-0.11851995118867469, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05925997559433734]
effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---
header: 
  seq: 2307
  stamp: 
    secs: 1643269768
    nsecs: 388624605
  frame_id: ''
name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7]
position: [-0.9431999921798706, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4715999960899353]
velocity: [-0.11868889302058212, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05934444651029106]
effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---
header: 
  seq: 2308
  stamp: 
    secs: 1643269768
    nsecs: 408326389
  frame_id: ''
name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7]
position: [-0.9452000260353088, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4726000130176544]
velocity: [-0.11823474117946216, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05911737058973108]
effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

The velocity command given here is [-0.1, 0, 0, 0, 0, 0, 0.05]. I observed from its timestamp that the actual rate is not that stable, and I am not aware how the velocity is calculated since only joint position is updated now in xArmHW::read(), calculation with two adjacent position and the time-stamp difference does not match with its velocity value, research on the 'ros_control' source code is needed for its algorithm.

For speed monitoring, I suggest you can try removing the spawning of JointStateController or just pick the state published from our driver for xarm joints. Check if the monitored velocity can be better this way. The joint state published by xarm_driver in my same experiment is:

header: 
  seq: 244
  stamp: 
    secs: 1643269768
    nsecs: 423874944
  frame_id: "joint-state data"
name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7]
position: [-0.9467999935150146, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4733999967575073]
velocity: [-0.10008712856336875, 0.0, 0.0, 0.0, 0.0, 0.0, 0.050043564281684376]
effort: [0.012418649159371853, -6.752345561981201, 0.037371568381786346, 3.9327456951141357, -0.007377090863883495, -0.8894346952438354, 0.07369352877140045]

Another thing is: in the controller log on system date 2022-01-21, I did not see the xarm.getServoAngle() which is called in xArmHW::read() in current commit: 9d59340503a48afbc2e3ea8095b9828d2d955a5a, if not called it should be the old implementation of xArmHW::read() which had no active acquisition of joint angles but using reported data as controller feedback. Maybe you have not updated to the latest xarm_ros back then?

JuliusSustarevas commented 2 years ago

Thanks so much for all your work trying to figure this out.

I will do a other test on Friday :

double checking the code that runs on the arm.
being very explicit about source of data.
yes the blue line was coming from joint_state_controller at 50hz. However I have remapper the joint states topic for xarm driver. So I don't think I was combining the fwo streams. But I will double check .

On Thu, 27 Jan 2022, 08:33 penglongxiang, @.***> wrote:

I just noticed JointStateController will also publish to joint_states topic if it is running, in the frequency specified in its config (50Hz here). And the velocity it publishes is indeed oscillating, this may be the actual data source of you blue line. A way to identify the state published by our driver from the same topic is: the frame_id is "joint-state data" rather than empty.

I captured some frames of the JointStateController published data:

header: seq: 2303 stamp: secs: 1643269768 nsecs: 316697469 frame_id: '' name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7] position: [-0.9359999895095825, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.46799999475479126] velocity: [-0.11922166652689098, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05961083326344549] effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

header: seq: 2304 stamp: secs: 1643269768 nsecs: 327934714 frame_id: '' name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7] position: [-0.9372000098228455, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.46860000491142273] velocity: [-0.11801686956336851, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05900843478168426] effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

header: seq: 2305 stamp: secs: 1643269768 nsecs: 357517282 frame_id: '' name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7] position: [-0.9399999976158142, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4699999988079071] velocity: [-0.07913817827940021, 0.0, 0.0, 0.0, 0.0, 0.0, 0.03956908913970011] effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

header: seq: 2306 stamp: secs: 1643269768 nsecs: 368871543 frame_id: '' name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7] position: [-0.9412000179290771, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4706000089645386] velocity: [-0.11851995118867469, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05925997559433734] effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

header: seq: 2307 stamp: secs: 1643269768 nsecs: 388624605 frame_id: '' name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7] position: [-0.9431999921798706, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4715999960899353] velocity: [-0.11868889302058212, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05934444651029106] effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

header: seq: 2308 stamp: secs: 1643269768 nsecs: 408326389 frame_id: '' name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7] position: [-0.9452000260353088, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4726000130176544] velocity: [-0.11823474117946216, 0.0, 0.0, 0.0, 0.0, 0.0, 0.05911737058973108] effort: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

The velocity command given here is [-0.1, 0, 0, 0, 0, 0, 0.05]. I observed from its timestamp that the actual rate is not that stable, and I am not aware how the velocity is calculated since only joint position is updated now in xArmHW::read(), calculation with two adjacent position and the time-stamp difference does not match with its velocity value, research on the 'ros_control' source code is needed for its algorithm.

For speed monitoring, I suggest you can try removing the spawning of JointStateController and simply use the state published from our driver. Check if the monitored velocity can be better this way. The joint state published by xarm_driver in my same experiment is:

header: seq: 244 stamp: secs: 1643269768 nsecs: 423874944 frame_id: "joint-state data" name: [joint1, joint2, joint3, joint4, joint5, joint6, joint7] position: [-0.9467999935150146, -6.938893903907228e-18, 0.0, 0.0, 0.0, 0.0, 0.4733999967575073] velocity: [-0.10008712856336875, 0.0, 0.0, 0.0, 0.0, 0.0, 0.050043564281684376] effort: [0.012418649159371853, -6.752345561981201, 0.037371568381786346, 3.9327456951141357, -0.007377090863883495, -0.8894346952438354, 0.07369352877140045]

Another thing is: in the controller log on system date 2022-01-21, I did not see the xarm.getServoAngle() which is called in xArmHW::read() in current commit: 9d59340 https://github.com/xArm-Developer/xarm_ros/commit/9d59340503a48afbc2e3ea8095b9828d2d955a5a, if not called it should be the old implementation of xArmHW::read() which had no active acquisition of joint angles but using reported data as controller feedback. Maybe you have not updated to the latest xarm_ros back then?

— Reply to this email directly, view it on GitHub https://github.com/xArm-Developer/xarm_ros/issues/96#issuecomment-1022967169, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7P7DCD4PIBWPCFUFKW5XDUYD7N7ANCNFSM5MKBMB3Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

penglongxiang commented 2 years ago

Hi another update… Sorry I did not check thoroughly, the velocity from JointStateController is calculated in the xArmHW:read() function rather than joint state controller itself. Now it is actually our problem. We will inspect into this part and try to optimize it (it may have something to do with the time used in that calculation, and lack of filtering). Unfortunately the Chinese New year holiday is coming, optimization test will have to wait until February 9.

I will get back to you when there is further update.

JuliusSustarevas commented 2 years ago

Ye I was thinking about the time stamps. Are the systems using timestamps from different machines maybe? If the message is stamped on the box, but then read on a PC and PC time is subtracted from box time it could be a sync issue.

JuliusSustarevas commented 2 years ago

Just confirmation update: Recloned the repo. I'm def on latest commit.

xarm_driver/joint_states are publishing at Hz. joint_states_controller at 50hz. The oscilation exists in joint_states_controller output and not in xarm_driver/joint_states.

JuliusSustarevas commented 2 years ago

Just another observation. joint_state_publisher frequency has an effect on the oscillation (but not the mean). Below plots: yellow thick line is xarm_driver/joint states. redish thinner line is joint_states from joint_state_controller Here it is at 100hz: 20Hz: 5Hz

This suggests a digitisation error type of thing. a counter being asynchronously read while its incrementing will always produce something like this. However, the bizz\re thing for me is still the overshoot being present in all these. This suggests the true velocity is still wrong.

JuliusSustarevas commented 2 years ago

(I'm just gonna keep posting as more information is never bad. I understand you're on holiday. ) Here is a more complex trajectory being followed. This is joint 5. Thick green is control signal, thin blueish is joint state velocity

The troublesome part is the undershoot.

JuliusSustarevas commented 2 years ago

Hi, hope you had a great holiday. Have you had a chance yet to take a look at this? Its beginning to severely impact me. I'm using velocity control to control for a cartesian position trajectory and the under shoots just make it miss its mark drastcally.

JuliusSustarevas commented 2 years ago

By the way, when I move the end effector in any cartesian line even at very slow speeds and even in xarm studio I see quite substantial vibration/oscilation on along ToolFrame Z axis. Is this something you're aware of perhaps? maybe this is related?

penglongxiang commented 2 years ago

Hi we've been looking at this issue since the day we were back to office, we suspect the oscillation in velocity calculated in read() and used by JointStateController is due to cycle mismatch of ros controller_manager(100Hz) and xArm controller (250Hz), also the non-realtime communication time delay will affect the calculation. We are working to mitigate the calculation mismatch or find a better solution now.

By the way, if switching to use joint_states from xarm_driver, will the outcome be better in your case?

penglongxiang commented 2 years ago

By the way, when I move the end effector in any cartesian line even at very slow speeds and even in xarm studio I see quite substantial vibration/oscilation on along ToolFrame Z axis. Is this something you're aware of perhaps? maybe this is related?

We are aware of the vibration in low speed operation most likely when the arm stretches forward. We will also work on the optimization of PID parameters for the joints. If it is achieved, new PID gains can be updated through xArm studio.

I'm using velocity control to control for a cartesian position trajectory and the under shoots just make it miss its mark drastcally.

Does this mean, after the velocity tracking execution, your final interest is still the position? If so, I think for your case, there may be another cause besides the joint PID parameters.

Current xArm velocity mode may not be very suitable for high frequency command tracking yet, unlike servo_joint/servo_cartesian, the real-time position command can be passed to the motor instantly for execution, external velocity command will go through a interpolation process first with a pre-set acceleration and jerk, to make velocity transition smooth enough, so it may be slower to reach the velocity target, if command changes rapidly, there will not be enough time to follow up the target, if the velocity error accumulates along execution, the final position will be deviated.

Moreover, I am afraid even if we pass the velocity command as quickly as possible, in an open-loop velocity tracking scenario, the final position error still may not be eliminated, real hardware control is not ideal after all and will always have tracking error. So maybe you can consider switching to position control? Such that the final position will not be affected by tracking error.

For better compatibility with high-frequency velocity trajectory, we need some time for development and test. Hopefully it can be better supported in the next updates of firmware and xarm_ros.

penglongxiang commented 2 years ago

If position control is not an option, as far as I know, velocity_controllers/JointGroupVelocityController operates in an open-loop fashion, a closed-loop version is velocity_controllers/JointTrajectoryController which is used by Moveit.

JuliusSustarevas commented 2 years ago

By the way, if switching to use joint_states from xarm_driver, will the outcome be better in your case?
- Issue with this is the 5Hz update rate. I believe it is still 5Hz right?
We are aware of the vibration in low speed operation most likely when the arm stretches forward. We will also work on the optimization of PID parameters for the joints. If it is achieved, new PID gains can be updated through xArm studio.
- Ye this vibration is pretty bad. And yes especially as it stretches forward. Hope this will be improved soon
Current xArm velocity mode may not be very suitable for high frequency command tracking yet,
- So just so i understand: 1) when using joint velocity command, acceleration/jerk constraint is imposed that cannot be edited? (i tried changing acc/jerk limits in xarm studio and it seemed to have no effect) 2) if using servo_joint services there are no acceleration/ jerk constraints? 3) So what would you recommend if I need to follow a precisely timed joint trajectory? This joint trajectory is about 6 seconds long and is updated at at 100hz.
Re: open/close lop velocity control:
- I am using an MPC controller that is essentially desired cartesian trajectory --> joint velocities. THis controller is closed loop with respect to joint states. My problem is more that if xarm velocity commands have some imposed acc/jerk limits that i cannot change it makes it difficult to follow prescribed velocities . since the mpc is closed loop it can compensate for this at low speeds. But then at low speeds I get this crazy up and down vibration. But if I speed up arm does not respond to velocity commands quickly enough either.. so a bit between a rock and a hard place.

penglongxiang commented 2 years ago

Issue with this is the 5Hz update rate. I believe it is still 5Hz right?

Yes, so we will make the data from JointStateController more reasonable even at 100Hz.

So just so i understand: 1) when using joint velocity command, acceleration/jerk constraint is imposed that cannot be edited? (i tried changing acc/jerk limits in xarm studio and it seemed to have no effect) 2) if using servo_joint services there are no acceleration/ jerk constraints? 3) So what would you recommend if I need to follow a precisely timed joint trajectory? This joint trajectory is about 6 seconds long and is updated at at 100hz.

(1) yes, they are internal parameter, we will volume up the jerk, acceleration is alreay at a maximum value for joint space motion. (2) if with servo_joint, technically there are no limitations for jerk/acceleration, it will be the responsibility of upper machine program to plan the trajectory profile, but if xArm controller noticed the speed exceeds limit (180 deg/s for any joint), a protective stop will be triggered. (3) If you can generate proper trajectories, maybe default HW interface with position control (which uses servo_joint for write() ) is also worth a try.

I am using an MPC controller that is essentially desired cartesian trajectory --> joint velocities. THis controller is closed loop with respect to joint states. My problem is more that if xarm velocity commands have some imposed acc/jerk limits that i cannot change it makes it difficult to follow prescribed velocities . since the mpc is closed loop it can compensate for this at low speeds. But then at low speeds I get this crazy up and down vibration. But if I speed up arm does not respond to velocity commands quickly enough either.. so a bit between a rock and a hard place.

Noted. In the next updates we will make velocity transition as fast as possible. The up and down vibrations currently seen may not reflect the true states, it is due to digital differentiation errors and lack of filtering, our test shows the feedback can be much more reasonable after our optimization. Please wait for our future release, hopefully available at end of February.

JuliusSustarevas commented 2 years ago

Hi are there any updates on this? Especially regarding vibrations at low speeds. I have a video to show the impact https://youtu.be/uBzdOuvIp9c?t=9 at 1x speed you can see the up and down oscilations. They are roughly +-2 or 3 mm. For my printing application I really need to figure out how to get rid of this.

penglongxiang commented 2 years ago

Hi we are now in lock down state and working from home because of the pandemic of the city. This affected the testing and release of new firmware. Maybe we can go back to office next week. Sorry about the delay.

penglongxiang commented 2 years ago

About the vibration in the video, could you please try just using xArm Studio to jog the robot at similar position with similar velocity, to confirm the robot will also vibrate in this way? This is to rule out the possibility of oscillating command generated from ros-controller, thank you.

xArm-Developer / xarm_ros

Joint states frequency #96

Clarifications: