Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Battery Smbus enhancements #15369

Merged
merged 1 commit into from
Aug 19, 2020
Merged

Battery Smbus enhancements #15369

merged 1 commit into from
Aug 19, 2020

Conversation

BazookaJoe1900
Copy link
Member

Describe problem solved by this pull request
The sbmus driver has many fixes and functional updates that can be done.

  • fixes - many code clean ups and optimizations
  • fixes/upgrade - how to behave when there is smbus interface errors
  • upgrade - support BQ40Z80 device
  • upgrade - publish mavlink SMART_BATTERY_INFO

Describe your solution
This PR is WIP to start and update the driver. it just cleanups before the "real work".
it can be merged, so the real work will be done on next step

Test data / coverage
I am working with BQ40Z80 only, and not BQ40Z50. (the code for the BQ40Z80 has not been pushed on first commits)
so if there someone that can test the code with BQ40Z50, to ensure nothing has break, that will be helpful

Additional context
Pr batt smbus stability #14409
SMBus battery (a.k.a. smart battery) enhancement. #14496

@dagar
Copy link
Member

dagar commented Jul 19, 2020

Looks good so far. I don't really have anything on hand to test this code. Any suggestions?

Bigger picture architecturally we really need to do something to split the messages for simple analog power modules and smart batteries. The existing battery_status is looking rather overloaded.

@BazookaJoe1900
Copy link
Member Author

BazookaJoe1900 commented Jul 19, 2020

Looks good so far.

Do you want to merge those changes, and further work to be done on other pr?

I don't really have anything on hand to test this code. Any suggestions?

I have tested it with mine BQ40Z80 based battery. @limhyon @dakejahl do you have setup to test with BQ40Z50?

Bigger picture architecturally we really need to do something to split the messages for simple analog power modules and smart batteries. The existing battery_status is looking rather overloaded.

@dagar I have the next proposal (That I have already implemented on my repo...).
all the data you can take from analog is already on SYS_STATUS message:

  • voltage_v
  • current_a
  • discharged_mah

leave it there.

the only thing that isn't there is the warning, but look at that, you have the "errors_count1" on SYS_STATUS which doesn't being used at all..... can we put the warring there?

only publish smart battery data on "BATTERY_STATUS", I have actually made new "SMART_BATTERY_STATUS_EXTENDED" that combine "BATTERY_STATUS" and "SMART_BATTERY_STATUS", if that something worth doing on master, tell me and I will make new pr for review.

@BazookaJoe1900 BazookaJoe1900 changed the title WIP: Battery Smbus enhancements Battery Smbus enhancements Jul 19, 2020
@BazookaJoe1900 BazookaJoe1900 marked this pull request as ready for review July 19, 2020 20:27
Copy link
Contributor

@dakejahl dakejahl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, please see suggested changes.

edit: I do not have hardware to test this against btw

@BazookaJoe1900 BazookaJoe1900 force-pushed the pr-smbus branch 2 times, most recently from 367dca9 to e68b4ac Compare July 19, 2020 21:17
@TSC21
Copy link
Member

TSC21 commented Jul 19, 2020

@themcfadden you might want to review this as well.

@BazookaJoe1900
Copy link
Member Author

Thanks all for the comments!
I have general question, how do you see the "resolve conversation" should be handled? does the one that open it should press it? or the one that "answer" to the conversation?

@dakejahl dakejahl self-requested a review July 19, 2020 21:23
dakejahl
dakejahl previously approved these changes Jul 19, 2020
@BazookaJoe1900
Copy link
Member Author

@dagar I see now a build issue for linux builds, because of using crc8ccitt() function, which is a nuttx function.
any suggestion how to solve it?

@TSC21
Copy link
Member

TSC21 commented Jul 19, 2020

@BazookaJoe1900 I would like to get some feedback from @themcfadden as he's using a BMS with the Texas BQ40Z80, which required also some mods on this driver.

@TSC21
Copy link
Member

TSC21 commented Jul 19, 2020

@dagar I see now a build issue for linux builds, because of using crc8ccitt() function, which is a nuttx function.
any suggestion how to solve it?

Well this needs some support added, but a workaround is use some prepocessor directives.

@BazookaJoe1900
Copy link
Member Author

@BazookaJoe1900 I would like to get some feedback from @themcfadden as he's using a BMS with the Texas BQ40Z80, which required also some mods on this driver.

great, looking for @themcfadden notes about current pr. but pay attention that the BQ40Z80 related code has not yet merged, I didn't want to mess this pr with much more changes that are pending in my repo...

@dakejahl
Copy link
Contributor

dakejahl commented Jul 19, 2020

crc8ccitt() function, which is a nuttx function. any suggestion how to solve it?

Add back the CRC calculation code and wrap it in preprocessor directives for not __NUTTX

@@ -55,7 +56,7 @@ BATT_SMBUS::BATT_SMBUS(I2CSPIBusOption bus_option, const int bus, SMBus *interfa
_batt_topic = orb_advertise(ORB_ID(battery_status), &new_report);

int battsource = 1;
param_set(param_find("BAT_SOURCE"), &battsource);
param_set((param_t)(px4::params::BAT_SOURCE), &battsource);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, maybe we should leave this alone until we can take a dedicated look at C++ param usage separately. The px4::params enum is really only meant to be used with ModuleParams, however I don't see why we shouldn't use it directly with along with a few other new helpers.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dagar Done

}

if (lifetime_data_flush() == PX4_OK) {
// Flush needs time to complete, otherwise device is busy. 100ms not enough, 200ms works.
px4_usleep(200000);
px4_usleep(200_ms);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be careful here if this is executed from the WQ thread (I2C bus). This is long enough to cause magnetometer or barometer timeouts if sharing the same bus.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that actually is simple refectory, so if there was problem before, it will be still a problem.
I am not sure how to handle that comment....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll take a closer look when I have some appropriate hardware on hand.

@dagar
Copy link
Member

dagar commented Jul 20, 2020

@dagar I have the next proposal (That I have already implemented on my repo...).
all the data you can take from analog is already on SYS_STATUS message:

I was actually only talking about battery_status within PX4, but yes it's a problem at the mavlink level as well.

the only thing that isn't there is the warning, but look at that, you have the "errors_count1" on SYS_STATUS which doesn't being used at all..... can we put the warring there?

I'm not sure of the exact details here, but in general to me it's a question of it being useful/actionable. Does an operator actually need that information for preflight or during operation?

@themcfadden
Copy link

Thanks @TSC21 for pulling me in. We are using the the BQ40Z80 in our battery design.
From my quick look this morning, I'm really liking all the good work here (@BazookaJoe1900).
I'd like to go over it in more detail, but I'm tied up again today and may not get to it until tomorrow. So if you can give me another day or so, that would be much appreciated.

@themcfadden
Copy link

I've had a chance to dig into this a bit more. As I said before I think the changes are good and don't want to hold anything up any longer.

The reason we designed a battery with the BQ40Z80 was to support 6S, which we need to meet a flight time requirement.
Given that the focus of the PR is to clean things up, I see that it does not add support for the additional cells (which was the main thing I was hoping to review).

What are the plans for this driver moving forward? Will it support the additional cells in the future?

We have it working with 6S, and I can help out with code submissions, reviews, and/or testing.

@BazookaJoe1900
Copy link
Member Author

BazookaJoe1900 commented Jul 22, 2020

@themcfadden

What are the plans for this driver moving forward? Will it support the additional cells in the future?

I am working with the BQ40Z80 too, and there is a bit more of just adding the extra cells due to compatibility differences.
I am already flying with updated code. so in the matter of functionality everything works.
there are other enhancement I made that should be discussed before I will feel confidence to merge, each can be discussed separately :

  • the current driver changes BAT_SOURCE parameter if it don't detect the smart battery. I don't think its right, if you should have smart battery and didn't detect it, its bad. you should warn the user.
  • the driver works at 10Hz, from what I understood the BQ data sample at 4Hz only.
  • the current driver seal/unseal the battery. I disabled that on my case. I don't think its smart to do it, unless you know what you are doing and you are in "maintenance mode".
    this behavior can be changed to be controlled only if some parameter enable it
  • the current driver changes the under voltage protection during flight, I think that should be done by well defined configuration on the battery, and not by controlling the BQ during flight.
    as above, this behavior can be changed to be controlled only if some parameter enable it
  • there are more efficiency staff to do, such reading blocks of data instead of single registers.
  • there is aslo issue of how to handle bad cases that there is interface errors

@dagar do you want me to add the Z80 code? or maybe to do some branch to the branch?

*EDIT - I have added basic code to use with Z80, for review and notes

@dagar
Copy link
Member

dagar commented Jul 23, 2020

If this has been and can pass CI I'm happy to merge other than 2 minor thing.

  1. the param usage
    • let's follow up and add a new proper c++ api for use with px4::params::BAT_SOURCE
    • it's not okay (yet) to use the enum directly as it skips the param_find which marks the parameter active
  2. the NuttX ifdef for crc8ccitt() usage
    • I would drop this temporarily and we can do a quick pass to get the CRC lib in place, or even just pull in crc8ccitt() for posix. It's taken quite a long time to get to real cross platform drivers, I'd rather not let fragmentation creep in.

* @value 1 BQ40Z50
* @value 2 BQ40Z80
*/
PARAM_DEFINE_INT32(BAT_MODEL, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BAT_MODEL is a bit too generic. Maybe something like BAT_SMBUS_MODEL?

I'd also consider just skipping it entirely if the battery is easy to identify.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will be happy to make it auto-detect, and I am sure it possible, but didn't had time to do it.
any way, I only have the Z80 to check it with, so I will need someone with Z50 to check it too

@dagar
Copy link
Member

dagar commented Jul 23, 2020

CI failing due to fmu-v2_default flash. Can you try merging current master into this branch or rebasing to see if it'll fit now?

Screenshot from 2020-07-23 10-51-02

EDIT: Looks like you already did before I hit "comment".

@BazookaJoe1900
Copy link
Member Author

@dagar anyway, don't merge before @themcfadden review, and functional tests please

@themcfadden
Copy link

listener battery_status is not showing individual cell voltages because the new_report.voltage_cell_v[] is not being populated. It is a 3 line change. Should I push it?

Otherwise it looks good.

@themcfadden
Copy link

themcfadden commented Aug 14, 2020

I don't seem to have access rights to push. Here's the patch It is super simple.

commit 683f8e0c666028d5202116a2c5ba4006b146e359
Author: Matt McFadden <[email protected]>
Date:   Fri Aug 14 12:35:15 2020 -0600

    batt_smbus: Added missing cell voltages to battery_status_s.

diff --git a/src/drivers/batt_smbus/batt_smbus.cpp b/src/drivers/batt_smbus/batt_smbus.cpp
index 25ea6c74b1..f3c83a5a89 100644
--- a/src/drivers/batt_smbus/batt_smbus.cpp
+++ b/src/drivers/batt_smbus/batt_smbus.cpp
@@ -171,6 +171,9 @@ void BATT_SMBUS::RunImpl()
 		new_report.serial_number = _serial_number;
 		new_report.max_cell_voltage_delta = _max_cell_voltage_delta;
 		new_report.cell_count = _cell_count;
+    for (int i = 0; i < _cell_count; i++) {
+      new_report.voltage_cell_v[i] = _cell_voltages[i];
+    }

 		// Check if max lifetime voltage delta is greater than allowed.
 		if (_lifetime_max_delta_cell_voltage > BATT_CELL_VOLTAGE_THRESHOLD_FAILED) {

@themcfadden
Copy link

A couple more comments:

  • The driver was tested on the bench against our 4S BQ40Z50 Teal One battery, and
  • against our new 6S BQ40Z80 battery
  • With the latest stuff, QGC complains about some of the BAT params. I assume that is known.

- added support for BQ40Z80 based battery
- added performance counter for interface errors
- added SMART_BATTERY_INFO mavlink message
- general code cleanups and optimization
- fixed: void flooding the log in case of interface error
- fixed: using _batt_startup_capacity instead of _batt_capacity for discharged_mah
- update: read manufacture_date
- update: get _cell_count from parameter and not const 4
- update: avoid re-reading data that has already been read and stored on class already
- currently the battery type defined by BAT_SMBUS_MODEL parameter and not by auto detection
@BazookaJoe1900
Copy link
Member Author

BazookaJoe1900 commented Aug 14, 2020

@themcfadden - thanks for testing! I rebased, fixed more small staff and also fixed the cell issue you noted.
@dagar there is a 'ERROR [SPI_I2C] Bug: driver batt_smbus does not pass the I2C address to I2CSPIDriverBas' note on start up, but the driver works well. can you help me to solve? I am not sure what it is. (@themcfadden found that)

@BazookaJoe1900
Copy link
Member Author

@dagar this pr ready to merge. can you do that?

@dagar
Copy link
Member

dagar commented Aug 19, 2020

@dagar there is a 'ERROR [SPI_I2C] Bug: driver batt_smbus does not pass the I2C address to I2CSPIDriverBas' note on start up, but the driver works well. can you help me to solve? I am not sure what it is. (@themcfadden found that)

Let's take a look at that separately. It's harmless, but I would like to get rid of it.

@dagar dagar merged commit 190b96a into master Aug 19, 2020
@dagar dagar deleted the pr-smbus branch August 19, 2020 01:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants