Hi!
Are there any plans to support using PyTorch models for custom object detection? Right now, PyTorch models can only be used for face detection/recognition.
It seems counterintuitive that PyTorch isn’t supported for object detection when YOLOv7 is supported. YOLOv7 is primarily trained in PyTorch, although they do provide a -Tiny Darknet implementation that’s only really suitable for inference and not for training custom models. And since PyTorch is already supported for SCRFD/MobileFaceNet, why is it not supported for object detection?
We are currently evaluating whether we can use the AMB82 for a line of products in the near future, and PyTorch support for object detection would be helpful.
Hi @at_and_red , We are currently in the process of completing this tool. Estimated in February, it should be ready for user to use.
1 Like
That’s very promising. Thank you very much to you and the team for your hard work. I’ll be on the lookout for the update in February. I’m actually going to deploy an AMB82-Mini to the field to validate the object detection next week. Looks like I’ll have to issue a patch at some point to test it with a PyTorch model.
On that note, I hope you guys make OTA updates available for the Mini (maybe in the next revision of the dev board). It’s a very nice product, and there’s a good chance we’ll move forward with implementing it into our products, so we might be looking at larger-scale orders and access to the NDA SDK soon — which I’m hoping has OTA support or at least documentation so we can design our own implementation. However, it’s such a nice product that I was thinking of using it for my personal projects. One of the reasons I use ESP32s at home is because I can upload new firmware OTA. Right now, I’m uploading new firmware to remote Minis via small Linux SBCs. Not ideal, but serviceable. 
Hi @at_and_red,
Sure, thank you for your support!
We will discuss internally to see if it is feasible for OTA features. 
Hi @at_and_red,
You can try out the conversion tool to convert yolov7 tiny model that is trained using PyTorch.
https://www.amebaiot.com/en/amebapro2-ai-convert-model/
Thank you.
1 Like
Hi, @pammyleong,
Thanks for the update. Sorry if I couldn’t try it right away. I was working on other aspects of the project that needed addressing after our field trial. I need to update our yolov7 model to include our new datasets, but I think I’ll be able to get to that later in this week or early next week. I’ll let you know how it goes when I get to it.
Thanks again for your hard work!
Oh, and I noticed the RTL8735BDM boards and modules are going out of stock with most third-party sellers, so if that means they’re getting snatched up because people like them, I guess congratulations are in order? 
Hi @at_and_red,
OTA feature for firmware is now available in the latest early release for Arduino.
GitHub - Ameba-AIoT/ameba-OTA-UI. This is the web UI to be used with the OTA firmware update. Do note that it does not support the OTA for models yet, but this will be worked towards in future.
The guide will be available soon.
Thank you.
1 Like
Awesome! I’ll test it out later today. Thanks for the update, @Kelvin_Huang!
Hi, @Kelvin_Huang!
I got busy, so I couldn’t test the OTA functionality until today.
I cloned the repository this morning and Dockerized it to use in our dev server. I just tested it out and finally got it to work after a couple of false starts (I was trying to upload flash_ntz.bin and firmware.bin before I realized the correct bin is ota.bin).
We’ll work the OTA process into our code and let you know if we run into any issues.
Thank you so much for your hard work!
Hi @at_and_red,
Great to hear that. It’s good that you are able to figure things out even though the official guide is not out yet.
Sure, please inform us whether if any parts of the instructions is unclear so we can improve on it.
Thank you.
1 Like
Yeah. It was pretty self-explanatory after looking at the related code.
The only things that, I think, need to be more well exposed are the variables that control the server, port and resource to use. Since they are implementation-specific, I think they should be exposed in the API so that an implementer can make a call to the API rather than edit an SDK source file to set them.
But so far so good. I haven’t heard any issues from anyone so far, but I also have been working on a different but related project. So when I get back to working on the firmware, I’ll let you know if someone has had problems that haven’t gotten to me yet.
Hi @at_and_red,
Thanks for your suggestion, this can be worked towards in future.