Huge tracking error of using non-realtime ros node

[XinyuanZhao]

I just found that the tracking error of joint motions from a non-real-time ROS node is huge compared with that from a similar real-time XBot Plugin.

Let's take the simplest homing function as an example. The joint command q_cmd is computed by q_cmd = q0 + 0.5 * (1 - cos(M_PI*time_elapse/homing_time)) * (q_home - q0) and the control rate of both the non-real-time and real-time realizations is 200 hz.

• plot of tracking errors of a single joint (the results of other joints are similar)

• when I call the service /xbotcore/set_filter_profile_fast, the tracking error from a non-real-time ROS node become smaller, but it's still large compared with that from a real-time plugin

Any ideas of the reasons and solutions? @EnricoMingo @alaurenzi

[alaurenzi]

Does this data come from the real robot?

[XinyuanZhao]

Does this data come from the real robot?

No. The results are from simulations.

Another related concern is that the results in simulations and in experiments are different, which means we could face difficulties after transforming the code. If the results are consistent, at least we can predict the performances by simulations.

So in my opinion, either figuring out the reasons or making sure the consistency is beneficial.

[XinyuanZhao]

Hello All,

Since the tracking errors seem to be caused by time delays when running an NRT ROS node, I further checked the approximated delays by setting set_filter_profile_fast or set_filter_profile_medium when running an NRT locomotion controller at 200 Hz. Here are the results:

• with set_filter_profile_fast: about 75 ms
• with set_filter_profile_medium: about 150 ms

For your information.

[XinyuanZhao]

Hello All,

Update this issue.

We did three tests of homing in the air on the robot. The test configurations are shown below.

• test_1: using RT Plugin in the package xbot2_examples
• test_2: using non-RT ROS node, safe filter profile
• test_3: using non-RT ROS node, fast filter profile

By the way, I copied the implementation of the homing function in xbot2_examples to the non-RT homing function.

Here display the results of joint tracking errors.

• test_1: using RT Plugin

• test_2: using non-RT ROS node, safe filter profile

• test_3: using non-RT ROS node, fast filter profile

Obviously, all of the tracking errors are within reasonable ranges this time. But with regard to this issue, now I have two further questions.

First, why is the tracking error in test-3 is in general smaller than that in test-1? In the previous tests as shown at the beginning, the RT Plugin always had smaller tracking errors than NRT cases no matter if fast filter profile was used. It seems that now the RT Plugin has been safely filtered by default, right?

Second, this test is quite conservative because the robot moved without any contacts and the motion was slow (homing in 5 s). I remember that in February I tested with Arturo and we found the tracking error during locomotion could reach about 0.3 rad (amazingly...). So I plan to test another round in the next week when we place the robot on the ground and let it walk.

Let's check later if this issue is really solved. @alaurenzi @liesrock @DavideAntonucci @ntsagarakis

[alaurenzi]

In xbot2 reference filtering is centralized and applied to all modules.

[XinyuanZhao]

In xbot2 reference filtering is centralized and applied to all modules.

This perfectly explains the first question. Thanks!

Talking about the filter, I remembered in February you @alaurenzi said that the error appeared between the filter and the motor (I mean, there was little error before the filter), so it's actually not a tracking error but a filtering error. Did you solve this issue when updating to Xbot 2?

[liesrock]

The issue should not be there: if you can still try it in simulation please confirm it @XinyuanZhao. For the moment I'll close.