search

OctoPrint / OctoPi-UpToDate

Latest OctoPi image with OctoPrint already updated to the latest release
GNU General Public License v3.0
58 stars 7 forks source link

Feedback for the latest camera-streamer based webcam stack build (20230328122604) #3

Closed foosel closed 1 year ago

foosel commented 1 year ago

👉 Latest image & feedback ticket can be found here 👈

This is a ticket to collect feedback on the latest build of the new camera stack (some background on that here) for OctoPi-UpToDate, 20230328122604. Find the image here: https://github.com/OctoPrint/OctoPi-UpToDate/releases/tag/1.0.0-1.8.7-20230328122604

Changes compared to the previous version:

(Compare view)

Some first config docs are available here: https://faq.octoprint.org/camera-streamer-config

The source tree used for the build is here: https://github.com/OctoPrint/OctoPi-UpToDate/tree/camera-streamer

❗ Please note

This image needs to be flashed to your SD card, wiping it in the process. So if you want to keep anything on there, make a backup first! You can also create an OctoPrint backup, download that, flash, restore from backup. There's no way to update to the contents of this image without a full reflash.

Please provide feedback on your experience with this image in this ticket, whether things work for you or not. Make sure to at least include the following:

Known issues:

Common pitfalls:

b-morgan commented 1 year ago

RPi 4B with camera module V3 (no printer). Image booted without incident. OctoPrint backup said it was for a new image so I created a new backup on my RPi 3B (with OctoPi 0.18.0, OctoPrint 1.8.7, camera module V2.1, and LulzBot TAZ 6). New OctoPrint backup installed and camera is working.

Robinson91 commented 1 year ago

Everything seems to work (including the PiCam V3) except for one very important thing: OctoDash not working despite working fine before the update. Error message on screen (official 7"): "error: XDG_RUNTIME_DIR not set in the environment". Anyone know how to fix this?

RPi 4B 8gb PiCam V3 Wide

fosterthree commented 1 year ago

Everything working on my end (RPi Zero W / v3 Camera). Thank you so much for your amazing work on this and everything else, @foosel!

foosel commented 1 year ago

OctoPrint backup said it was for a new image

You were already on 1.9.0rc3 I take it? In that case, yeah, backup restoration is stopped because things might have changed between 1.8.x and 1.9.x. I think I should maybe allow a manual override here if the user thinks that's a good idea (here it would have worked). Going to add a TODO for that to OctoPrint proper ;)

foosel commented 1 year ago

Error message on screen (official 7"): "error: XDG_RUNTIME_DIR not set in the environment". Anyone know how to fix this?

Can't say that I have any idea what could be going on here. BUT, this image includes a newer kernel (latest from apt) for which I already had to fix one bug, so possibly this is related somehow?

GitIssueBot commented 1 year ago

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/setting-up-multiple-webcams-in-octopi-the-right-way/32669/172

onlywatanabe commented 1 year ago

Anyway to setup multiple cameras on this new stack? I was told the guide above wouldn't apply to this new firmware. I'm not able to access port 8081 on the new firmware using that guide.

cp2004 commented 1 year ago

The documentation for the new camera stack linked above has a section at the end for setting up multiple cameras.

onlywatanabe commented 1 year ago

Thanks so much. That was so much easier than the previous method.

Elitesoulman commented 1 year ago

I've got a Pi3+ and I'm working with the v3 camera module, everything seems to be working great. The options I've tried (resolution and framerate) seem to be working as intended. Thanks again @foosel for your hard work.

I'm chasing one issue with Octolapse (timelapse only stable with a larger delay >1000ms) but everything with the actual build is great.

emelbardis commented 1 year ago

What would be the syntax for AF off and focal point (LensPosition) at the middle range? I'm assuming lens position is from 0 to 32 so middle would be 16. AF on my machine is not really usable since it seems to try to focus constantly due to vibration.

- available option: AfMode (0000001c, type=3): [0..2]
- available option: LensPosition (00000023, type=5): [0.000000..32.000000]
cp2004 commented 1 year ago

You can definitely turn off autofocus by using

OPTIONS='--camera-options="AfMode=0"

The closest explanation I could find of the values was the Raspberry Pi documentation - which doesn't use the same values. It does list some AF modes, but with no numbers attached. Source.

I believe it is:

I then played around with LensPosition in the same way as autofocus, eg.

OPTIONS='--camera-options="AfMode=0" --camera-options="LensPosition=1"

and could set the different values between 0 and 32 and it changed the focal point a lot. Focus scales aren't really linear, so you might not need 16, so I suspect trial and error might help. Alternatively, use AFMode=1 to autofocus once.

emelbardis commented 1 year ago

Thanks. This is really helpful. AFMode=1 probably runs at boot and subsequent boots but it might be helpful to boot with an object in the center of the plate, setting ideal AF and then trying to retrieve that LensPosition value to set permanently.

edit: got it focused nicely with lensposition 6 but this thing is a jittery mess when anything is moving (like the printer). I don't think this cam will work for this application. Is there anyone who's having a good experience with these?

cp2004 commented 1 year ago

Ideally, I guess this page should be reworked to describe the debugging procedure for camera-streamer. I'll see if I can get a PR together to update the page:

image

Edit: PR #4

Ruhel786 commented 1 year ago

Everything working? This install was much more difficult to get HyperPixel 4 touchscreen and OctoDash working. No idea why. I had to comment out dtoverlay=vc4-kms-dpi-hyperpixel4sq and then the touchscreen started working. Is this anything to do with the OctoPi image? Also OctoLapse no longer takes stabilised images. Thanks to @Elitesoulman comment above I added a >1000ms delay and its working a bit better.

Pi model: Pi 4 2gb

Camera: PiCam v3

in case of issues: related logs (journalctl -u camera-streamer* | pb and share the generated paste.octoprint.org URL) https://paste.octoprint.org/9yy638kJaJ

FormerLurker commented 1 year ago

I've been running some tests today, and here are the things I have observed:

Everything working: The camera streamer is working as expected Pi model: Pi 3B Used Cameras: Logitech C920

I had a minor issue that isn't a big deal, but I figure I'd mention it: my settings backup failed to restore because it was from a 'newer version of OctoPrint'. I know it's due to the version numbering of this pre-release, and that's fine, but in case some people are surprised.

However, I did discover a change of behavior between mjpg-streamer and camera-streamer that I thought you all should be aware of: the /snapshot endpoint is delivering a frame from the past, and not the 'next' frame, like mjpg-streamer used to do. This issue seems to affect the raspicam much more than a usb camera (I need to do more testing on the raspi camera, which is why I didn't mention it in the 'used cameras' yet), but it is definitely noticeable when using my C920. Here I will only discuss the USB camera behavior I have tested enough to understand (I think). This was discovered (of course) while testing Octolapse. There is a default delay of 125MS added before requesting a snapshot from the endpoint, and this is no longer enough to get a stable timelapse. This number used to be quite conservative (I typically use delays of < 50MS for my own timelapses, and sometimes much lower).

The FPS plays a key role, apparently, in determining how much delay needs to be added. At 15FPS, you get a frame every 66.67MS approx. That means we can be only 1 frame behind for the default 125MS delay to work (66 .67 * 2 = 133.34MS = No bueno). At 30FPS (up from the default of 15), the default delay appears to be sufficient (more testing needed on my part to verify), but only just so. Increasing the default delay will increase oozing and artifacts, unfortunately, so I'd really like to keep it to a minimum.

I have added an issue to the camera-streamer repo (feature request, linked above) for an endpoint that is capable of returning the next available frame, and asked if there are any workarounds or alternatives. I took a look at the code, and it would definitely take me quite a bit of time to understand, so hopefully if this feature request is denied, I can at least get some pointers/info so that I can fork and PR. If not, setting the default FPS to 30 (no problem for my RPI 3b) would help quite a bit, though I know that would be problematic.

If you feel this comment is polluting the intent of this thread, please feel free to remove it as it isn't exactly a problem for OctoPrint. I will report my findings with the raspicam v2 ASAP.

foosel commented 1 year ago

Is this anything to do with the OctoPi image?

It could be related to this being based on OctoPi 1.0, which in turn is now based on a newer Debian version (Bullseye instead of Buster). Which raises the question, much more difficult compared to what?

If you feel this comment is polluting the intent of this thread, please feel free to remove it as it isn't exactly a problem for OctoPrint. I will report my findings with the raspicam v2 ASAP.

Absolutely not, that is valuable feedback! :) Also glad to have you back!

FormerLurker commented 1 year ago

Also glad to have you back!

Took me long enough, lol!

FYI, there has been some movement on my feature request. I'm always blown away by the open source community. This new webcam stack will be a huge upgrade!

Ruhel786 commented 1 year ago

It could be related to this being based on OctoPi 1.0, which in turn is now based on a newer Debian version (Bullseye instead of Buster). Which raises the question, much more difficult compared to what?

@foosel Sorry I didn't clarify in my original post. I have been using the 1.0.0-1.8.6-20230222114422 which seemed to be extremely stable for me. I have tested this again on a separate memory card and installing this version and getting it working with HyperPixel and OctoDash was as simple as using the one-line installers for both the screen and OctoDash.

I never updated to the stable release.

When I installed OctoPi 1.0.0 with OctoPrint 1.8.7-20230328122604 I just found that using the one line installers for both the HyperPixel screen and OctoDash would not work the first time and I had to manually install OctoDash to get it working. I also know that some of the issues could be inexperience on my part but going back to the previous pre-release image, the installation and configuring of the screen and plugin was seamless and quick. I've only installed the most recent pre-release image OctoPi 1.0.0 with OctoPrint 1.8.7-20230328122604 once, Im happy to go and try it all again as I have spare memory cards for testing images/builds.

cp2004 commented 1 year ago

I guess it could be the difference in kernel versions? If I'm remembering right this image coincided with a kernel upgrade that might have impacted it.

foosel commented 1 year ago

Could be. There seem to be some kernel shenanigans in general these days, just learned the other day that the firmware updater will now push 64bit kernels on 32bit userspace systems: raspberrypi/linux#5402 🤡

See also this discussion on the OctoDash repo: UnchartedBull/OctoDash#3559

That will need to be addressed for OctoPi-UpToDate in general, even outside of this current camera stack work. Speaking of which... I'm holding back on this currently because of the known issue/regression with vflip/hflip no longer working under current libcamera versions, see known issues above. And the discoveries by @FormerLurker regarding snapshot behaviour also gave me pause, so I'd like to see where this is going first as well.

So I guess my original goal of "get this finalized within or very much right after Q1" is out of the window now. Will still see that I get a new build posted with a pin of the 32bit kernel, next week most likely, and it would then be lovely if you could give this a test in your setup @Ruhel786

Ruhel786 commented 1 year ago

Will still see that I get a new build posted with a pin of the 32bit kernel, next week most likely, and it would then be lovely if you could give this a test in your setup @Ruhel786

Hi @foosel. I'm on my phone so the GitHub layout is a bit weird. I'm happy to try the versions on my setup. Can you just clarify which one/s you want me to try? Ill be doing the 1.9.0 RC4 this weekend and have a few memory cards so can try a few more.

foosel commented 1 year ago

@Ruhel786 Nothing to try yet. What I meant was, I'll create a new build of the OctoPi image with camera-streamer stack and current stable OctoPrint (1.8.7) some time next week, that will then make sure the kernel is pinned to 32bit, and then you can check if things are still more difficult or not with regards to OctoDash and Hyperpixel things.

Ruhel786 commented 1 year ago

Ok. I'll keep an eye out for it. I might have another go with this current version and screenshot the errors in case they are relevant to you.

FormerLurker commented 1 year ago

FYI, I'm installing development build of camera-streamer in preparation for testing. See this issue.

FormerLurker commented 1 year ago

Installed the new version and tested with a short print @30FPS with my USB camera, and it works BEAUTIFULLY! In fact, it's a huge upgrade over the old streamer, shaving off between 100-200MS (I need to re-test with the old streamer to verify the FPS setting I used, which plays a big role) for snapshot acquisition time, and another 125MS by setting the camera delay to 0MS. This should provide a substantial quality boost by eliminating at least 225MS of oozing per frame (maybe up to 325MS!). This is the single biggest per/snapshot performance boost for Octolapse ever, I believe. If not, it's pretty close. I have yet to test the pi camera.

Note: the snapshot url needs to change for this test to be valid:

http://{IP_OF_PI}:8080/snapshot?max_delay=0

Also be sure to verify the index page of the streamer (http://{IP_OF_PI}:8080/) shows the new parameter:

image

Ruhel786 commented 1 year ago

@Ruhel786 kernel is pinned to 32bit, and then you can check if things are still more difficult or not with regards to OctoDash and Hyperpixel things.

Had another go last night and after actually reading the changes that have been made it made sense about the error with OctoDash. OctoPi image above was installed perfectly and ran on Raspberry Pi 4 4GB with Rectangle HyperPixel 4 screen. HyperPixel 4 screen driver installation was simple via one line legacy installer. curl -sSL get.pimoroni.com/hyperpixel4-legacy | bash In /boot/config.txt add dtoverlay=vc4-kms-dpi-hyperpixel4 dtparam=touchscreen-inverted-x display_lcd_rotate=3 The screen and touchscreen work perfectly. I missed the part about the 32bit kernel which explains why the OctoDash online installer fails. It always seems to try to install the 64bit version of the deb file. Manually installing the 32bit deb allows for a straightforward installation. Below is the error if you try to run the OctoDash one line installer and run the program. PXL_20230413_204132156 OctoPrint working fine with OctoDash after manual install of 32bit deb. PXL_20230413_204525031

Elitesoulman commented 1 year ago

@Ruhel786 the issue with >1000ms delay for Pi Cam v3 is fixed in the current develop branch of camera streamer. I've had great results so far.

Ruhel786 commented 1 year ago

@Ruhel786 the issue with >1000ms delay for Pi Cam v3 is fixed in the current develop branch of camera streamer. I've had great results so far.

Did you do a full OctoPi install? Thank you

Elitesoulman commented 1 year ago

Using this RC, yes. OctoPi-UpToDate, 20230328122604. The other changes are documented on the camera-streamer discussion ayufan/camera-streamer/issues/53. I've also added an issue in Octolapse to document logs and other testing Formerlurker/Octolapse/issues/895.

banthungprong commented 1 year ago

Using the HQ Cam (IMX477R) on a Pi3 B+ (didn't work with the old mjpeg and high resolutions). Streaming with 1920x1080 and 30fps without any problems while printing. Very nice: with the option to activate the RTSP server I can integrate the cam in my frigate NVR.

GitIssueBot commented 1 year ago

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/webcam-repeatedly-fails-every-3-minutes/51415/3

GitIssueBot commented 1 year ago

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/add-support-for-raspberry-pi-camera-v3/49052/9

GitIssueBot commented 1 year ago

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/new-pi-v2-camera-on-pi-4b-not-working/51456/3

matthewfischer commented 1 year ago

After struggling with the official build - this one finally solved the camera issues. Worked great out of the box.

Raspberry Pi 4B Pi Cam 3 Prusa Mk3s+

When will this get into the mainline?

Ruhel786 commented 1 year ago

@matthewfischer

After struggling with the official build - this one finally solved the camera issues. Worked great out of the box.

Raspberry Pi 4B Pi Cam 3 Prusa Mk3s+

When will this get into the mainline?

Did you only install this image and nothing else? I have the same setup as you and cant get the camera to work on this image. Had to go back to a previous build.

matthewfischer commented 1 year ago

All we did was a flash of this image and it just worked. We didn't restore from backup because we never finished the old install - so maybe that's difference.

GitIssueBot commented 1 year ago

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/raspberry-pi-camera-3-problem/51570/2

BigBlock65 commented 1 year ago

RPi Zero 2 W with Raspberry Pi Camera Module 3 (Prusa MK3S Printer). Image booted and ran initial setup script as expected.. Camera came online without any additional configuration. I also have a Logitech C270 connected to the USB port which was working on the current release build. I will be attempting to set that up as a second camera next.

BigBlock65 commented 1 year ago

RPi Zero 2 W with Raspberry Pi Camera Module 3 (Prusa MK3S Printer). Image booted and ran initial setup script as expected.. Camera came online without any additional configuration. I also have a Logitech C270 connected to the USB port which was working on the current release build. I will be attempting to set that up as a second camera next.

I successfully added the USB camera following these steps: https://community.octoprint.org/t/camera-streamer-configuration-on-octopi-1-0-0/49950

I will be checking timelaps configurations tomorrow. Thanks to everyone who contributed and made this all work so nicely!

foosel commented 1 year ago

After some upstream bug fixing on the part of @ayufan (THANKS!) I've prepared an updated test image. It includes a new build of camera-streamer which fixes the flipping options no longer working, and also pins the kernel to 32bit (so that latest RPi shenanigans don't move it to 64bit while keeping a 32bit user space, which causes issues with things like OctoDash). New image here: https://github.com/OctoPrint/OctoPi-UpToDate/issues/5

Teslafly commented 1 year ago

I tried setting up octodash with the "new camera stack 1.9.0" raspberry sd image on a pi 3B+ I used raspberry pi flasher to configure wifi and ssh at card flashing.

I have the official 7" display connected with just the ribbon cable and power.

octodash installed fine, but when it booted, the touch screen didn't work. as far as I could tell the touch controller was not being detected. However It did work with an off the shelf desktop rasbian image with the same hardware setup.

I looked in the config.txt on the boot partition, and uncommented the 2x i2c config lines to enable those ports since I think the touchscreen is attached there?

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
dtparam=i2s=on
# dtparam=spi=on

with that change the touchscreen started working.

So possibly octodash setup script needs to enable the i2c port for the touchscreen controller, or the setup should include a note about doing it manually.