To account for the parameter definition.
My tests if quadratic is actually better in practise were anyways not conclusive.

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.

Battery: enhanced voltage, capacity estimate fusion, set empty voltage to a useful value for reasonable lipo usage

Battery: adapt output constraints to possible values, only calculate remaining capacity if capacity is configured

Battery: refactor _param out of the variable names and use 0.f for zero floats to make code more readable

Battery: simplify linear voltage relation, currently neglecting the real world voltage drop under load

fadfdasf

   Connected is assumed when the battery voltages is greater than
   a predefined level.

   system_source - This battery status is for the brick that is
                   supplying VDD_5V_IN
   priority      - Zero based, This battery status is for the brick
                   that is connected to the Power controller's
                   N-1 priority input. V1..VN. 0 would normally be
                   Brick1, 1 for Brick2 etc

  Battery now assigns connected from the api in the
  updateBatteryStatus, as well as system_source and priority

We need to differentiate between a level where the user should act and where we are about to fall out of the sky (emergency). This helps performing more suitable failsafe actions.

Battery charge estimation: Refactor the filtering strategy and move it to the backend, doing integration before and filtering the resulting charge estimate