Duration in JointSpeed

[akihikoy]

Summary

Could you write more explanation about the duration parameter of JointSpeed?

Use case

Currently, it is explained as:

Duration constraint. If not 0, allows to set a limit (in seconds) to the JointsSpeed (future)

I cannot understand clearly.

1. Is that a limit of duration during which the robot moves at the specified speed? (e.g. If duration is 5, robot moves the joint at the speed of value for up to 5 seconds?) Or, does it have another meaning?
2. Why duration is in seconds? It could be milliseconds since the robot works at kHz.
3. What does (future) mean? Is duration a future function?

Alternative

Possible issues

Additional context

[KinovaCustomerSupport]

Hi @akihikoy

Thanks for your questions.

Q1. Is that a limit of duration during which the robot moves at the specified speed? (e.g. If duration is 5, robot moves the joint at the speed of value for up to 5 seconds?) Or, does it have another meaning?
A1. This limit is not implemented yet, so the final implementation could be as you expect, but I can't guarantee it.

Q2. Why duration is in seconds? It could be milliseconds since the robot works at kHz.
A2. The duration is in seconds stored in a float.

Q3. What does (future) mean? Is duration a future function?
A3. Future means not implemented yet, we will make sure to clarify this in the documentation.

We also had this question regarding SendJointSpeedsCommand in February, I hope it can help you.
#3

Sincerely,
Jean-Philippe Côté, Customer support - Software.

[akihikoy]

Hi @KinovaCustomerSupport

Thank you for your answers.
I overall understand them.

I asked Q.2 because of the type of duration, which is uint32 in the document. If it is float32, I can understand.

So, actually I reached to this document of JointSpeed by investigating how to use SendJointSpeedsCommand from ROS. I thought that if I send a proper request consisting of JointSpeed to that service, I can operate the robot by commanding joint speeds. However, the discussion of #3 seems to be saying that SendJointSpeedsCommand is a future function. Then, I cannot control the robot by commanding joint speeds? Is there alternative ways to control the joint velocities of the robot?

Many thanks!

[KinovaCustomerSupport]

Hi @akihikoy

I double check and you are right, the duration is a UINT32. Still in seconds, but no fraction.
Like I said earlier, the implementation is yet to come, so it could changes.

Also, I validated with our engineering team and it is not possible at the moment to control the robot by commanding joint speeds. It is currently planned for next release.

As you may know, we have some examples for our ros_kortex package here : https://github.com/Kinovarobotics/ros_kortex/blob/master/kortex_examples/readme.md
And for Kortex package, examples are located here:
https://github.com/Kinovarobotics/kortex/blob/master/api_cpp/examples/readme.md

Sincerely,
Jean-Philippe Côté, Customer support - Software.

[akihikoy]

Hi @KinovaCustomerSupport

As I need a velocity control capability as soon as possible, please tell your engineering team that some customers really waiting for that.

Also, could you tell me how the joystick control implemented? I thought it is implemented with velocity control. Or, is it implemented by a control like updating joint/Cartesian positions every control cycle? Is that possible for users to implement a similar control? If we can, it could be an alternative of velocity control.

Many thanks.

--Akihiko

[alexvannobel]

Hi @akihikoy ,

The implementation of the angular velocity control is a top priority for our engineering team for the upcoming 2.0 release.

• The angular velocity control with the joystick is achieved with the SendSelectedJointSpeedCommand rpc in the Base service. However, this rpc only commands a single joint at a time, effectively putting the other joints's speeds at 0.
• The cartesian velocity control with the joystick is achieved with the SendTwistCommand rpc in the Base service. You could use this same function to control the arm in cartesian velocity, if that suits your needs.
  I am fully aware this does not replace angular velocity control on all joints, however.

Thanks for your patience,
Best regards,
Alex

[akihikoy]

Hi @alexvannobel

Thank you for the explanation.

The cartesian velocity control with the joystick is achieved with the SendTwistCommand rpc in the Base service.

I'm a bit confusing about this. In general, the Cartesian velocity is converted into joint angular velocities, and then the robot is controlled to achieve the joint angular velocities. In other words, the joint velocity control might be internally used. So, if the Cartesian velocity control is implemented, why is the joint velocity control unavailable...?

Very best,
--Akihiko

[alexvannobel]

Hi @akihikoy ,

In general, the Cartesian velocity is converted into joint angular velocities, and then the robot is controlled to achieve the joint angular velocities. In other words, the joint velocity control might be internally used.

Internally, the high-level commands are eventually transformed in a series of small joint position increments for every actuator.

So, if the Cartesian velocity control is implemented, why is the joint velocity control unavailable...?

The handling of the high-level joint speed command API call inside the arm could not be implemented for release 1.1.6, but will be in the next release.

Cheers,
Alex

[alexvannobel]

Hi @akihikoy

The SendJointSpeedsCommand function is now available with the 2.0 release.
I'll close this issue, but feel free to open a new one if there is anything with the functionality.

Best,
Alex

[akihikoy]

I quickly reviewed the new release, and still think that the issue I reported here is not yet improved.
So, this issue should be kept opened.

The point is that the type of the duration parameter of class JointSpeeds is still int, but it should be float64 or some.

[gstlaurentkinova]

Hi @akihikoy

I'm reopening the issue following your observation.

We will keep this issue updated with further progress.

Best,
Gabriel

[martinleroux]

Since I am doing a clean up in our Open issues, I will take the time to confirm that the duration field still does not work as of API 2.6.0 and firmware version 2.5.2. The bug has been formally logged in our internal system since this ticket has been opened. As of today, it is currently planned for our next major release not to implement a duration constraint, but rather to remove the duration field from the API to avoid confusion.

As a workaround, we recommend using a timer in your application and call the base.Stop() function or send a null Speed/Twist command to interrupt your command.

For this reasons, I will be closing this issue as Won't do. If you find that the duration field is necessary to your applications and that the above workaround does not work for you, let us know. If enough people complain about this, the feature may be revisited in the future.