-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coral USB is not working #13
Comments
Thank you for reporting this bug! What version of TensorFlow are you using?
|
Leigh, You are very welcome & thank you very much for responding! It's with It was clean install over buster (only rpi-deep-pantilt + update) |
Leigh, Please see following link referencing that same issue & Namburger and Feranick stated problem solved & case closed, but obviously it doesn't appear that way in case of Pi4. I left a comment referring to this issue at the site. |
Thank you for the additional info! Could you try the following?
I'm pretty sure this is a standalone TensorFlow lite runtime, which we don't need here. We're installing the full TensorFlow wheel, and then initializing a TF lite interpreter (ref: https://github.com/leigh-johnson/rpi-deep-pantilt/blob/master/rpi_deep_pantilt/detect/ssd_mobilenet_v3_coco.py#L49) I'll add better docs around getting the Coral setup!
My reference implementation might be using a different version of this library, which might be the culprit.
|
You work long hours too! I appreciate your attention & certainly will. I'm in the middle of testing your rpi-deep-pantilt detect on my direct driven brushless motor Pan & Tilt control HW-device that I firmly believe that it will provide minimal latency unlike any other conventional mechanical gear driven reduction type, similar to that of standard servo motors or super expensive Flir's and also direct driven stepper motor type's that relate to annoying constant noise plus awkward positional step motions, thus provide promissing real time object or face tracking that matches speed of CPU processing in real time & minimize PID processing resource . So far, it's been working great & I'm getting fluid like positional movement (rather slow but you deserve all the credit--(I didn't think Pi's GPIO can provide such smooth PWM output unless I'm using Arduino via Serial output of Pi attached & use of VAR servo) but I'm having to adjust inner PID within the software side & PID at HW side together. (driving me crazy because of slow SW input speed). I would like to prepare back up of what I have so far tonight or tomorrow morning --(I'm exhausted tonight) & follow your response tomorrow and I'll report back to you tomorrow. (I'm in Virginia USA & it is 1:04 AM now) I'll also appreciate if you can also look into issue of person's face to being in centroid of frame when you have chance please. (My first priority) I'll be happy to share my HW brushless Pan & Tilt device implementation with you in private conversation & providing you with video or perhaps even with actual prototype. I'm newbie in Software, but I'm a professional carpenter worked on Washington DC Kennedy Performing Art Center Remodeling project & Martin Luther King Library specialized flooring project including Gym, Dance Studio, Sports Flooring, audotorium construction and ongoing. |
I'm getting this output (.venv) pi@raspberrypi:~/rpi-deep-pantilt $ sudo apt-get install libedgetpu1-std=12-1 |
Run following; same error output; "RuntimeError: Internal: Unsupported data type in custom op handler: 0Node number 2 (EdgeTpuDelegateForCustomOp) failed to prepare." It still run without --edge-tpu I also tried new install of Buster & only rpi-deep-pantilt related install package and I2c & picam enabled only, same error. |
Hey @Martin2kid! Sorry about the dead air on this issue. I am going to release Docker images in v1.2.0 and script the platform-level installation with pinned versions of system-level dependencies. Right now, the manual installation instructions feel like they're already out of date. I haven't upgraded to libedgetpu1-std@13.0 to try and reproduce this issue yet, will let you know if that ends up being the cause. |
I am extremely interested in your brushless motor setup, by the way. Is this the module you're working with? https://www.flir.com/oem/pan-tilt-systems/ My email is hi@leighjohnson.me if you'd like to share more about your prototype and use case.
|
Leigh, Thank you very much following up & updating me. I saw couple of Pi4 & TensorFlow 2.1 related issue here too & may have something to do with this issue for your reference; https://www.raspberrypi.org/forums/viewtopic.php?t=262595 It's not a Flir or Raytheon's (same product, they used precisely machiened worm-geared mechanism with stepper setup) which still produce mechanical latency) of I'll send you info to your email |
@Martin2kid The problem here is that this repo is using I suggest using the |
Nam Vu, |
Thank you @Namburger! 🙏 Appreciate the example code. I'll fix this in my next release. |
for anyone that needs a temporary fix, you can do the following:
|
Complementing to IanShow15's contribution, the following worked for my RPI4:
|
Hi Yuji09, Like you, I am running a Rpi 4B+ also and I experienced the same problem described in this issue when I tried to run detect with the Coral TPU. Modifying the Python code per your instructions did the trick as I am now detecting objects at 27-28 frames/second without any errors at startup. Nice work, much appreciated. |
Hey y'all, this should be fixed in versions >= 1.2.0 - let me know experience any issues! I'm also looking into why My understanding is that these interfaces are provided by TensorFlow's The |
This is indeed non standard and we apologize. The issue is that libedgetpu started depending on tensorflow as a dependency, so you'd need the exact tensorflow commit that we used to build libedgetpu in order to be compatible. That's why we packaged |
No worries / no apology necessary! Thank you for jumping in and helping everyone in this issue. ❤️ Let me know if there's anything I can do to assist you in the meantime! The Google GDE program operates behind Google NDAs (we don't work for or otherwise represent Google though). GDEs often organize/participate in early access programs if you're looking for extra feedback, testing, support before open sourcing. I have a couple USB accelerators, the Dev Board, and I'm more than happy to do bonkers things like try the SOM on an RPI running an aarch64 distribution like Mendel, Fedora, Arch, etc. Shoot me an email hi@leighjohnson.me if you want to connect and chat more about working with the GDE program. |
@leigh-johnson I mentioned you to our FAE team and our Developer Advocates, they'll contact you if we need your helps! |
Description
Ran "rpi-deep-pantilt detect --edge-tpu --loglevel=INFO" after installing Coral USB per instruction & Googl's (Note it is now 2.1 version Runtime)"
Error: "RuntimeError: Internal: Unsupported data type in custom op handler: 0Node number 2 (EdgeTpuDelegateForCustomOp) failed to prepare."
It works without "--edge-tpu"
What I Did: multiple re-install & reboot & same result
The text was updated successfully, but these errors were encountered: