I have been going through the project for the picar-x on the website and everything works well until #7. Computer Vision. When I run it, it captures 1 frame and then the camera automatically closes. The program doesn’t end there, so I have to Ctrl-C to exit if that gives any clues. I can look at the Flask app on the url provided to see the picture it takes. Also when I run ‘rpi-hello’ it takes video fine so I’m confident that the camera and connections are good. I think it could be related to the flask app but i’m not sure. I will show what the terminal prints out when I force exit the program but I can’t make sense of it.
There may be a conflict between the system desktop and the video source. When you run the example code, the video display shows for a moment before automatically closing, and then the screen freezes when you access the video source through the browser.
Please modify the code in the 7.display.py file and then re-run the 7.display.py example to check the working status.
Change Vilib.display(local=True, web=True) to:
Vilib.display(local=False, web=True)
Save the changes, exit the code file, and then run it again.
1 Like
Awesome, that worked! Thank you for the help. I figured it was something simple since I could take videos using the rpicam command.
I have been experiencing the same problem with the camera opening for a single shot and then stopping. I followed the advice above setting the local=False attribute, and this works fine for the camera streaming to a web browser (I have been running the 7.computer_vision.py script in ~picar/example folder). BUT… the “take photo” function is not working.
When I don’t set the local=False attribute and leave it as the default local=True, an error appears in the terminal stating:
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
I notice that the /tmp/runtime-root folder is owned by the root user rather than me and wonder if the local=True attribute is making the script try to use that folder for storing temp images/data but is being refused because of the permissions. (I should add, I am not at all an expert in how Raspbian / linux works).
Can you advise how I can overcome this problem, as I want to be able to “Take photo”?
When both local=True (local display) and web=True (web stream) are enabled simultaneously, resource conflicts may occur. It is recommended to choose one based on your needs (prioritizing web=True mode for better compatibility).
After setting Vilib.display(local=False, web=True), please rerun the 7.computer_vision.py script. Then, access the camera stream via the web page and take a photo.
The photo file will be saved to the /home/{username}/Pictures directory. Please open the Pictures directory to check if the captured photo is there.
The camera was working for me until the SD gets busted. When replacing it with a new one for Raspberry Pi 5 and using the updated Trixi OS, I got the same issue above, such that the camera captures one frame, and then it freezes. I tried disabling either the local or the web by turning the status of one of them into False, but the same issue persists. What may resolve this conflict issue?
This issue seems more likely to be a compatibility problem between the new libcamera environment in Raspberry Pi OS Trixie and the current Vilib, rather than a hardware failure of the camera module itself.
You mentioned that:
The camera worked normally in your previous system.
The issue only appeared after you flashed a new SD card with Trixie.
This suggests the problem is more related to changes in the system environment.
Please first run the following command to test whether the camera module itself is functioning properly:
rpicam-hello
If this command also shows only one frame and then freezes, the issue is likely related to the camera stack / libcamera in Trixie, not the PiCar‑X camera hardware itself.
Yes, I searched the problem in more depth. The rpicam-hello command showed that the camera hardware and the associated OS drivers are in a healthy condition: The camera operates clear and live for about 5 seconds and closes normally. So the issue is not in the hardware, but in the conflict between the vilib and the OS desktop of Trixie. In fact what worked is to enable the web streaming mode and disable the local streaming mode:
Vilib.display(local=False,web=True)
and then watching the video on a webpage:
http://ip-address:port-number/mjpg
like: http://192.168.2.191:9000/mjpg
woking smooth, which is good. However, this requires the PiCar-X to be connected in a local netwok with Internet access, so it can be connected headless to the controlling host computer which run the Python code that controls the operation of the robot. This method works well when the robot is tested at home utilizing a home configured network. However, due to legitimate reasons in situations when a network is not available or in a high security netwok, like one used in a school, the direct network reach between the host computer and the robot may not be facilitated. A simple solution for the headless operation in this case is to configure the Raspberry Pi of the PiCar-X as a hotspot and then reach it directly from the host computer using RealVNC Viewer in an example, but in this case the robot is not connected to the net and the web streaming is not possible. In this case the local video streaming is the only option available, but currently it has an issue due to the conflict with the Trixie OS desktop. I think SunFounder should find a solution for the vilib library to retain the local video streaming option. The PiCar-X may be a good tool for learning but it needs this issue to be fixed so utilizing its AI machine learning features become easily possible for testing in a public place.
Thank you …
Thank you for your careful observation and valuable suggestion. We truly value every piece of feedback from our users.
Your input has been submitted to our product team and will be included in our future optimization roadmap to be gradually implemented.
Thank you again for helping us improve.