Error loading embedded model

Hello, I saved/added my own model into the OpenMV firmware using this guide
It suggests using the tf.load_builtin_model() function to load the model. I have been using the following code (embedded in boot.py):

 try:
        net = ml.Model("model.tflite", load_to_fb=True)
    except Exception as e:
        print("Failed to load model:", e)
    print("Free memory after loading classification model:", gc.mem_free())
  try:
      labels = [line.rstrip('\n') for line in open("model.txt")]
  except Exception as e:
      print("Failed to load labels:", e)

I keep getting this error:

Failed to load labels: [Errno 2] ENOENT
Error in prediction: 'NoneType' object has no attribute 'predict'
Traceback (most recent call last):
  File "boot.py", line 180, in <module>
OpenMV v4.5.9-322.g82449de5.dirty; MicroPython 38c1ae3e0; OPENMV4P with STM32H743

Is the issue with the way the model is being loaded? Should I be using the tf.load_builtin_model() function instead?

Update: When I tried with other TensorFlow examples, nothing is being loaded [could not find the file] besides fomo_face_detection. i guess the loading process net = ml.Model(“model.tflite”, load_to_fb=True) is ok but what could be the issue?

That guide is out of date. Ibrahim refactored it so that you don’t need to call load built-in model. You just pass the model name when creating the model.

For example, see the person detection example: openmv/scripts/examples/03-Machine-Learning/00-TensorFlow/tf_image_classification.py at master · openmv/openmv

The model name from the built-in ones is just person_detect. The tflite part is stripped. openmv/src/lib/tflm/models at master · openmv/openmv

Thank you; I implemented that. The model wasn’t loading still; I removed all pre-existing models from the board beside my own. Also, I tried @ajacobs’s method of renaming it as fomo_face detection; I did not observe any errors (“couldn’t find the file”), and the model ran with some modification on my part.
My project involves running two models in succession: a classification model and a segmentation model. While I have managed to get the classification model working, I am encountering an issue loading multiple models.
The classification model only runs when I name it fomo_face_detection. However, when I try to load another model (the segmentation model) using different names, it fails to load. I have attempted using other built-in model names, but unfortunately, this has not resolved the issue. It seems the models only work if they are named fomo_face_detection. I tried it with the segmentation model as well, it only runs when named fomo_face_detection as well.

Do you have any guidance or recommendations on how to handle this?

Hi, I’m not sure exactly what the error is. If you see the RT1062 firmware there are clearly more than one model with it’s default firmware build that can be loaded with different names.

So… something is likely going wrong in the generation process for building the firmware. Maybe it needs to be cleaned before building?

Note, we are working on a massive firmware update that will be released shortly where we are switching to something called ROM FS. This will move all the models and binary resources out of the firmware image and into a new partition on the FLASH which can be treated as a linear filesystem for direct execution in place by the processor. The IDE will then have a new updated feature which allows you to load resources to this flash. Finally, accessing it will be via standard file paths. Once this lands you will no longer need to bother with all of what you are doing. Note that the bootloader for the board will have to be updated to for this feature.

Add VfsMap filesystem, mpremote deploy-mapfs, and ability to import .mpy files from ROM (WIP) by dpgeorge · Pull Request #8381 · micropython/micropython

oh sorry I forgot to mention I am working on OPENMV H7 plus. I did make sure to follow everything to the bone during build, so I am not sure if that could be the problem. Also, how long on the status of the new update ? I need to finalize this for a work project within the next two weeks.

I did not read the whole thread, but it sounds like you’re having trouble embedding a model. Did you see the comment here:

You could always check the generated file in build/lib/tflm/tflm_builtin_models.c to see exactly which networks are included and if they’re enabled or not.
Also with the next release, which is due in a month or so, all of this is gone anyway; you’ll be able to just copy tflite files to storage via the IDE.

The file generated in build/lib/tflm/tflm_builtin_models.c is fomo_face_detection_only.c. Initially, when building the firmware using the default method, which involves loading custom models only in the src/lib/tflm/models directory, the firmware was throwing various errors https://forums.openmv.io/t/openmv-h7-build-error/10498
so i tried listing the model in the index.csv file, the errors disappeared.
For the OpenMV H7+, I attempted to make changes in the src/omv/boards/OPENMV4P directory since the second case is working for me. If I enable it in the board.config, it should work, I assume.
I made changes in the same way they were done for builtin_models in the imlib_config.h file

//Enable custom model

#define IMLIB_ENABLE_TFLM_BUILTIN_MODEL_SEGMENTATION

but i have encountered many errors

openmv/src/lib/tflm/libtflm/include/tensorflow/lite/c/common.h:31,
                 from /home/openmv/src/lib/tflm/libtflm/include/tensorflow/lite/micro/micro_op_resolver.h:18,
                 from tflm_backend.cc:38:
/home/openmv/src/lib/tflm/libtflm/include/tensorflow/lite/core/c/common.h:1463:10: fatal error: utility: No such file or directory
 1463 | #include <utility>
      |          ^~~~~~~~~

How can I enable them correctly?

Hi, those compile errors on that library suggest that the tools aren’t setup correctly. I would recommend to check to make sure you followed how the automated build system setups your environment.

I have never gotten the compile error you are dealing with. This suggests that gcc doesn’t have the right search paths… which are specified by our makefile. So, this wouldn’t break unless the tool setup is different.