ergoCub 1.1 S/N:001 – Unable to read the data coming from the BMS/BAT

[S-Dafarra]

Robot Name 🤖

ergoCub 1.1 S/N:001

Request/Failure description

The values read from the ports /ergoCub/battery/bms/data:o and /ergoCub/battery/bat/data:o return 0.0 nan 0.0 nan 0

Detailed context

Discussing with @MSECode and @AntonioConsilvio, this is due to the BMS and BAT not connected to the EMS.

Reading the value of the battery status can be very helpful, especially during long demos where the robot is completely wireless

Additional context

No response

How does it affect you?

No response

[S-Dafarra]

cc @gabrielenava as there might be a similar issue on iRonCub

[AntonioConsilvio]

Hi @S-Dafarra, the BMS and the BAT boards are temporarily disconnected. We will connect them asap!

[AntonioConsilvio]

Hi @S-Dafarra, today I connected the boards!

Let us know if them works as expected!

cc @sgiraz

[S-Dafarra]

Thanks @AntonioConsilvio!

Now the bms seems to work as expected. For the bat instead, there are still some nan, while I noticed that the voltage value was pretty low (4.4 V if I recall correctly, I only managed to do a quick test), while the current value oscillated between nan and about -1.

Another thing I noticed is that when the battery is off (and hence the battery charge is 0), many warnings are thrown in every terminal we open in the torso about the battery being critically low. This can be pretty annoying.

cc @isorrentino

[DanielePucci]

cc @gabrielenava as there might be a similar issue on iRonCub

It seems to me as well, please @gabrielenava open an issue for fixing this, thanks.

[AntonioConsilvio]

cc @MSECode

[MSECode]

For the BAT the current should always be nan because we are not transmitting it because on the BAT is calculated by the ADC, which gives a value that is not highly accurate, so it was decided to not send it to the EMS. Moreover, we did not want to send 0 since it could be an acceptable value. Here the values sent by the BAT are specified: https://icub-tech-iit.github.io/documentation/battery_boards/bat_board/bat_protocol/

For the error on the YRI, if it is the one regarding that the battery charge is critically low, it is given by the api getBatteryCharge() of the yarp interface iBattery. I'm gonna check that anyway and see if it can be suppressed when the battery is not attached

[S-Dafarra]

For the error on the YRI, if it is the one regarding that the battery charge is critically low, it is given by the api getBatteryCharge() of the yarp interface iBattery. I'm gonna check that anyway and see if it can be suppressed when the battery is not attached

Thanks!

For the BAT the current should always be nan because we are not transmitting it because on the BAT is calculated by the ADC, which gives a value that is not highly accurate

Even if not very accurate, it would be helpful to have a coarse measurement. In this way, we may have an idea of the power consumption even when not running in battery mode.

[valegagge]

For the error on the YRI, if it is the one regarding that the battery charge is critically low, it is given by the api getBatteryCharge() of the yarp interface iBattery. I'm gonna check that anyway and see if it can be suppressed when the battery is not attached

Thanks!

For the BAT the current should always be nan because we are not transmitting it because on the BAT is calculated by the ADC, which gives a value that is not highly accurate

Even if not very accurate, it would be helpful to have a coarse measurement. In this way, we may have an idea of the power consumption even when not running in battery mode.

cc @maggia80

[MSECode]

But you should have an accurate value looking at the BMS port, since the BMS gives a good value. It should always gives you values. I'm not very confident in the fact that is a good idea having a coarse measurement given by the BAT, considering it is also averaged. It can be then be misleading in my opinion. I suppose that if you need the instant current you can look at the bms data from that port, since it is now connected.

[S-Dafarra]

But you should have an accurate value looking at the BMS port, since the BMS gives a good value. It should always gives you values.

We don't have the BMS data if the battery is off 😉 (or completely disconnected, as in iRonCub)

[MSECode]

Oks, I've spoken with @maggia80 and @valegagge and it's ok to send the data of the instantaneous current even if it's not highly accurate. Anyways, please add here as a list all the improvements you need and I'll schedule the work.

[S-Dafarra]

Anyways, please add here as a list all the improvements you need and I'll schedule the work.

I would say:

• allow retrieving the voltage and current values also when the BMS is off
• avoid spamming the terminals if the battery is off

[sgiraz]

Hi @S-Dafarra,

The main problem seems to be solved after the intervention of @AntonioConsilvio in https://github.com/robotology/icub-tech-support/issues/1715#issuecomment-1900016881.

Anyways, please add here as a list all the improvements you need and I'll schedule the work.

I would say:

• allow retrieving the voltage and current values also when the BMS is off
• avoid spamming the terminals if the battery is off

Before closing this issue, I would open a separate ticket to track the development of the 2 features requested above.

cc @MSECode @AntonioConsilvio @valegagge @Nicogene

[S-Dafarra]

Before closing this issue, I would open a separate ticket to track the development of the 2 features requested above.

Related ticket: https://github.com/icub-tech-iit/tickets/issues/3343

[sgiraz]

Thanks @S-Dafarra,

I close this issue then!

cc @AntonioConsilvio @MSECode @valegagge @Fabrizio69 @Nicogene