I deployed my model in float32 C++ library format and run it on a ESP32 chip. I use signal_from_buffer() to create the signal and then feed it into run_classifier(). However, the classifier spits out invalid result with the class value of NaN (Not a Number). I did enable the DEBUG_NN macro and this is the list of generated features I get:
Features (7 ms.): 0.000000 nan nan -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 0.000000 nan nan -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 0.000000 nan nan -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 0.000000 nan nan -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 -10.000071 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 -3.000000 1000.000000 1000.000000 1000.000000 1000.000000 0.000000 0.000000 -3.000000
The nan values in the processed features show there is an illegal mathematical operations being performed like dividing by 0. I did try int8 model as well but the issue is still there. In the web portal it shows over 99% accuracy on the valuation data which tells me something is not quit right in the deployed model. Any idea what could be wrong?
Project ID:151742
I just had a quick look at your project and it seems that you added a raw data dsp block that you are not using.
Could you try to delete it and try again?
If the issue actually comes from there, I’ll ask our core engineering to investigate and fix the issue.
When the raw data dsp block is present and not used, I have a compilation error
I created a version of your project called Edge Impulse Support where I deleted the raw data dsp block, the compilation works but I am having the NaN error too.
I am creating an internal ticket so our embedded engineers can investigate.
@louis Thanks for looking into this. it’s one of the last minute issues that we didn’t expect. Unfortunately our debugging capabilities is limited here but looking forward to getting the updates.
@yanedge has identified the issue, a fix will be merged soon.
To give you more context, it comes from a standard deviation function which was not properly handled when all the input where zeros in the spectral feature block.