slvMove under Mode 0x202

[wanweiwei07]

I am using bcap python to control cobotta. When performing bcc.robot_execute(self.hrbt, "slvMove", jnts) in a while loop to move joints a long a planned trajectory, my robot stops due to exception 84201482. After some debugging, I find that the buffer empty problem usually happened in the very beginning of a motion trajectory. If I print the returned timestamps from robot, I could see things like this:

13508748 [-116.20905554149799, 3.0567682619781675, 53.14143028320454, 116.36814649315967, 103.1989631033668, -49.82750854531973, 0, 0] 13508750 [-116.20512549882889, 3.057020257002086, 53.1431989936295, 116.36538289994337, 103.19413799537672, -49.826592746694786, 0, 0] 13508751 [-116.19322104613083, 3.05778357259303, 53.14855657657791, 116.35701172754392, 103.17952230932254, -49.82381871029631, 0, 0] The timestamps have very short intervals.

For successfully executed trajectories, the short intervals happen sometimes too, but in most cases, 8 ms separation could be confirmed. Any ideas about the causes? Thanks!

[furukawahiromi]

@wanweiwei07 I'm sorry for the inconvenience. "Position command buffer is empty (0x84201482)" as an error message when the buffer becomes empty during running state. Could you please answer the following?

1. What is the version of cobotta? You can check it on TP. Please open setting and press F2.
2. Could you please give us some information to reproduce the problem?

[wanweiwei07]

Thank you for your quick reply.

My Cobotta information is as follows コントローラID 04D8001 ロボット型式 CVR038A1-NV6-NN コントローラタイプ COBOTTA CPU　Standard

Let me share more information. First you can see a video of the problems from the following youtube link: https://youtu.be/QwUKzW0vx10

When the trajectory is successfully followed, I get the following controller timestamps (integers) and local times (floating number, collected by using time.time()) We could see that the first 6 timestamps are smaller than 8ms, after that, the timestamps are around 8ms.

starting slave mode 749943 0.0017979145050048828 749944 0.0012614727020263672 749946 0.0012881755828857422 749947 0.0015835762023925781 749949 0.001306295394897461 749954 0.006234407424926758 749962 0.007612705230712891 749970 0.008440494537353516 749979 0.007849454879760742 749986 0.007779359817504883 749994 0.008558273315429688 750002 0.007825851440429688

The following parts show three failure examples. For the first one, the control failed after sending out the first joint configuration.

starting slave mode 757474 0.0049855709075927734 Traceback (most recent call last): File "/home/wrs/research/wrs/0000_examples/cobotta_rt_exec.py", line 45, in robot_x.move_jnts_motion(path) File "/home/wrs/research/wrs/robot_con/cobotta/cobotta_x.py", line 90, in move_jnts_motion ts, return_jnts = self.bcc.robot_execute(self.hrbt, "slvMove", jnts) File "/home/wrs/research/wrs/drivers/orin_bcap/bcapclient.py", line 312, in robot_execute return self._send_and_recv(64, [handle, command, param])[0] File "/home/wrs/research/wrs/drivers/orin_bcap/bcapclient.py", line 545, in _send_and_recv raise ORiNException(hex(hresult+2**32)[2:]) # 20220313weiwei drivers.orin_bcap.orinexception.ORiNException: 84201482

For the second one, the control failed after sending the third joint configuration. starting slave mode 909950 0.0014660358428955078 909956 0.006208658218383789 909962 0.00583958625793457 Traceback (most recent call last): File "/home/wrs/research/wrs/0000_examples/cobotta_rt_exec.py", line 45, in robot_x.move_jnts_motion(path) File "/home/wrs/research/wrs/robot_con/cobotta/cobotta_x.py", line 90, in move_jnts_motion ts, return_jnts = self.bcc.robot_execute(self.hrbt, "slvMove", jnts) File "/home/wrs/research/wrs/drivers/orin_bcap/bcapclient.py", line 312, in robot_execute return self._send_and_recv(64, [handle, command, param])[0] File "/home/wrs/research/wrs/drivers/orin_bcap/bcapclient.py", line 545, in _send_and_recv raise ORiNException(hex(hresult+2**32)[2:]) # 20220313weiwei drivers.orin_bcap.orinexception.ORiNException: 84201482

For the third one, the control failed after sending the second joint configuration. starting slave mode 953217 0.0015070438385009766 953218 0.0024602413177490234youtu Traceback (most recent call last): File "/home/wrs/research/wrs/0000_examples/cobotta_rt_exec.py", line 45, in robot_x.move_jnts_motion(path) File "/home/wrs/research/wrs/robot_con/cobotta/cobotta_x.py", line 90, in move_jnts_motion ts, return_jnts = self.bcc.robot_execute(self.hrbt, "slvMove", jnts) File "/home/wrs/research/wrs/drivers/orin_bcap/bcapclient.py", line 312, in robot_execute return self._send_and_recv(64, [handle, command, param])[0] File "/home/wrs/research/wrs/drivers/orin_bcap/bcapclient.py", line 545, in _send_and_recv raise ORiNException(hex(hresult+2**32)[2:]) # 20220313weiwei drivers.orin_bcap.orinexception.ORiNException: 84201482

[wanweiwei07]

Let me share more information.

Tonight I tested my code on a RT Linux and a different cobotta robot. The video result is uploaded to the following link. https://youtu.be/_i0ztx8xy5k There was no 84201482 error.

The success could be because of:

1. The different cobotta robot.
2. The RT Linux system.

I do not think the RT Linux is a good excuse because on the previous cobotta, the error always appeared at the very beginning of a the trajectory configurations. If it was the non-RT system problem, the error could happen anywhere when a system interrupt jumps in.

Thus, I am suspecting the robot itself. Could it be a problem of my cobotta controller?

If you need more about more RT and non-RT systems, their details are as follows. RT-Linux, Ubuntu 20.04(5.11kernel->5.10preempt_rt kernel), i5-7gen, 16g memory non-RT-Linux, Ubuntu 20.04(5.13kernel) i3-10gen, 8g memory

[wanweiwei07]

Problem solved.

I installed a new ubuntu20.04 with preempt rt just now, and used it to control the previous cobotta. The results are as follows. https://youtu.be/BR06o7LtCYY It seems the robot is running correctly.

But I am still wondering why non-rt system does not work. There are three buffers and should be able to host a 24ms delay. A non-rt system should have an overhead much smaller than it. Even if the delay could be more vulnerable in the first one or two configurations, I do see many cases where the robot accepted more than three configurations but still stopped at a 1482 error.

By the way, I have tested all the following system setups, none of them worked. windows10 windows10 with rt previlege ubuntu20.04 ubuntu20.04 with chrt -f 99 ubuntu20.04 with preempt_rt but without chrt -f 99

The only feasible setup is: ubuntu20.04 with preempt_rt and meanwhile change priority to chrt -f 99

I am not closing this problem as I still hope to see your comments on the failed system setups.

[wanweiwei07]

I did more tests today. Now my only problem is the acceleration.

If I set the maximum acceleration of my trajectory planner to pi for all joints, the robot works fine. However, if I change them to larger values, I encounter the 83500121 error.

I did not find the acceleration parameters from a cobotta guide book, and would appreciate it if you could tell me them here...

[wanweiwei07]

I think I have figured out the problem: After sending the mode-changing command, I instantly started sending the joint angles. On a non-RT system, the "instant" action is not delayed enough sometimes and thus causes problems. Including a short sleep (0.02ms) could help to avoid the problem.

I will close this session now and will switch to Cobotta Technical Support for the other questions I raised before. Thank you all.

[wanweiwei07]

I am sorry but this problem happen again. It seems including a short sleep is not the final solution for it. We still encounter 1482 from time to time.

[furukawahiromi]

@wanweiwei07 san, RC8/COBOTTA v2.16.11 improves 84201482. If your COBOTTA are older than this version, please consider upgrading.

For SlvMove and 84201482 issues, we analyze the error cause in Wireshark. ORiN2\CAP\b-CAP\Tools\Wireshark\b-CAP.lua is available for you to try.

[DENSO-FASupport]

Dear @wanweiwei07 san, Thank you for using the COBOTTA. I was wondering if I could be of further assistance to you regarding what you were discussing the other day. If the issue has been resolved by the COBOTTA's version up, could you close this issue? I'm sorry to trouble you, but I appreciate your cooperation. Thank you very much!