Recent content by mailseth

I’ve been doing this for many years, but still prefer print statements over breakpoints for whatever reason. I’ve been doing all of my testing using a script to run and test the tpu_runner.py code, so I’m not really even that familiar with how things interact within CPAI, and I may not be of...

As far as an IDE, I’ve used Eclipse, BBEdit, Sublime, and most recently VS Code. My Linux machine that I’ve done my Coral development on I’m using Sublime and the default Linux text editor (simple text?). And EMacs sometimes. Or vi if I have to. And sometimes I’ll work on some prototype code...

The Coral TPU code is all in python, although some of the failures may be related to the setup configuration/environment. There really isn’t any hardcore coding that you’d need to do. Just figure out how to make the existing code run more reliably via trial and error. Things like refining the...

It looks like you are attempting to use multi-TPU by default, but something is wrong so it falls back to the old method. If you’re feeling adventurous you could dig into it and figure out what’s wrong and let me know what to change. (But it may be just the installed coral library version, which...

You should be always able to use the multi-TPU implementation, even if you only have one. Basically the single TPU just refers to the old code base and multi TPU the newer code base that does better threading. That should fix the error that you were seeing.

‘Best’ practices is going to be what works best for you. People tend to be pretty happy with the custom IPcam models, but they aren’t really available right now on the TPU. YOLOv8 is the best in theory, but is going to require more compute and so may not be the best for you. Similarly, there may...

Not YOLOv8? I trust your opinion, but am curious why?

I wonder how large of a photo/label pairing dataset you could scrape off of Craigslist or Edmunds? Would probably be more complete in the past ten years.

The easiest way to ‘fix’ the problem you’re seeing would just be to be running the multi-TPU code on your single TPU. Do you see any earlier problems that would show why that’s not working?

Yeah, I wouldn't expect to see much difference between 0.03 FPS and 1.0 FPS as far as analysis load goes. It's going to really only make a difference when everything is moving because it's windy or raining.

Thanks for the report. I haven’t seen that problem before. From the stack trace, it looks like it’s using the original single-TPU code which hasn’t been changed recently (as far as I know.) I’m on my phone now, I’ll take a closer look when I get a chance.

If I'm reading that correctly, that's ~700 frames analyzed (motion triggers) over 6 hours, for around 1 frame every 30 seconds? How many frames does a motion trigger cause to be analyzed?

Good to know. What sort of video stream load are you putting on it? (Average FPS?)

Sorry to hear that. I hope it’s better in the next version.

That would be an API change between BI and CPAI, I’d guess. BI would need to send the info to CPAI in order for it to appear in anything on the CPAI side, and I don’t think it does. I’m not familiar with the details of the API, but I haven’t seen anything like that in there.