ergoCub 1.1 S/N:001 – Failed to Discover CAN boards under ems eb 6-9

[MSECode]

Robot Name 🤖

ergoCub 1.1 S/N:001

Request/Failure description

Failed to Discover any CAN board under the ems from eb6 to eb9 as seen in the image below

Detailed context

While trying to update the CAN boards under the ETH ems boards from eb6 to eb9 I was unable to discover the CAN boards beneath them even if the ETH boards were in Maintenance and the CAN boards were clearly working.

Additional context

No response

How does it affect you?

No response

[AntonioConsilvio]

Hi @MSECode, We are already aware of this problem, FirmwareUpdater is not not able to do the discover of the CAN boards on this robot.

As long as the problem is present, to update the boards is possible to connect externally with a 5-pin connector to the EMS EB9 board (left ankle) to the P3 connector, as it is not used.

cc @sgiraz

[MSECode]

Cc: @valegagge

[MSECode]

Just to update all on some weird behavior of the boards that I've noticed while working with ergoCubSN001, which can be related to this issue of discovering the CAN boards, I've experienced the following:

Let us consider that if we connect directly to one of the ETH boards with the ETH adapter it is possible to discover all the ETH boards and also the CAN boards beneath them, as previously said.
However, when I updated the CAN boards beneath the ems boards from 10.0.1.3 to 10.0.1.9 everything was fine.
Instead I've noticed a strange behavior when updating the foc CAN boards under the ems 10.0.1.1 and 10.0.1.2. Thus, when updating the foc boards form the FirmwareUpdater the update process started but after a few moment I got the operation Done message without having any CAN board updated.
Moreover, after that, it was impossible to discover any CAN board connected to any ETH board.
Finally, it was possible to discover again the CAN boards iff we switch off and on again the motors.

cc: @valegagge @sgiraz

[maggia80]

@MSECode the issue in eb1 and eb2 is due to the fact that the BMS and the BAT boards are connected to those boards respectively and we don't know how they interfere with the CAN bootloader

[maggia80]

here the details of the connections: https://github.com/icub-tech-iit/electronics-wiring-public/blob/master/ergocub1/ergocub1.1/pdf/ergoCub1.1_Logic_17256_1.1.0.pdf

[MSECode]

@MSECode the issue in eb1 and eb2 is due to the fact that the BMS and the BAT boards are connected to those boards respectively and we don't know how they interfere with the CAN bootloader

Yeh, I know that. So that could be the main problem. I'm gonna check it out, maybe with the help of @sgiraz, debugging the FirmwareUpdater software after I'm completely done with the temperature feature, since we cannot have these problems with the Updater.

[sgiraz]

Just for keep you informed,

On last Friday alongside with @MSECode, we spotted that if we try to discover the CAN board with the BAT disconnected from the EMS eb2 splitter's connector we are able to see all the CAN boards correctly.

cc @Gandoo

[MSECode]

Hi @sgiraz after some tries that's not actually always true and there're other misbehaviours related to the CAN boards discovery. I suggest to have the whole cabling done and then re-check and also see if something changes when connecting to the ETH switch

[sgiraz]

Hi @sgiraz after some tries that's not actually always true and there're other misbehaviours related to the CAN boards discovery. I suggest to have the whole cabling done and then re-check and also see if something changes when connecting to the ETH switch

Unfortunately yes!
The only consistently observed condition is that when we can successfully discover CAN boards through SSH on ergocub-torso, connecting the bat CAN connector to the EMS (EB1) immediately disrupts CAN board discovery and we are not able to discover any CAN board anymore.

cc @marcoaccame @MSECode @maggia80

[MSECode]

Regarding what discussed here until now, it should be pointed out that when I tested on ergoCub SN001 the feature related to this PR, which introduces the fact that now the BAT board remains silent until the YRI is started, I was able to see, using the CANReal, that as we expect, the BAT DOES NOT stream on the CAN all the messages when we send from an ETH board the discovery signal. However, we are still not able to discover the CAN boards beneath the ETH board, which we are asking to be discovered. Therefore, there's still this problem which does not only depend on the fact that before the BAT board was making the CAN bus dirty.
For sure the aforementioned feature is necessary for aligning the BAT board to the standard behavior of all the other CAN boards, but we have still to study the discovery of the CAN board.

cc: @valegagge @sgiraz

[github-actions]

This issue has been automatically marked as stale because it did not have recent activity. It will be closed if no further activity occurs.

[github-actions]

This issue has been automatically closed due to inactivity. Feel free to open it again if needed.