Failed to convert PTQ model

[kortysukura]

Some errors occurred during the model conversion process. After modifying parts of the code, we successfully converted the model; however, issues with the resulting PTQ model emerged in subsequent processing steps. Could you please provide a pre-converted PTQ model for our research?

[kortysukura]

The issue with the previous PTQ model has been resolved, and the project has been successfully reproduced. However, when I replaced the data in example-data, I found that the .pthand .binfiles do not have a corresponding source for generation. As a result, the performance with the new data is very poor. Could you please provide the code for generating these two files, or specify the format of these files, so that I can make modifications and proceed with further research? Thank you.

[AlphaPlusTT]

Sorry for the late reply. I’ve been tied up with other deadlines recently.

Glad to hear that you have successfully reproduced the project.

This CUDA deployment project is developed based on Lidar-AI-Solution. You can refer to the documentation of Lidar-AI-Solution for detailed specifications of data generation formats. Since I’m currently occupied with urgent tasks, I won’t be able to offer relevant assistance in the short term.

As a small tip, you may use Codex to quickly analyze the required input data format.

[kortysukura]

Thank you for your feedback; I have indeed proceeded along those lines.
I have successfully established the full workflow from training to deployment. To streamline experimentation, I have transitioned to using a mini dataset. However, I encountered a gap regarding OCC labels, as there are few open-source implementations available. Consequently, I am currently focusing my research on OCC label generation and annotation strategies.
Despite various optimization attempts, the current results still fall short of our project requirements. It appears that modifying the dataset or the model architecture is necessary. Based on my research, improving the dataset is likely the most practical and impactful approach. For autonomous driving perception (OCC/BEV), the data is often the key differentiator. Although models and datasets are frequently shared, the documentation regarding their construction is scarce.
I appreciate your insights.

[AlphaPlusTT]

That makes total sense.
Generalization remains a long-standing unsolved challenge in 3D perception. Many leading autonomous driving companies unify sensor layouts across different vehicle models at the design phase, to keep their sensor configurations highly consistent.
I fully agree with your view that data is the key to breaking through this issue. 2D perception achieves much better generalization largely due to its abundant data sources and diversified acquisition devices, which empower models to adapt to various data distributions and hardware setups. Even so, targeted fine-tuning is still a necessity for real-world engineering deployment.
For OCC ground truth generation, you can refer to the SurroundOcc project. If you plan to collect your own dataset, a high-precision inertial navigation system is essential for map construction.

[AlphaPlusTT]

btw, pure LiDAR-based solutions deliver pretty strong generalization capability.

[kortysukura]

Thank you so much for your answer; it was really helpful. I need to rethink my next steps. To be honest, given that the vehicle already has LiDAR and cameras, I feel like Occ doesn't add much value. However, BEV alone can't solve the problem of irregular obstacles. Maybe there’s a better way to handle this that I haven't thought of yet? Thanks again.