Very similar to a couple of other recent posts I’ve noted, I’m getting the subject error message when I try to run a recent model on an Oak-D. Not exactly sure why this is as I’m only trying to run inference on a single Oak device.
Would appreciate any guidance. Thanks in advance.
- Project type (Object detection)
- The operating system & browser - OSX, Chrome
Sorry to hear you’re having issues. I have reset your device limit. Please let me know if you continue experiencing issues.
Hope this helps
Hi Leo -
Thanks for getting back with me on this, and for resetting the device limit. I’ve had to set the project aside for a few days, but will try it out again soon and let you know (either way).
Hi Leo -
Just following up and getting back to reporting on this issue I initially raised last week …
The good news - It looks like the device limit reset you did helped … thanks much. The short story is that I switched over from my Mac to a Raspberry Pi 4, and after a bit of work I’ve now got the Pi and Oak-D playing nice together … seeing the frame and depth map, as well as the predictions/FPS scrolling by on the terminal … all looks as I would expect.
The less good news - there are however NO predictions when I present images of my different classes to the Oak … no indication of any detection at all. (The same images have high confidence when tried with the web API). I’ve checked the model name, api_key, and version very carefully, and that all looks good, so I’m not quite sure why the inferencing on the Oak isn’t working. (The Oak I’m using inferences fine when I try it with the Luxonis depthai setup and models)
I’ll keep working on it to see if I’m missing anything, but would appreciate any suggestions or guidance you might be able to provide. (I’ve also attached my code if you’re interested in taking a quick look at that). I also do understand this could possibly be a Luxonis vs. Roboflow issue, so just let me know.
Hi @Larry I’m reading over your post, but in the meantime, please reset your private API key as soon as possible by going into your Settings > Your Workspace > Roboflow API > Revoke API Key.
Glad to hear your device limits issue got resolved.
Have you attempted to infer with a known image? (something from your training dataset) It should detect that image and it can help rule out issues with your model.
Hi Leo -
Thanks for the quick response and for looking into it. (I did reset the API key … shouldn’t have put that out there … thanks for the catch). I haven’t tried an image from the training set, but will give that a go shortly and let you know. (I’d be a bit surprised if that would work as the model, when run with the web API, infers these new images with high confidence - they’re quite similar to the training set - but we’ll see).
Also, I just came across what appears to perhaps be an alternate/newer deployment method (?), so will look into that a bit further too.
Thank you again,
It seems I am running into the same issue as Larry… Using the roboflowoak API I am getting 0 inferences and after thinking it was a model issue, I retrained a new model and upon deployment I am getting the 5 device limit error for my “UCSD Object Detection” workspace.
I also wanted to ask if you can point me towards any information regarding the device limit and what exactly it means. I have 3 oak-ds on my robot and I have multiple models I would like to use / switch between. Will I exceed my limit?
The OAK-D deployment limit is for five devices per workspace. Switching models should not cause you to hit your limit, but one issue we are aware of is that switching IP addresses or Wi-Fi networks can often cause our system to believe a new device is being used. We are working on a solution, but in the meantime, I’ve reset your device limit as well.
Also, if you are doing a project for university research, consider applying for research credits.
Thanks for the quick reply, I no longer have the device limit issue but I am still getting the problem with no inferences. To ensure it wasn’t a model issue, I ran the roboflowoak script and recorded the raw frames simultaneously. Although I wasn’t getting predictions on the camera, when I uploaded the video to Roboflow in the deployment tab in my project, the model worked perfectly…
Not entirely sure what’s happening, here is my setup:
(the device parameter I altered in the library so I can easily select the oak-d I want by keyword)
Thanks - Eesh
(Also I’ll look into the research credits thanks for that)
Hi @stellasphere -
So, I did follow up on your suggestion and present a couple images from the training set to the Oak … as I anticipated though, there is still no indication of any inferencing, only null predictions.
One thing is curious to me however - I assume how this works is that the script, when the RoboflowOak rf object is instantiated, first phones home to the Roboflow mothership to download the model to the Oak device based on the specified model/api/version information. The interesting thing though is that even if I change the api_key to some bogus string, the script starts normally, displaying null predictions. There is no indication or warning that I have attempted access with a bad api_key. (The program will however balk at a bad model name or version).
I’m not sure if this might be related somehow to the non-inferencing issue with the camera, but it did seem unusual to me that my script would run, irrespective of the api_key information. But perhaps I’m just misunderstanding the function or role of the api_key is accessing/downloading the model.
Again, any suggestions or guidance is much appreciated.
Brief update - after reading and looking into things a bit further, I think I’ve resolved my misconceptions about the API, and also made some progress on inferencing with the Oak.
I realize now that the API key is associated with my account/workspace, not with a particular model as I had initially thought. So, I think my understanding of that is cleared up now.
Re: Oak/inferencing - I moved on to ‘plan B’, trying out inferencing using the depthai_sdk based approach as mentioned in my earlier comments referencing this blog post/tutorial. I’ve got that running fine now on my Raspberry Pi / Oak-D setup … inferencing looks as expected using the pre-trained model referenced in the blog post as well as a few others from Roboflow Universe.
That said, I am still unable to get my particular model running using this alternate approach. Though I believe I am trying to run a model I have previously trained, an error message - ‘no trained model was found … you must train a model on this version of Roboflow Train …’ - is returned. (Attached are screen captures of both the error message and model … I’ve been unsuccessful trying both versions v4 and v5).
So, this error message would seem to suggest that there is some problem with my model preventing it from being deployed properly on the Oak with both methods I have tried. I’m thinking perhaps of just starting over from scratch and trying to retrain a new model, but would appreciate any comments you might have.
Hi @Larry and @Eesh_Vij
I’ve added additional training credits. Do you mind re-training your model to see if that issue resolves?
Great … thanks @stellasphere. It might take a few days as I do think I’ll take a step back, review and update the dataset a little, then retrain. But I will definitely get back with you to let you know how things go … hopefully smoothly.
Thank you again,
Hi @stellasphere, I will give it a shot a bit later, but in the meantime, I found a workaround for my needs and potentially for @Larry.
After annotating and augmenting from Roboflow, I exported the model as a yoloV5 PyTorch dataset in a zip format and imported it into Ultralytics hub on their free plan. Then I selected to train the model as a YoloV5nu (~10-13 fps on the Oak-D with my model) and if you export as YoloV8 from Roboflow you can pick any of the V8 options given its ideally an “s” or “n” model since Oak-D struggle to process larger models. From there, just follow the directions to train and once done, hit export and you will get a .pt file. I would rename this file to something simple like “model.pt” since the next step is picky with the file name.
This file can then be put into https://tools.luxonis.com/ to convert into a blob file. For the size, just put the dimensions of your images from the dataset you trained (width and height separated by a space and make sure they are divisible by 32). Under the advanced options you can pick the amount of shaves you want to use (6 shaves gave me the best results). Soon you will get a zip file called results.zip.
Within this file, you will find a blob file that can be put on the camera. From there you can look inside the roboflowoak package to see how to load it onto the camera or the API docs for depthai. If you like I can also post a code snippet for how I ran the models.
Hopefully, this helps…
Thanks - Eesh
Thank you for elaborating an alternate training/deployment approach @Eesh . You are definitely well ahead of me in your understanding of various workflow options, but I may dig into your suggestions deeper if the Roboflow based Oak inference isn’t planning out.
(I noted a possible UCSD affiliation from your earlier post? Long time SD local here also … have visited campus many times. Good luck with your project).
Hi @stellasphere -
I did follow up and retrain a model after updating the dataset a bit, but no change in the outcome using the depthai_sdk based approach … same ‘no model found’ error message.
(I also went back and tried the earlier roboflowoak based approach I had initially started with, but am now running into some ‘X_LINK_ERROR’ drama I’m trying to work through).
So, if you have any ideas as to why this newly trained model is still unable to be located/deployed I would appreciate that.
Lake from our team noticed that your error message looked like you might be pulling version 1. Can you double-check and confirm that’s correct?
Hi @stellasphere -
Yes, I only created/trained version 1 … here’s the depthai_sdk related script I’m trying to run. Let me know if I’ve overlooked or am doing something incorrectly.