Make the BAT compliant with the FW update

[valegagge]

Recently we noticed that when the BAT is connected to the EMS, it is not possible to discover the 2foc boards connected to the same EMS board.

We already investigated on this issue and decided to fix it making the BAT silent when the FW updater is run. In other words, the BAT starts silently on the CAN channel, while continuing to update the screen.

The EMS will send the message SET_TXMODE of analog polling class with payload 0 when the BAT service starts by YRI.
On reception on this message, the BAT starts to send its info on CAN as its usual rate(100 ms)

When the YRI is shutting down, and all devices are closing, the EMS will send the same message but with payload 1.
On its reception, the BAT stops to send data.

NOTE: please check TSD-ICUBUNIT-canprotocol-sensorboards.docx for more details about the CAN message

Dod

• EMS and BAT update
• FW PR done
• tests done: the BAT starts silently and it sends CAN frames only when YRI is running.
• The fw update of 2foc connected to the EMS with BAT board runs successfully

[MSECode]

Here the working branches of this feature:

• icub-firmware
• icub-firmware-shared

Basically we have done the following updates to EMS and BAT code:

• in the EMS, in the service embot_app_eth_theBATservice we have update the methods can_battery_TX and can_battery_TXstop in order to start and stop the CAN frame transmission of the BAT iff the ems has been started.
• in the BAT, we have filled the callback function triggered by the receiving of messages over CAN, checking that the CAN frame defining the start and stop of the transmission sent by the EMS is received and with which value. If 0 we start transmission, if 1 we stop it

In this manner we can start the BAT board as silent and we enable the transmission iff the YRI is up and running, so that we do not flood the CAN bus with messages while the ETH boards are in CAN GATEWAY MODE, while doing the Discovery in the FIrmwareUpdater

With only the BAT attached we can see that the updates work, as a matter of fact, here the result of a discovery operation:

[valegagge]

Hi @MSECode ,
just a clarification: your setup is composed of:

• one EMS
• one BAT board connected to one CAN port of EMS
• 2 2FOC boards connected to the other CAN port of EMS.

Is this correct?

In this setup, that is equal to the situation on the robot, the firmware updater and yarprobotinterface work as expected, do they?

[MSECode]

So the setup, or to be precise the portion of the setup I've used, which is the only one connected via ethernet, is composed by the following boards:

• 1 EMS
• 1 BAT
• 1 FOC
• 1 MTB4
• 1 STRAIN

As you can see from the image below, the boards are the ones described

Then, as highlighted by the FirmwareUpdater window, all boards are correctly found

The tests I've done to check that our code is working as expected are the following:

• first, as shown above, I've just started the FirmwareUpdater and the CAN board discovery --> this is done to check that the BAT starts silent, therefore the CAN frames streaming is disabled
• then, I've tried to start the YRI and checked that the BAT is streaming --> this is done to check that the EMS correctly sends the transmission enabled command to the BAT, which reads it correctly, and starts the stream
• finally, I've stopped the YRI and re-discovered the CAN boards, to check that the BAT CAN frames streaming is now disabled --> this is done to check that EMS sends the STOP of the transmission when the YRI is going to be closed

All works as expected and the CAN boards are always found.

[valegagge]

Create pr for robots config with bat address 2.

cc @MSECode @valegagge

[valegagge]

In addition, while we were developing this feature, we noticed that the embObjBattery sends an empty CAN-monitor configuration. This creates an unexpected behavior: the CAN-monitor checks the presence of the battery boards with a period lower than the battery board transmission period.
To fix this issue, we decided to work at two level:

1. at fw level, we will add a check in the battery service object that set 250 ms as the default period for the CAN monitor, in case the CAN monitor configuration is empty: --> Improve the CAN monitor configuration inside the embot_app_eth_theBATservice #454
2. at embObjBettery level, we'll add the persing of CAN monitor configuration: --> Make the CAN-monitor configurable in the embObjBattery icub-main#927

Create pr for robots config with bat address 2.

cc @MSECode @valegagge

We decided to address this sub-task in a new issue with the check of the empty CAN monitor configuration.

Just a more note about the need to set the address 2 to the bat board.
Currently, bat and bms boards send periodic messages using a different protocol from the one we employ on our robots sending messages with ID from 620 to 629.
In our protocol each digist has a meaning, in detail, the digit 2 is the address of the boards, which is used by the CAN monitor to check the presence of the board.
Therefore, to adapt the bat and bms protocol to our protocol and be sure that the ethernet boards can manage correctly their messages, we need to define the bat and bms board with address 2.

Anyway, the Dod is satisfied.