Improve battery (BAT) data streaming and management

[MSECode]

Task description 📝

As requested and discussed in https://github.com/icub-tech-iit/tickets/issues/3343 some improvements should be developed for BAT board, specifically:

• currents streaming
• voltage streaming when connected to either batteries or power supply
• avoid spamming the terminals if the battery is off (we noticed that some warnings are thrown in the terminal when the BMS is off)

Definition of Done ✅

New fw tested and working as AMI group desires

[MSECode]

Working branches are the following:

• https://github.com/MSECode/icub-firmware-shared/tree/feature/batUpdate
• https://github.com/MSECode/icub-main/tree/feature/batUpdate
• https://github.com/MSECode/icub-firmware/tree/feature/batUpdate

[MSECode]

cc: @valegagge

[MSECode]

If sending from the BAT in the CAN packet 0x620 the voltage info as the BATTERY_VOLTAGE in the case in which the battery pack is not connected the value sent to the port is about 4.5V as shown in the image

We'll discuss about that and if change the value sent for the BAT only

[MSECode]

After F2F discussion w/ @valegagge and @maggia80 regarding multiple aspect about BAT we have decided the following:

• we can send the INPUT VOLTAGE for the BAT as the first 2 bytes of the CAN packet with id 0x620. Even if we know that we are using same network variables for both BMS and BAT and the same CAN packet we are modifying the meaning of the values for the BAT only so that we can give to the user all the pieces of information they need when using the system connected with either the power supply or the batteries. Therefore, even if the CAN message sent by the BAT differ from the one of the BMS regarding the protocol, the user can have always all the info
• adding the total current absorbed by the system on bytes 2 and 3 of the CAN message 0x620 sent by the BAT.
• evaluation of the Battery Charge on the BAT side should be revised and moved on the fw since the calculation is done with a frequency smaller than the streaming of its value
• as instead personally discussed w/ @valegagge, we are thinking to set the value of the battery charge to NAN on the yarp port (software side) when equal to zero, and then check if the error of the critical battery level is still spammed on the terminals

[MSECode]

So, as detailed above the following changes have been made:

• if battery charge raw value is zero on the high level we are setting it to NAN, so that we can somehow avoid spamming the terminals with the law battery charge message as shown here:

• changed the lower limit for the battery charge calculation from 33000 mV to 30000 mV according to the line identified on the graph of the robot battery discharge here:

In the image, I've tried to approximate the discharge curve with the red line. The green and yellow lines are 2 possible limits of voltage for the ~0% of charge. I've decided to use the minimum value of 30000 mV and the max value of 42000 mV since this gave me values that seems to be more in line with what sent by the bms (which is theoretically correct). I've used as comparison the data shown in the screenshot here: https://github.com/icub-tech-iit/tickets/issues/3343#issuecomment-1946269568
Even if not 100% accurate, especially when the SoC is low the line can be use to approximate the level of charge in the robot batteries. Now, at a first look to the values given by the setup used, which are shown here:

it seems that the battery charge percentage correlated to the instant voltage is close to the more accurate value given by the BMS. So I suppose that we can currently accept this approximation. Then, when tested on the robot we can see if the values between BAT and BMS are compatible or they differ a lot and eventually use an offset or change the order of the approximation for the curve to follow better the lower part of the discharge curve.

• finally now the total current absorbed by the system is sent up to the ems from the BAT as well as the temperature value.

Therefore, as things now, all the points requested on the ticket should be satisfied. Need to make some tests on the robot for checking the values obtained since I've done tests only on the bench setup.

[maggia80]

ok!

[MSECode]

I've done some tests on ergoCub, here the results:

Order of DATA for all is:

Voltage | Current | StateOfCharge | Temperature | Status

current status w/ battery switched OFF

BMS	BAT

current status w/ battery switched ON

BMS	BAT

updated status w/ battery switched OFF

BMS	BAT

updated status w/ battery switched ON

BMS	BAT

[MSECode]

I need to do another test using only the battery and disconnecting the power supply thus to cover all cases

[maggia80]

@MSECode good! so we should then update the documentation:

BAT board provides the voltage of the robot (coming either from power-supply or battery)
BMS provides the voltage of the battery

what about the current read from the BAT and the state of charge?
For the current we could fill the field with the total current consumption of the robot (the sum of the three currents: 42V + 12V motor + 12V cpu)
For the SOA we should show always the state of charge of the battery (calculated reading the battery voltage). In case the battery is OFF we should send a NaN. If it's on even if it's not used we can provide the SOC.

[MSECode]

yes, sure, the documentation needs to be updated. Then:

• Voltage: as you said
• Current: for BAT is total current absorbed by the system, for BMS the current in or out from the battery
• SoC: as you see is available only if battery is connected otherwise NaN and for BAT is calculated on the Voltage

[maggia80]

and for BAT is calculated on the Voltage

Which voltage? Should be the voltage of the battery if available.

[MSECode]

and for BAT is calculated on the Voltage

Which voltage? Should be the voltage of the battery if available.

Exactly. It is the Battery voltage as here:

Battery_charge = 100*(mean.V_BATTERY-Battery_low)/(Battery_high-Battery_low)

[maggia80]

updated status w/ battery switched OFF

BMS | BAT -- | --   |  

@MSECode when the battery is switched off you should read NaN because the voltage of the pin Battery_voltage should be 0.

[valegagge]

Hi @maggia80 ,
currently the BAT baord is publishing the temperature, I suppose related to the battery, but its value is very different from BMS one.

We checked the code of Battery, where it calculates that value, but it isn't clear to us. (Here the code. )

So the questions are:

1. is the BAT calculating the temperature correctly?
2. If yes, do we want to show a value that differs from the correct one so much? (~ double)

[valegagge]

Hi @MSECode,
hereafter the issue to address the documentation updates. icub-tech-iit/documentation#342 as we already discussed.

[valegagge]

After a f2f chat with @MSECode,
we would like to improve the status information related to the BMS and BAT. Currently both objects rely on the embObjBattery device which is not at all compliant with the BAT board.

Even if the best solution is to create an ad-hoc device and expose ad-hoc API in a new interface, we decided to give more significance to the status. we'll address this new feature in a new issue: robotology/icub-main#952

[MSECode]

Hi @maggia80 , currently the BAT baord is publishing the temperature, I suppose related to the battery, but its value is very different from BMS one.

We checked the code of Battery, where it calculates that value, but it isn't clear to us. (Here the code. )

So the questions are:

1. is the BAT calculating the temperature correctly?
2. If yes, do we want to show a value that differs from the correct one so much? (~ double)

I've checked the origin of that adc_values.Temp_sensor value. It is referred to this MACRO initialization:
#define LL_ADC_CHANNEL_TEMPSENSOR (LL_ADC_CHANNEL_17 | ADC_CHANNEL_ID_INTERNAL_CH) /*!< ADC internal channel connected to Temperature sensor. On STM32L4, ADC channel available only on ADC instances: ADC1, ADC3. */

And it is specifically the internal temperature of the microcontroller.
Therefore, I suppose that can be omitted from the values sent towards the user and added to the CAN message 0x620 since it is not informative to the scope of that CAN frame, since it could be quite different from both the battery pack temperature and the temperature of the system itself.

cc: @maggia80

[maggia80]

and for BAT is calculated on the Voltage

Which voltage? Should be the voltage of the battery if available.

Yes, I agree

[MSECode]

Results after tests on ergoCub001

After testing the latest firmware, which is available in this and linked PRs, the results are as follows.
First of all, now all the requested data are available and they allow the user to have a good idea of the status of the system and eventually of the battery pack specifically. The images that follows explain this.

On all the images it is possible to see the following important points:

• left-hand-side tab shows the YRI logs and it is possible to see that every 10s ( or depending on the value of embot::core::relTime periodofreport defined in the CANmonitor::Config defaultcanmonitorconfig set in the fw in the file embot_app_eth_theBATservice.cpp (for now is hardcoded and cannot be updated from the configuration. It will be possible after the completion of Make the CAN-monitor configurable in the embObjBattery icub-main#927 ))
• middle tabs shows the values printed on the yarp port ergocub/battery/bms/data:o that are in order: Battery_Voltage [V] | Current towards/outwards (+/-) the battery-pack [A] | battery-pack StateofCharge [%] | battery-pack Temperature [^C] | BMS_error_status
• right-hand-side tab shows the values printed by the yarp port ergocub/battery/bat/data:o that are in order: Input_Voltage [V] (Can be either the power-supply voltage or the battery voltage, the highest anyway) | Total current absorbed by the system (sum of hsm, cpu, motors) [A] | battery-pack StateofCharge [%] (But calculated using the Battery Voltage) | Not Used (NaN) | BAT_status

NOTES:

• In some screen there's no one of the port printed since the values are not informative because battery-pack switched off (BMS OFF) or power-supply not connected (BAT OFF)
• BAT yarp port values are defined to give to the user an idea of the status of the whole system (i.e. the robot)
• BMS yarp port values are defined to give to the user an idea of the status of the information related to the battery-pack
• If SoC raw value is equal to 0.0 we are setting its "yarp" value to NaN so that the terminal is not flooded with the Warning message of critical battery charge even when it is meaningless.

Values displayed on the yarp ports when we have both BMS and BAT enabled and working:

NOTES:

• Voltages are comparable
• BMS gives the current going out from the batteries (almost null since we have the power supply enabled)
• BAT is showing the total current absorbed by the system
• SoC (correct is the one of the BMS) but the one displayed in the BAT port is close to it (fine for us)

Values displayed on the yarp ports when we have both BMS and BAT device enabled by configuration but the battery-pack enabler switch is in OFF position:

NOTES:

• See on the logs that the canmonitor is notifying about the impossibility to find the device enabled
• All values of the BMS in the canmonitor are 0 or NaN
• In the BAT the SoC is NaN

Values displayed on the yarp ports when we have only BAT enabled (only power-supply):

Values displayed on the yarp ports when we have only BMS enabled (robot is powered by battery-pack):

cc: @valegagge @maggia80