Increase upper limit of force in low-level control

[yangbenbo]

Version

Kortex Device: 7DOF Gen3
Firmware Version: 2.2.0
KortexAPI: 2.2.0
OS: Ubuntu 18.04

Description

We want to realize the robot’s gravity compensation in current mode, but when we apply a force to robot, it's so easy that the robot raise error and stop. Maybe the force is a little large, the error is below,

Kortex exception: Device error, Error sub type=WRONG_SERVOING_MODE => <srv: 3, fct: 1, msgType: 3>
description: Wrong servoing mode, must be low level servoing mode
Error sub-code: WRONG_SERVOING_MODE 

We change the ControlMode before control as below and didn't change it when running the code.

auto control_mode_message = k_api::ActuatorConfig::ControlModeInformation();
control_mode_message.set_control_mode(k_api::ActuatorConfig::ControlMode::CURRENT);
for (int i=1;i<8;i++){
    m_actuator_config->SetControlMode(control_mode_message, i);
}

I would appreciate it if you can give some advice, is there any ways to increase the upper limit of force in low-level control, I only find that soft limits are not configurable in admittance modes nor in low-level control in User Guide.
Thank you in advance!

Best regards,
yangbenbo

[alexvannobel]

Hi @yangbenbo ,

You did switch the individual actuators's control modes, but did you switch the whole arm to low level control? The error suggests the arm is still in high level control mode.
You can have a look at this snippet to see how we do it in the torque control low level example.

Hope this helps,
Alex

[yangbenbo]

Hi Alex, Thanks for you help, I think I do switch the whole arm to low level control like below.

    // contorl mode
    servoing_mode.set_servoing_mode(k_api::Base::ServoingMode::LOW_LEVEL_SERVOING);
    m_base->SetServoingMode(servoing_mode);
    base_feedback = m_base_cyclic->RefreshFeedback();

    // Set control mode include  POSITION = 1, VELOCITY = 2 TORQUE = 3, CURRENT = 4,
    control_mode_message.set_control_mode(k_api::ActuatorConfig::ControlMode::CURRENT);
    for (int i = 1; i < 8; i++) {
        m_actuator_config->SetControlMode(control_mode_message, i);
    }

And when I use Joystick to stop the program, the error is the same.

Best regards,
yangbenbo

[alexvannobel]

Hi @yangbenbo ,

You do indeed switch the base's control mode so that should be good. I understand from the snippet in your first message that this error occurs when calling Kinova::Api::BaseCyclic::Refresh.

Do you also mean you get this exact error when the arm is in low level control mode and you try to move it with the joystick, or do you get the error using another API call? You cannot move the arm with the joystick while it's in low-level control mode.

Best,
Alex

[yangbenbo]

Hi Alex,
Sorry for the delay and thanks for your help. My question is below.

joint speed limit

I have tested the gravity compensation in current mode and collected the joint velocity, joint torque, joint position and joint current include the command and feedback until the robot reports the error.





As you can see, the joint current, joint torque, and joint position is ok, but the joint velocity is over the limit which I find in the user guide. However, this joint limits are used in hig-level control and I'm not sure whether it's the same in robot low-level control.
Besides, I have tested the last joint in low-level joint speed control mode. When the joint speed is 69°/s which is under the limit, everything is ok. But when the joint speed is over the limit such as 150°/s, 140°/s, 105°/s and even 85°/s, the robot reports the error. I find the error is the same every time and it's same with the error in gravity compensation in current mode .

Kortex exception: Device error, Error sub type=WRONG_SERVOING_MODE => <srv: 3, fct: 1, msgType: 3>
description: Wrong servoing mode, must be low level servoing mode

cann't reconnect the robot

Sometimes I send a big joint current like 4A, then I lost the connection. The web app cann't connect the robot and the program reprot a runtime error, but the led is green. Finally I have to reboot the robot.

safety error from web app and program is different

I use base_feedback.actuators(i).fault_bank_a() to get the SafetyIdentifierBankA. Sometimes the program the FOLLOWING_ERROR, but there is just a joint fault in the web app.

Communication issue and Firmware issue

I use the command below to compare the usual kernel and Real-time kernel
sudo ping <fci-ip> -i 0.001 -D -c 10000 -s 1200
The first picture is the usual kernel, and the second picture is the Real-time kernel.. I find the Real-time kernel works much better. Should we make sure the sum of Round trip time (RTT), Execution time of program or control loop, and time needed by the robot to process data and step the internal controller is less than 1ms.

As for Firmware issue, I have downloaded the Software Upgrade Package v2.2.0 from this site upgrade the Firmware.

summarize

1. Is the joint speed limit in low-level control mode same with that in high-level control mode? If not, I'd like to know the joint current limit, joint velocity limit, joint torque limit in low level control mode to prevent lose connection with the robot.
2. Why safety error from web app and program is different?
3. Should we make sure the sum of Round trip time (RTT), Execution time of program or control loop, and time needed by the robot to process data and step the internal controller is less than 1ms?

[polthergeist]

Hi @yangbenbo, about the question #3, I would say yes, you'll have much better results using a real time kernel. I have tested it with the kernel 4.15 but I'm pretty sure it could work great on other version. One of the test we do here is that we move the robot in low level mode while monitoring the comm. For a 1 hour test, 3 600 000 cycle of 1 ms, we usually between 20 and 100 cycles that exceed 1 ms threshold.

I'll get back to you about question 1 and 2.

[polthergeist]

Hi @yangbenbo, I've asked the control team and the limit in high level and low level should be the same.

[polthergeist]

Hi @yangbenbo, About the mismatch of error, it is not really a mismatch. The error is a FOLLOWING_ERROR. On the web app, if you are on the general TAB it will says that there is a fault join, which is true. If you want to know what kind of fault, you need to go in the actuator TAB. You should see your FOLLOWING_ERROR there. That said, the following error probably comes from a timing issue. Your 1 Khz control loop must not be tight enough. Make sure that you are a real time kernel and try it again. Also, if you are comfortable about sharing your code, I could check how you compute your loop, maybe I'll see something.

[polthergeist]

Hi @yangbenbo, I was wondering, is your issue solved?

[felixmaisonneuve]

I will assume this issue has been solved and I will close it.
If you still encounter this issue, we will reopen it