Battery State Monitoring Configuration #131
Conversation
|
@MaEtUgR There is already a document that covers some of this material in QGC https://docs.qgroundcontrol.com/en/SetupView/Power.html Your docs is more informative, but it would also be good if we can keep some of the concise style of the QGC doc. Minimally we should link to it at the end, and steal the screenshot - a picture really does tell 100 words. Let me know when you're done and we can iterate together. |
|
Also note that those instructions also require that you measure the voltage at various points, which I think cuts out a lot of the need for discussion. Thoughts? |
|
@hamishwillee Thanks for taking this up. I somehow switched task in the middle and lost track. I try to write to a useful state probably this friday. I don't understand what you mean by
Looking forward to getting these instructions in. |
Well, if you can measure the full battery voltage, for example, then you don't really need to go into great detail that the nominal voltage is a certain value. To be honest I only scanned this so far, so it may be absolutely perfect. |
MaEtUgR
changed the title
|
I finally continued writing the on the document. I hope it's not too detailed but in my opinion if you want to configure the monitoring right you need to understand these basics and try it out otherwise you will just guess based on defaults and be unsatisfied... |
en/config/battery.md
Outdated
| 1. Select the **Gear** icon (Vehicle Setup) in the top toolbar and then **Power** in the sidebar. | ||
|
|
||
| You are presented with the basic settings that characterize your battery. | ||
|
|
There was a problem hiding this comment.
Insert QGC screenshot from https://docs.qgroundcontrol.com/en/SetupView/Power.html here.
en/config/battery.md
Outdated
| @@ -0,0 +1,81 @@ | |||
| # Battery and Powermodule Setup | |||
en/config/battery.md
Outdated
| @@ -0,0 +1,81 @@ | |||
| # Battery and Powermodule Setup | |||
|
|
|||
There was a problem hiding this comment.
Perhaps change introduction to this (the "span" is required by gitbook to properly render notes that follow each other.
The power setup for PX4 allows you to monitor the battery state and determine remaining available flight time.
> **Warning** Flying without sufficient power may lead to deep discharge of the battery. This can damage the battery and may lead to loss of vehicle control/crashes.
<span></span>
> **Note** PX4 battery monitoring requires hardware (typically a power module) to measure the battery voltage and the current between battery and vehicle.
There was a problem hiding this comment.
I didn't know, this time I saved the effort to have a gitbook rendered preview and worked with a simple mark down editor to save time...
en/config/battery.md
Outdated
|
|
||
| You are presented with the basic settings that characterize your battery. | ||
|
|
||
| ### Number of accumulator cells connected in series |
There was a problem hiding this comment.
Use first-letter capitalization on all headings (we're a bit inconsistent on this, but I'm trying to be more so). So ###Number of Accumulator Cells Connected in Series
There was a problem hiding this comment.
Good idea, I totally agree with that style, sorry for being inconsistent.
There was a problem hiding this comment.
Actually here we are mapping to a QGC screen, so we should match the text on the screen where possible.
en/config/battery.md
Outdated
|
|
||
| ### Number of accumulator cells connected in series | ||
| Batteries commonly rely on a chemical process to save and supply energy. The voltage across one atomic battery cell is given by the chemical properties of the battery type. | ||
| For example the byy far most common battery type for remote controlled vehicles are lithium polymer (li-po) accumulators with a nominal cell voltage of 3.7V. |
There was a problem hiding this comment.
typo 'byy'
What does nominal mean here - stated voltage on battery body? From what I read here the battery range for LiPo is about max 4.2 unloaded when full, and around 3.5V under load when "nearly empty". If the battery drops much lower (say 3.2V) then it is likely to be damaged. Correct?
There was a problem hiding this comment.
Yes, all your statements are correct.
3.7V is what is printed on every LiPo and what you generally assume the battery has when neglecting the variation because of the charge level and the load drop. It has the same meaning as 1.5V for your typical AA or AAA type alkaline batteries, they acutally don't have exactly this value but it's what you assume and use them for.
en/config/battery.md
Outdated
| You are presented with the basic settings that characterize your battery. | ||
|
|
||
| ### Number of accumulator cells connected in series | ||
| Batteries commonly rely on a chemical process to save and supply energy. The voltage across one atomic battery cell is given by the chemical properties of the battery type. |
There was a problem hiding this comment.
OK, so I prefer to have intro about section and simple how to instructions, THEN the explanation of how things work. This allows people to understand what they have to do, before seeing the detail. So in this case I would lead with the last line you added:
This setting sets the number of cells connected in series PX4 should monitor. Typically this will be written on the battery as a number followed by S. See the information below for more detail
There was a problem hiding this comment.
You are right, I think that's what I personally would prefer as a reader. I was going back and forth to make sure it's introduced before it's used like in a thesis and somehow lost the purpose.
en/config/battery.md
Outdated
| This setting sets the number of cells connected in series PX4 should monitor. | ||
|
|
||
| ### Full cell voltage | ||
| A chemical battery cells output voltage depends on many parameters like the way the battery was built, temperature, load, if the battery was damaged. But for a healthy battery under normal conditions with no load attached the remaining capacity is the main factor. |
There was a problem hiding this comment.
So again, start with the what they need to do in the setting:
This setting specifies the maximum voltage of each cell.
There was a problem hiding this comment.
It's not the maximum voltage of a cell. It's basically the lowest voltage you still want to cosider full (100%). If you set it to the absolute maximum you will never have the case in practise and therefore never have 100% before you start using your battery.
There was a problem hiding this comment.
Fair enough - my point is that this should state "setting information first", whatever that happens to be :-)
en/config/battery.md
Outdated
|
|
||
| ### Full cell voltage | ||
| A chemical battery cells output voltage depends on many parameters like the way the battery was built, temperature, load, if the battery was damaged. But for a healthy battery under normal conditions with no load attached the remaining capacity is the main factor. | ||
| Normal li-po batteries should be charged by dedicated charging devices such that each cell reaches a maximal voltage of exactly 4.2V. But after the battery was fully charged and is stored for later use the voltage starts to decrease even with no external load at all. |
There was a problem hiding this comment.
maximal -> maximum
So how should they determine what the maximum value is? Is this written on the battery or do they need to fully charge the battery, measure the voltage, and then divide by the number of cells?
You say that they should use a slightly lower value than the max. If the max was 4.2, what would you recommend they use?
There was a problem hiding this comment.
This is partly covered in my reply to your last comment. I would recommend the default value of the parameter. You basically want that your estimation shows 100% when you insert a full battery but a battery you charged a day ago or which was used a lot might not have 4.2V anymore when you plug it in. So you set it a bit lower than 4.2V but not too low such that you have 100% for the first 5 minutes of flight.
en/config/battery.md
Outdated
| That's why this setting should be set just a bit lower than the maximal voltage of a cell otherwise the fuel estimate will likely already be below 100% by the time you connect the battery to your autopilot. | ||
|
|
||
| ### Empty cell voltage | ||
| Most battery cells particularly also li-pos suffer a lot when they get used after they are "empty". To say if they are empty is not binary and not accurately possible by only knowing the cell voltage. |
There was a problem hiding this comment.
So again, start with a sentence explaining what is set here:
This setting specifies the minimum/empty voltage of each cell.
I understand from this is that "empty" is a very unclear value, but I don't understand what you should set it to - ie there is a lot of explanation of various times/conditions under which voltage can be measured, but I'm not sure what I should enter. I think based on this that you're suggesting the nominal voltage would be a good value. Is that correct?
There was a problem hiding this comment.
The problem is there is no clear definition of empty. It's all a tradeoff which usually has a sweet spot for your application. From a certain point on if you discharge your battery further the current battery life is longer but the battery will degrade more and you'll see the effect in the future. This is not linear which means at a certain point if you discharge just a bit further your battery gets a lot of damage. The common term which didn't come to my mind when I wrote it for discharging until the battery takes significant damage is "deep discharge". You'll find a lot of opinions about what the values are in the internet and batteries also have different quality levels and are getting better with new manufactoring technology.
There was a problem hiding this comment.
Thanks - I get that. SO how about:
This setting specifies the nominal minimum safe voltage of each cell (below which the battery may be damaged).
en/config/battery.md
Outdated
| This value highly varies depending on the momentary current draw from the cells. As a result you will see fluctuating battery percentages | ||
| * Rest voltage without a load when the battery is resting for some time | ||
| Best suitable measurement to infer charge status of the cell. | ||
| * Load compensated voltage calculated in air (under load) |
There was a problem hiding this comment.
Here you introduce "load compensation" but I know nothing about this, and neither will your reader. Is this something that is provided by a battery or by PX4 or by a power module. How would we know if this is enabled?
There was a problem hiding this comment.
Simplest explanation: The load compensated voltage is the voltage the battery would currently have without load but you are trying to guess it during operation and hence load. This is useful because the current discharge level can better be infered from a battery voltage when it is not under load.
PX4 uses a load compensated voltage value for its battery voltage estimation if configured to do so. The voltage you see in the UI and log is always the real measured voltage and never load compensated.
- If you set the parameter
BAT_V_LOAD_DROPit uses compensation based on the current total motor thrust which is an inacurate way of guessing the voltage without load because you assume the motor commands directly and instantaneously translate to electrical load. - If you set
BAT_R_INTERNALit uses compensation based on the current measurement which basically assumes an elecrical internal resistance model that is more accurate.
en/config/battery.md
Outdated
| * Load compensated voltage calculated in air (under load) | ||
| Ideally you want to have a load compensated voltage available during flight which reflects the rest voltage without load. but in practise the load compensated value will always be a bit below what you end up with because the battery "recovers" its unloaded voltage over time without gaining usable capacity. | ||
|
|
||
| ## Without load compensation |
There was a problem hiding this comment.
This is a level 2 heading, but appears to/may belong to the preceding heading/discussion on empty cell voltage. If it doesn't belong to that section then it is "floating" because at this point I don't know what "without load compensation" applies to.
There was a problem hiding this comment.
You can run the estimation without load compensation which is default, easiest to configure, worse performance compared to the other two methods. If you only set the "Basic Battery Settings" which are currently available directly in the Power UI of QGC you don't have load compensation.
I'm sorry if I structured it confusing, you basically have the following options:
- only set your cell count
-> setBAT_N_CELLS, (BAT_V_EMPTY,BAT_V_CHARGEDif you don't like the lipo defaults)
you get a coarse percentage estimation based on the voltage measurement which highly fluctuates depenting on load - reduce the fluctuation with load compensation
-> setBAT_V_LOAD_DROPorBAT_R_INTERNAL
you get a lot less offset while hovering and fluctuation but it's still voltage based - cobine the voltage based estimate with the accumulated used capacity
-> setBAT_CAPACITY
At system startup it does a voltage based estimate to know what value to start from. It changes the estimate according to the measured current which gets integrated (mathematical) over time to give the accumulated used capacity (this tracks the actual energy consumption super accurate). The emptier the battery gets, the more of the voltage based estimate gets fused in to prevent you from deep discharging it because you configured the wrong capacity or the start value was wrong. This is the most accurate because if you always start with a healthy full battery it's basically what a smart battery does.
If you have a current sensor available the acumulated mAh capacity can always be seen in QGC for personal reference if you press on the battery icon even if it's not used for the battery estimation.
en/config/battery.md
Outdated
| Ideally you want to have a load compensated voltage available during flight which reflects the rest voltage without load. but in practise the load compensated value will always be a bit below what you end up with because the battery "recovers" its unloaded voltage over time without gaining usable capacity. | ||
|
|
||
| ## Without load compensation | ||
| With the default parameter set there is no load compensation enabled because if you don't have a current sensor, it might be uncalibrated or the internal resistance of your battery is completely off the resulting compensation might not make sense. |
There was a problem hiding this comment.
What default parameter?
Are you saying that PX4 assumes that load compensation is not enabled by default (ie that there is no power module/current sensor)? Again, without knowing what compensation is and where it is implemented I can't understand this.
There was a problem hiding this comment.
Further to this, we're now talking about current sensors. Didn't we assume this would exist when we specified the power module should be used?
There was a problem hiding this comment.
You need a current sensor for load compansation based on current and for capacity accumulation. I've seen PX4 builds with no working power module with only voltage reading and with current reading...
en/config/battery.md
Outdated
| ## Without load compensation | ||
| With the default parameter set there is no load compensation enabled because if you don't have a current sensor, it might be uncalibrated or the internal resistance of your battery is completely off the resulting compensation might not make sense. | ||
|
|
||
| If you don't want to use load compensation set the empty cell voltage to the value that should result in 0% battery estimation. |
There was a problem hiding this comment.
I don't know what this means. Specifically "how would I guess the value that should result in 0% battery estimation"?
There was a problem hiding this comment.
Sorry I'm not super good at writing 😇
If you have BAT_V_EMPTY = 3.5V, ...
- ... you don't use load compensation and the battery reads 3.5V per cell under load you see exactly 0%.
- ... you use load compensation and the battery reads 3.5V per cell under load and it gets compensated to 3.55V per cell you see maybe ~8%.
Therefore if you want to tune your load compensation well for the vehicle battery combination you use it's best to have a log with data to see what value gives the best results. You can also tune by trial and error.
en/config/battery.md
Outdated
| ## With load compensation | ||
| If you use load compensation the empty voltage should be set higher than without because the compensated voltage gets used for the estimation. What you want to set is typically a bit below the expected rest cell voltage when empty after use. | ||
|
|
||
| ### With thrust based load compensation (not recommended) |
There was a problem hiding this comment.
Ah, so reading this section it sounds like you're saying that PX4 supports load compensation either via thrust based compensation (enabled by setting BAT_V_LOAD_DROP) or current based load compensation - for which you need a current sensor (in your power module?) and to set BAT_R_INTERNAL.
There was a problem hiding this comment.
Exactly, see also #131 (comment)
The current sensor is usually in the power module but can theoretically also be in each motor ESC because some ESCs have that anyways for e.g. field oriented control.
en/config/battery.md
Outdated
|
|
||
| The easiest way to calibrate the dividers is by using QGroundControl and following the step-by-step guide on https://docs.qgroundcontrol.com/en/SetupView/Power.html. | ||
|
|
||
| ## Combning voltage based estimation with current integration |
There was a problem hiding this comment.
Combning -> Combining
en/config/battery.md
Outdated
|
|
||
| ## Combning voltage based estimation with current integration | ||
| After tuning the voltage based estimation you can achieve a more stable linear and accurate estimation by fusing your estimate with the so far used capacity. This is only possible with accurate current measurements because the current gets mathematically integrated over time to have a used capacity estimate. | ||
| This is the best way to have totally accurate relative fuel consumption of the battery. You can not use only this technique because: |
There was a problem hiding this comment.
I do not know what you mean by "You can not use only this technique because:"
I think what you are saying is that to use the technique you have to know the current battery capacity. Normally that means you would need to start with a full battery.
There was a problem hiding this comment.
The best way to track the used energy is to measure the current and accumulate it over time. But we want to know how much energy is left in the battery and not how much we used. So we need to know how much energy was available from the battery when we started counting.
We estimate how full it was in the beginning using the voltage estimate and assume the battery has in total the capacity you configured in the parameter. If one of those assumptions is wrong the battery might last longer or be empty earlier than we think. The first leads to less flight time and the second to a crash. That's why we still need to fuse the voltage estimate all the time especially when the battery is nearly empty. And also why the voltage estimate should be configured usefully first/for sure.
As smart battery usually always follows the state of the battery even if your device is turned off, the battery is removed, the battery is charged, degrades with cycles or gets damaged. So it basically has all data inside for a really accurate estimation of how much energy is really left in the battery.
en/config/battery.md
Outdated
| * If the absolute fuel estimation is for some reason wrong or the battery is faulty you don't have feedback. | ||
|
|
||
| That's why you should always configure and tune the voltage based estimation first and then afterwards enable direct used capacity fusion. | ||
| To enable this feature make sure you have a working and safe voltage based estimation then set the parameter `BAT_CAPACITY` to around 90% of the advertised battery capacity which is usually printed on a label on the battery. |
There was a problem hiding this comment.
So what I think you are saying is that if you set BAT_CAPACITY and you have a current sensor, PX4 will estimate fuel consumption and let you know approximately how much you have left. You're also saying that you need to always have a full battery when you start so that you can set the capacity correctly.
- Is that right?
- If you don't set the BAT_CAPACITY what changes? PX4 just won't tell you how much fuel you have left in warnings?
There was a problem hiding this comment.
So what I think you are saying is that if you set BAT_CAPACITY and you have a current sensor, PX4 will estimate fuel consumption and let you know approximately how much you have left.
Yes
You're also saying that you need to always have a full battery when you start so that you can set the capacity correctly.
No, it will start off with a voltage based estimate but the initialization might be inaccurate so it's always best to start with a full battery. If you start or configure a wrong value the fusion of voltage based estimate towards the end should safe you from a crash (without warranty).
If you don't set the
BAT_CAPACITYwhat changes? PX4 just won't tell you how much fuel you have left in warnings?
All of this is to have a percentage estimation of how much of your battery capacity is left. Any method from #131 (comment) will give you a (more or less accurate and fluctuating) percentage and hence warnings and automatic low battery reactions. The parameter determines if you use the last method or not.
A remaining flight time is theoretically possible with the last method but not implemented yet.
en/config/battery.md
Outdated
| To enable this feature make sure you have a working and safe voltage based estimation then set the parameter `BAT_CAPACITY` to around 90% of the advertised battery capacity which is usually printed on a label on the battery. | ||
| Setting this value too large will not extend your flight time it will only result in worse estimation and a sudden percentage drop or if exaggerated to totally unreliable percentages. | ||
|
|
||
| If you set up all of this correctly and you use a healthy, fresh charged battery on every boot up the estimation will be comparable to a smart battery and theoretically allow for accurate remaining flight time estimation. |
There was a problem hiding this comment.
You mention smart battery here - is this something we need to mention in terms of setup?
There was a problem hiding this comment.
Smart batteries are industry standard for laptops, smartphones and also higher quality drones e.g. DJI. It is the future and makes this whole problem so much easier. The user does not need to care about any of this with a smart battery and the estimation will always be more accurate. It's basically what you're trying to achieve with cheaper resources...
I would mention for completeness but it's not mandatory.
|
Thanks @MaEtUgR , |
|
Sorry, I was absent. From the text in the comment here: #131 (comment) I assume you already started to do changes and I should not repeat them. Let me try to answer the questions and we go from there. |
|
I tried to answer everything as clear as I can, I hope that helps, I'm sorry if some of what I wrote is confuding. Thanks a lot for proofreading it and questioning the parts which are not understandable, that's super useful! |
|
@hamishwillee 's improvements: https://github.com/MaEtUgR/px4_user_guide/pull/1 I just found old documentation: https://pixhawk.org/users/battery_config |
That is actually pretty cool. What about if we put everything below "Parameters" into a "Parameter Summary" section at the end of the new doc? There would be some repetition, but I still think useful. I particularly like the graph. |
|
It's probably more efficient to get it in and continue improving on the comments in https://github.com/MaEtUgR/px4_user_guide/pull/1 upstream. |
|
Agreed! I have merged. I'll fix up some of those comments in https://github.com/MaEtUgR/px4_user_guide/pull/1 separately. |
|
@MaEtUgR Do you think it would be useful to pull in content from https://pixhawk.org/users/battery_config ? If so, can you pull in the diagram and examples? We should confirm with Lorenz that he is happy to take these, since Pixhawk.org does not belong to Dronecode. |
|
@hamishwillee The diagram is IMO useful, the examples are old, we should add new ones instead. |
@MaEtUgR OK. Can you do this? |
As @ndepal correctly pointed out in PX4/PX4-Autopilot#8153 (comment) the configuration of the battery state monitoring/estimation is currently not well documented.
This is my attempt to change this. I'm opening this PR because I recently (hopefully) improved battery estimation on PX4/master. After changing the algorithm and doing a lot of real world tests I feel like I should share how to achieve good results with the current state.
I will add to one commit and force push until I have a full structured text.