ergoCub 1.0 S/N:000 – The yarprobotinterface throws a lot of warnings due the CAN2 of the eb1

[S-Dafarra]

Robot Name 🤖

ergoCub 1.0 S/N:000

Request/Failure description

When running the robot, the output of the yarprobotinterface is flooded by warnings related to issues to the CAN2 on the eb1 board.

Detailed context

We noticed this issue after adding the battery device to the yarprobotinterface. See robotology/robots-configuration#571

Additional context

No response

How does it affect you?

No response

[maggia80]

cc: @MSECode

[MSECode]

Yes,
already checked that. I'm gonna reduce the frequency for sending messages over CAN bus and correct the CAN lines set in the configuration file, which should be CAN2:1 for both bms and bat and not CAN1:1 as it is now.

[MSECode]

Open the PR for the robot configuration update here: robotology/robots-configuration#573

[AntonioConsilvio]

Hi, @S-Dafarra @MSECode, to avoid these warning messages I have disconnected the CAN connection between the BAT board and the EB1 EMS, I will reconnect it when we update the firmware version with a new one that does not print these messages.

cc @maggia80 @Fabrizio69 @sgiraz

[valegagge]

Hi @S-Dafarra and @AntonioConsilvio ,
could you add here the log of YRI with the warning mentioned above?

Thanks!

[S-Dafarra]

Hi @S-Dafarra and @AntonioConsilvio , could you add here the log of YRI with the warning mentioned above?

Thanks!

Sorry, unfortunately, I don't have it at the moment. It is something we noticed during the rush of the demo.

[MSECode]

The logs should be this one, or at least highly closer to this:

and it most likely due to the fact that the version of the ems4 board connected to the BAT is older with respect to the information sent to the BAT over CAN.
Anyways, I reduced the frequency used for sending message from BAT to EMS considering that the current one is more than enough for our use cases.

As a matter of fact the current version of the EMS is the 3.72 and the feature of the BAT_Status has been introduced on version 3.73.
Thus, you can see that the yri is complaining about not recognizing the CAN frame with StdId: 0x629.
Considering this I will propose to plan the update of the robot, for both boards and superbuild, thus we can be aligned with the latest distro.
What do u think about this? if I'm not mistaken the responsible for ergoCub is @lrapetti.
So, do u have some demo planned or this is a good time for planning the update?

[sgiraz]

Hi @lrapetti,

Could you update the FW of the EMS board accordingly with the comment above letting us know if the problem is solved, please?

cc @MSECode

[lrapetti]

Considering this I will propose to plan the update of the robot, for both boards and superbuild, thus we can be aligned with the latest distro.
What do u think about this? if I'm not mistaken the responsible for ergoCub is @lrapetti.
So, do u have some demo planned or this is a good time for planning the update?

Since the next days are used by the teams to complete the experimental activities with the robot before it leaves for Rome, we were thinking to keep the update of the system for the last week. Clearly this means that there will be less time to test the updates before the activities in Rome. I don't know however what other people think, also in view of the demo that is supposed to happen in Rome before the robot is delivered @S-Dafarra @GiulioRomualdi @DanielePucci.

Clearly, if its independent from the update of the superbuild, I think I can manage to test at least the FW of the EMS.

[sgiraz]

Clearly, if its independent from the update of the superbuild, I think I can manage to test at least the FW of the EMS.

I think it is independent in this case. Is that right @MSECode?

[MSECode]

Not totally independent. In order to not having incompatibility you should have the same version of icub_firmware_shared on both firmware and icub main so on the superbuild.
So they are not totally independent.

[lrapetti]

I updated the firmware of the EMS at 3.74. I see the following warning on the yarprobotinterface, but probably it's something else:

[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 339m 694u: (code 0x0000000d, par16 0x0124 par64 0x0001009b003d01b6) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 419m 691u: (code 0x0000000d, par16 0x0124 par64 0x0001009b003d01b8) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 439m 695u: (code 0x0000000d, par16 0x012b par64 0x0001009b003d01b4) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 489m 697u: (code 0x0000000d, par16 0x0124 par64 0x0001009b003d01b6) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 569m 699u: (code 0x0000000d, par16 0x012c par64 0x0001009b003d01b5) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 571m 694u: (code 0x0000000d, par16 0x0120 par64 0x000100d9003701b2) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 629m 697u: (code 0x0000000d, par16 0x0124 par64 0x0001009b003d01b6) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 631m 691u: (code 0x0000000d, par16 0x0124 par64 0x000100da003d01b2) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 647m 694u: (code 0x0000000d, par16 0x0129 par64 0x0001009b003d01b8) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 649m 691u: (code 0x0000000d, par16 0x0123 par64 0x000100da003701b2) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 781m 691u: (code 0x0000000d, par16 0x0123 par64 0x0001009d005801b2) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 849m 694u: (code 0x0000000d, par16 0x0121 par64 0x0001009b004201b3) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 857m 691u: (code 0x0000000d, par16 0x0124 par64 0x00010098003d01af) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 869m 691u: (code 0x0000000d, par16 0x0124 par64 0x000100a2006701b3) -> SYS: the TX phase of the control loop has last more than wanted. In par16: TX execution time [usec]. In par64: num of tx can2 and can1 frames and latest previous execution times of TX, RX, DO [usec] + .
[WARNING]  from BOARD 10.0.1.8 (left_leg-eb8-j0_3), src LOCAL, adr 0, time 231s 898m 688u: (code 0x0000000c, par16 0x01a6 par64 0x009d01ad01070076) -> SYS: the DO phase of the control loop has last more than wanted. In par16: DO execution time [usec]. In par64: latest previous execution times of RX, DO, TX, RX [usec] + .

As a side note, I noticed icub-firmware-build was at the following commit and I have updated it to the latest release v1.36.0 (cc @ale-git @isorrentino) :

commit 1ba4af1026bbc5b902ea348374de97162bc57a30 (HEAD -> devel, origin/devel)
Author: Alessandro Scalzo <alessandro.scalzo@iit.it>
Date:   Wed Aug 9 09:36:31 2023 +0200

    2foc v3.3.20, 2foc.experimentalV3.6 v3.6.20 (#97)

[AntonioConsilvio]

Hi! Updating the EMS and the BAT boards to the latest icub-firmware-build (Tag: v1.37.0) this problem is not present anymore and the BAT has been connected again with the EMS EB1.

cc @sgiraz @MSECode @S-Dafarra