Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am bringing you another fragment on my journey to get my PiCamera working in a video call. Let’s get Started.
This week had a lot of progress, but no workable results. I did a lot of research on the problem, refining my understanding of the situation, but the solution always feels an hour or two away.
To recap, work last week finished with the Discord webapp playing nicely with my Blue Yeti microphone, but it wouldn’t even acknowledge my PiCamera, even when getting into the sound and video test page.
This week, one of my early findings was a driver, Video 4 Linux 2 (v4l2). I spent half a day believing something wrong with it, because v4l2 looked a lot like v412 because of the numbers before and after a lower case L. Long story short, after running a command:
sudo modprobe bcm2835-v4l2
The camera still didn’t work, but at least Discord tried to load an image from “Default” instead of insisting there wasn’t anything resembling a camera it could use
Fortunately, while researching why the camera still isn’t working, I noticed a forum where someone pointed out the command needed to be run after each reboot for the V4l2 driver to work. Other background information I picked up was that the problem might be something requesting a 0x0 feed to display.
I also noticed for the first time that the “raspistill” program’s output covered parts of the black boarder Raspbian leaves. It’s as if it’s on a separate layer in front of the OS’s video output. One of the options included making the camera output transparent, so I used that freedom of vision to try and share screens, but any screen sharing was from the desktop layer only.
I had a bunch of redundant/unfruitful research for a couple days, and I eventually ended up in the workshop again. I want to say I had about half my progress this week right there. It took a little while to review my progress so far, but after everyone understood things, we started playing around with narrowing the source of the problem farther. Many of my hunches about where the problem wasn’t were confirmed, though I did learn a bit about the Chromium hardware permission system and how some software repositories are left in a power saving state while not actively being used.
We managed to confirm the driver was working after arguing with a python prompt. It still requires adjustment, as in it threw up what looked like a blotchy, pixel for pixel view of the camera, and it was zoomed in. It covered up the black boarder entirely, so I’m hoping this isn’t just an educational dead end.
Final Question: most of my unfruitful research is quite unmemorable. This was just one of those weeks where my early work was mentally lumped in with last week’s work until I reviewed the actual blog post I made not covering it. When was the last time you forgot how recent your recent progress was?