Some questions about using HTM for battery prediction


I’m working on my dissertation and I want to use HTM for battery prediction. For example, predicting remaining power based on battery voltage and current, which is battery SOC. Data sampling interval is the same. Do I have to use the Temporal Memory algorithm in this case? I think because nupic.torch is a sparse CNN implementation. No Temporal Memory algorithm here. If it has to use Temporal Memory algorithm, does this mean that nupic.torch cannot be used? In this case I can only use htm.core?

Should multi-dimensional inputs like voltage, current, temperature, etc. use multiple encoders? Then concatenate all these encodings into one large encoding for Spatial Pooling.

I see the related translation will translate “Pooling” in “Spatial Pooling algorithm” into “pond”, I think it should be translated into “clustering”. Maybe my words are inaccurate, but that’s probably what I mean.

Any help would be much appreciated.

I do this a lot for my day job. You did not specify the battery chemistry but I will assume that it is NMH or one of the many lithium variants.

The problem requires that you consider the amount of remaining charge and the rate of charge delivery and temperature as the charge is delivered. The voltage is stable enough that it is almost not helpful in relation to these other factors; the voltage output is mostly flat until it drops rapidly. In real life circuitry measuring this voltage to the precision necessary to gain useful information is surprisingly expensive. Yes, our A/D converter is 18 bit and should be up to the job but you have to add in some very expensive precision resistors and switching circuitry to be able to read the battery. You have to make sure that this circuitry is temperature stable. The voltage changes are small enough that noise is an important factor, as is PSRR. (Power Supply Rejection Ratio)

To be complete you should also factor in how many charge discharge cycles as this affects these curves.

Ideally you need a coulomb (down)counter with dynamic adjustments for C rate and temperature.

I don’t see this as a good fit for HTM.

If this is in a real circuit I would include a safety cutout if the voltage drops below some predetermined point to avoid battery damage if all the above does not work. Good luck with picking the right voltage for all the factors named above - and variations in the circuit performance.


@chenjunyi I agree with @Bitking that HTM doesn’t fit this problem. The nupic.torch implementation is not a complete HTM implementation. It attempts to apply sparsity to CNNs and other networks in a fashion similar to Spatial Pooling.

And yes, pooling is like clustering. It is a remapping of semantic meaning from one context to another.

1 Like

@Bitking Thank you! Yes, it is lithium battery. Since I saw many papers on battery prediction using artificial neural networks, I thought of using HTM to achieve. In some papers, several specific points in battery life, different discharge currents, different ambient temperatures and other related data are used to train neural networks.

@rhyolight Thank you! Regardless of this application, should multi-dimensional input use multiple encoders? How to determine and optimize initial parameters? For example, the “size” in “RDSE_Parameters”, the “columnCount” in “SPRegion”, etc. Or are these initial parameters unimportant because of online learning? Since htm.core is a branch of nupic.core, although the algorithm API has been modified, the same initial parameters should get the same result, right?

Generally yes.

You should experiment for each field you’re encoding. It depends on the data and the trends in the data over time. Get a sense for encoding numbers with these interactive examples (WIP).