Error and fail malloc with Picodet network in espdl (AIV-747) #197
Comments
github-actions
bot
changed the title
|
@simoberny |
Thank you for your prompt response. The pedestrian example runs perfectly, but when I use my model, I still encounter the same error as before: The quantization process with ppq at the end prints out: Looking at the layers of the network seems really different from the pedestrian example tough. |
|
I add some information I found out. The problems seems to happen in the first concat element of the network (Concat.0), where converge a Resize and a Relu.6 activation.
For some reason it seems that the relu comes out with 70 items for the second factor instead of the 96 as expected.
|
|
@simoberny Thank you for your info. I did a super quick test. I am able to run the exported model without the assert failure, although the model inference result is incorrect. We will try to reproduce your problem and dig deeper to find out why the inference result is incorrect. |
|
@100312dog Yeah my bad, Windows was the problem, I was using a conda environment. Now it is panicking on inference call Update 17/02 I investigate some more, in the post process all the Tensor element seems to not be found, and become consequently null. TensorBase *score0 = m_model->get_intermediate("score0"); // --> nullptr
TensorBase *bbox0 = m_model->get_intermediate("bbox0"); // --> nullptr
TensorBase *score1 = m_model->get_intermediate("score1"); // --> nullptr
TensorBase *bbox1 = m_model->get_intermediate("bbox1"); // --> nullptr
TensorBase *score2 = m_model->get_intermediate("score2"); // --> nullptr
TensorBase *bbox2 = m_model->get_intermediate("bbox2"); // --> nullptr
if (score0->dtype == DATA_TYPE_INT8) { //<-- Accesing nullptr, panic'ed
parse_stage<int8_t>(score0, bbox0, 0);
parse_stage<int8_t>(score1, bbox1, 1);
parse_stage<int8_t>(score2, bbox2, 2);
} else {
parse_stage<int16_t>(score0, bbox0, 0);
parse_stage<int16_t>(score1, bbox1, 1);
parse_stage<int16_t>(score2, bbox2, 2);
} |
|
I understand that the ESP-DL post-processing code is designed for a specific network configuration. I tried replacing score0, bbox0 with the actual output tensors from my PicoDet XS model, which was trained on a custom dataset with a single "person" label: TensorBase *score0 = m_model->get_intermediate("save_infer_model/scale_0.tmp_0");
TensorBase *bbox0 = m_model->get_intermediate("save_infer_model/scale_4.tmp_0");
TensorBase *score1 = m_model->get_intermediate("save_infer_model/scale_1.tmp_0");
TensorBase *bbox1 = m_model->get_intermediate("save_infer_model/scale_5.tmp_0");
TensorBase *score2 = m_model->get_intermediate("save_infer_model/scale_2.tmp_0");
TensorBase *bbox2 = m_model->get_intermediate("save_infer_model/scale_6.tmp_0");I'm using three out of the four FPN scales (64, 32, 16), but the code gets stuck during parsing. Could you help me understand if I am making a conceptual mistake? Or is it possibile to have the picodet configuration to replicate the pedestrian example network. Thank you for your help |
Checklist
Issue or Suggestion Description
Hi, I'm trying to use a custom-trained Picodet network for person detection with ESP-DL, but I'm encountering an error when loading the model. My goal is to obtain a network similar to the one used in the pedestrian detection example, as I was informed that it is a modified version of Picodet.
I trained a Picodet XS with some modifications, using ReLU6 instead of hardswish as the activation function, to avoid opset 14 in the onnx format.
My setup version:
I successfully exported the .onnx model to .espdl using the provided tools. However, when I try to load the model using dl::Model, I encounter the following error:
If I try to load the model using the Pico Model from the PedestrianDetection example instead, the system attempts to allocate 223,827,472 bytes, which inevitably causes a crash.
Thanks in advance in any help!
P.S: Is it possible to have some insight on the parameter and the procedure used to obtain the model from pedestrian example?
The text was updated successfully, but these errors were encountered: