-
Notifications
You must be signed in to change notification settings - Fork 4
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 TPU Dev board #8
Comments
I've been running my system on the Coral TPU Dev board for almost a year now, it makes a nice stand-alone system, but it wasn't reliable until I put it on a UPS, as it seemed more sensitive to "power glitches" that my other systems. I recommend the Raspberry Pi4 power supply for it The problem is that Google put a layer of "security" on it that makes a more difficult to set up. I had to start with a serial terminal and manually enter the ssh key. The basic instructions to set it up are here: https://coral.ai/docs/dev-board/get-started/ Once you are logging in via ssh further installation is pretty much like any other command line Debian system, although the "Mendel" Linux they use has some quirks and is not well documented as far as I can tell. Not a good choice for Linux beginners. One quirk is that the Mosquitto broker doesn't start automatically after rebooting so I had to start it with a root cron job: @reboot /usr/sbin/mosquitto >/dev/null 2>&1 & A larger issue is the current Mendel system probably uses Google's "new" Python API which breaks the original. Since the two are apparently incompatible at the lowest level hardware library that uses the same name, so I couldn't get the two versions to co-exist. Modifying my code for the new API is on the ToDo list, but since they can't co-exist I haven't yet set up a system so I can do so. But my code runs if you apt-get install the "legacy version": The above is the installation sequence that worked for me, even though it installs and then uninstalls some things on a new Ubuntu 20.04 system. Hope this helps. Here are some of my Coral Dev board results: I may have had to compile OpenCV for the TPU Dev board, as I said, its not a good board for Linux beginners. I'll see if I can find my notes about how I did it. |
Thank you, very much! This gives me hope! |
Do you think this is a good guide on how to install OpenCV 4.0 on the Google Coral Dev board? Or this is too old?https://medium.com/@balaji_85683/installing-opencv-4-0-on-google-coral-dev-board-5c3a69d7f52f |
No they should already be in the Mendel system that you install to setup/update the Dev board. As I said initially, you will probably have the new "python3-pycoral" which is in compatible with the python3-edgetpu package. Assuming Google has the libedgetpu1-legacy-std packags in the Mendel repo, you should be able to remove the new libedgetpu1 and install the legacy version my code requiers with: Modifying my code to use the new pycoral API is on the ToDo list but has no timetable, as I see only pain and no gain for doing so at the moment. If they'd made it so the two versions could co-exist, I think I'd have done it by now, it doesn't look to be too difficult, but breaking one of my existing systems to work on it is a hindrence. |
Yes I believe that these are the same instructions that I followed, needing the SD card, activating swap, and compiling open-cv 4.0.0 I think I tried what was then the "newest" opencv version, 4.1.? initially, but the build failed, so I repeated it with 4.0.0 as used in these instructions and it has worked very well. If the build can read h.264/h.265 rtsp streams correctly, my TPU code doesn't need anything that is not in opencv-3.3.0. Some of the opencv-openvino versions have had issues decoding h.265 rtsp streams as noted in my instructions. My current TPU code has been running since 24SEP2020 on my Coral Dev Board, the cameras have dropped out a few times (power glitches?) during the interval (according to the log file) but the code has recovered each time and sent me an alert this morning when the mail arrived. I haven't touched the system since last restarted, I had to replace my router when it died suddenly and everything quit working back then. |
Thank you for your quick response. |
It should work with node-red and and MQTT broker on a different hosts, although its not been exhaustively tested. The --mqttBroker command line option should let you specify the name or IP of your MQTT broker host. The node-red uses messages from the mqttBroker so you'll have to reconfigure the MQTT nodes if not using node-red on the local host. The real issue will be the start, restart (watchdog), and stop scripts, you'll have to re-write them to launch the commands using remote ssh commands. There are potential advantages to having the node red store the detections on a different machine, but I've not pursued it since Node-red iand MQTT are so good with resources. HTH. |
specify MQTT broker
This line ( 246 AI_dev.py) for MQTT Broker? |
Correct. My system is designed to run on a private network where lack of physical access is the security. I push notification out via Email to MMS gateway of my phone provider. There is no access to my IOT devices unless you can physically plug a cable into the LAN side of its router/firewall. You'll have to consult the Mosquitto and paho-mqtt python docs for adding password protection. |
Thank you!
|
You may need to make it script as I did to set the environment and paths etc. |
Thank you for your response. I modified NodeRed code and I can see all my cameras in the NodeRed GUI also I can start-stop code from NodeRed. But I detting error like this: (Cam0:4775): Gdk-CRITICAL **: 18:47:50.873: gdk_monitor_get_scale_factor: assertion 'GDK_IS_MONITOR (monitor)' failed. I feel like I need to do more modifications to TPU.py file? I just added my local unsecured MQTT server. Also, the code is not saving any screenshots. Do I need to create a special folder for screenshots? Do I need the AI_OVmt.py file? It is part of PiTPU_startAI.sh sample script. One more error: |
Nevermind, found out how to fix all of these issues. Thanks. |
Streaming 6 RTSP streams from DAHUA cameras H264 704x480 5 FPS. And code is not reliably recognizing cars or persons so far... |
A lot of dropped frames on exit, is this normal? RTSP stream sampling thread2 is exiting, dropped frames 35407 times. |
It would be nice if you could followup with what fixed your issues. You do not need the AI_OVmt.py file as it is basically TPU.py but for using the NCS/NSC2. The sample node-red code tries to support both options. The setupvars.sh line is needed for the NCS/NCS2 OpenVINO support. It should have been commented out in the sample TPU startup script. I started with the RaspberryPi and the original NCS stick, but the TPU is much better, especially when used with something stronger than the RaspberryPi4. I think you will be happy with the reliability. I can unplug a camera and and nothing bad happens to any of the other cameras. When I plug the camera back it, it simply starts working again (unless your router changes its IP address). I specifically ignore everything but detecting people. You need to modify the TPU thread in the I modified a version to use for license plate detection. I'm biased strongly against false alarms, you can lower the --confidence from the default 0.60 and the --verifyConfidence from the default of 0.70 on the command line. Somewhat paradoxically I seem to get better detection with higher camera resolutions. Try changing a camera to 720p or 1080p. Camera resolution is handled automatically I've mixed 4K, 1080p and 720p, although a single 4K camera is about all the Pi4 can handle, I've gotten ~9 fps from three 4K (8 Mpixel) cameras with my Coral Dev Board. The testDetection.jpg shows it is picking up people walking on the other side of the street with a 1080p camera, which I have to ignore as they are not on my property and thus not worthy of a notification. I have noticed that very high camera angles (close to looking straight down) reduces detection sensitivity -- my speculation is that its the perspective distortion from the "wide angle" lenses generally used in security cameras. As to dropped frames, depending on your camera rtsp stream frame rate, lots of dropped frames are normal in the camera threads. Since you are getting ~30 fps processed by the TPU, I'd change the frame rate on each camera to 5 or 6 fps, saves network bandwidth if nothing else. Although seeing some cameras dropping 40K frames while others drop only 30 seems strange. Do some of your cameras have a really slow rtsp stream startup? Camera threads that are running will accumulate dropped frames while other camera threads are starting. |
I've changed the start script as: #!/bin/bash export DISPLAY=:0 #should be clean shutdown #but, make sure it goes away before retrying #export PYTHONUNBUFFERED=1 #./TPU.py -cam snapshots.txt -d 1 |
I'm not at all familiar With that particular camera. Grafana means nothing to me Here is a sample from my Coral Dev Board. Clearly it works very well. Maybe post a sample image with a person you though it should have detected but didn't. For me detecting and alerting on anything that is not a person is a failure, YMMV. |
Any guide on how to use the Coral TPU Dev board (not the Coral USB Accelerator)?
Thanks.
The text was updated successfully, but these errors were encountered: