Updates to batt_smbus driver to add functionality and work with TI BQ40Z50-R1/R2 fuel gauge #8854
Conversation
| } | ||
| } | ||
| battery_status_s battery_status; | ||
| _battery.updateBatteryStatus(now, new_report.voltage_v, new_report.current_a, |
There was a problem hiding this comment.
I see why you did this, but I really think we need to find a better overall solution than having a low level battery driver subscribing to controller output like this.
There was a problem hiding this comment.
I agree, the sensors.cpp battery update process also relies on it.
| @@ -1014,60 +773,47 @@ batt_smbus_main(int argc, char *argv[]) | |||
| if (g_batt_smbus == nullptr) { | |||
| PX4_INFO("not started"); | |||
| batt_smbus_usage(); | |||
| return 1; | |||
| exit(1); | |||
There was a problem hiding this comment.
Please return an error instead of exiting. On Linux these modules are threads within a single progress, so exiting from a single module/driver kills all of px4.
There was a problem hiding this comment.
Woops, I was working off of the older one and not your new commit today.
|
@AlexKlimaj check the CI failures. |
|
@davids5 @ChristophTobler @bkueng it might be time to think about the system_power/battery_status architecture again. |
|
PEC is not enabled on the TI BQ40Z50-R1/R2 by default. So I left it out. I will add it back in as a check. |
|
I added PEC back in. Removed the call to update battery status which enabled me to remove the vehicle control mode and actuator controls dependency. I also added battery capacity to the battery uorb message. The total discharged is calculated based on the remaining capacity when the driver starts minus the current remaining capacity.
|
|
Added more functionality today.
|
Signed-off-by: Roman <[email protected]>
- simulated tailsitter needs a virtual elevator since we cannot simulate elevons yet (liftDrag plugin does not model longitudinal moment Cm) Signed-off-by: Roman <[email protected]>
AlexKlimaj
changed the title
This prevents the autopilot from sending an invalid unix timestamp. Usually, if no time is set yet by a GPS, the date is somehow set to 2000-01-01, therefore we can ignore anything earlier than 2001.
On the Intel Aero and probably also other specific platforms the first measured voltage values despite connected battery are unuasable. The solution here is to start filtering and determining warning only after a measurement above 2.1V was received.
This gets rid of a printf.
Signed-off-by: Roman <[email protected]>
When the timer callback is called at a higher rate than the logger can execute the main loop (which is never the case under normal conditions), the semaphore counter will increase unbounded, and eventually lead to an assertion failure in NuttX. The maximum semaphore counter is 0x7FFF, and when the logger runs at default rate (3.5ms), the logger task must be blocked for 0x7FFF*3.5/1000 = 114 seconds continuously for an overflow to happen. I see 2 cases where that could happen: - the logger execution blocks somehow, or busy-loops in an inner loop - a higher-prio task runs busy and hogs the CPU over a long period of time
Signed-off-by: Roman <[email protected]>
…arged is calculated
…battery uorb message
I have updated the batt_smbus driver to work with the TI BQ40Z50-R1/R2 fuel gauges.
Voltage and current are working correctly and using updateBatteryStatus to update uORB.
There are many more values I want to gather from the fuel gauge and get into a mavlink message. Would it be best to add them to battery_status.msg?
updateBatteryStatus in the battery driver is very geared towards battery measurements coming from the on board ADC's. I think it would be worth updating the battery_status.msg through the batt_smbus driver instead.
BATT_SOURCE also needs to be set to 1 to bypass reading the battery ADC's in the sensors.cpp driver.