Timelapse pictures & videos with Duet and webcam on layer change
-
If there is enough interest, I can make it a pip package, so it is easier to install and update. For now it still requires some manual setup and configuration.
-
@danal said in Timelapse pictures & videos with Duet and webcam on layer change:
Fantastic.
Now, we need to integrate this with the other "Proxy/Camera" Pi work that is going on, and produce a pre-built image.
My thoughts exactly.
-
What is a good way to set up a USB webcam to return snapshot pictures (still image) via an URL? I tried this link and it seemed to install fine. But I'm not getting an image with http://127.0.0.1:8080/?action=snapshot in the raspberry browser.
-
I'm also using
mjpg-streamer- there should be a bunch of different guides and how-tos out there, even specific ones for Raspberry Pi or other Linux devices.@Railgunner13f the link you posted does not configure it as HTTP webcam, but uses port 9000 for streaming with a different protocol. Try this instead: https://github.com/cncjs/cncjs/wiki/Setup-Guide:-Raspberry-Pi-|-MJPEG-Streamer-Install-&-Setup-&-FFMpeg-Recording (only the top part).
-
Bingo!
I am finally capturing the stills!
Where do I send the beer! -
Would you be able to post an example timelapse?
-
-
That's great. Exactly what I was hoping for. Hopefully I can find some time to get it setup soon.
-
@Phaedrux let me know how the mjpg-streamer stuff works for you. I'm thinking about removing this dependency and implementing a simple frame-grabber with OpenCV in Python directly... This means the webcam can't be used for Octoprint or other tools easily, but if people only want timelapses, thats fine.
-
@resam Will do. I'm thinking I will pick up another RPi3 to run this on. Or do you think a RPiZeroW with camera module would be good enough? I currently use MotionOS on the zero to act as an IP cam.
-
I'm running this on a RPiZeroW - good enough for 15fps streaming of 1280x720p and the snapshots with my script.
-
@resam said in Timelapse pictures & videos with Duet and webcam on layer change:
I'm thinking about removing this dependency and implementing a simple frame-grabber with OpenCV in Python directly... This means the webcam can't be used for Octoprint or other tools easily, but if people only want timelapses, thats fine.
Would this affect the ability to have the camera visible and updating in Duet Web Control?
-
@Danal yes - in that case the "access to the webcam" is exclusive. Either timelapse snapshots or DWC/Octoprint/some other streaming.
There might be a way around it, but it involves a more complex Linux setup - which I want to avoid. I can make it optional: "quickstart = exclusive timelapse snapshot" and as second option, the existing mjpg-streamer integration via a URL.
Let me know how many of you want to keep DWC/Octoprint webcam access, and how many ONLY want to use timelapse snapshots.
-
@resam would it be possible to serve those timelapse shots (or rather the latest one) to DWC? For remote monitoring it gives a once per layer update.
-
@T3P3Tony probably - but the idea behind using OpenCV and ditching mjpg-streamer was to REDUCE complexity
For people who want to keep their DWC webcam, you should probably still use mjpg-streamer (unless somebody knows of a similar / better tool?)
-
Having a camera visible in DWC allows a human to periodically check from their mobile and abort prints that go wrong. And/or have the confidence at hour X that a long print is going right!! They may be checking from the next room, or across town. Timelapse is nifty to document, share, show to non-3D print people, etc. It is most desirable to capture these on the same long prints where remote monitoring is most desirable.
Longwinded way of saying: If we are building an Rpi setup (or image) to provide a camera for Duet/RepRap based printers, it really should do both camera functions, seamlessly.
Blending that with the desirability of a proxy function, the DWC camera view should work on "local network" or "via proxy" equally seamlessly.
-
@resam yeah I get that. I think the big opportunity is to add that complexity back in to compare commanded movement with what happens and what the model should look like so a failed print can be detected.
-
This thread can't be allowed to die... This tool is incredible, @resam
I didn't bother with the "M400" or "G4 P500", and it's still perfect. If the snapshot isn't exactly on the layer change, it's okay. As long as I get a snapshot each layer, it's all good.
It would be nice of the script had an option to automagically run ffmpeg and then (on success) remove the jpg directory. Perhaps if I ever get any free time, I'll add that functionality (and adjust the focus on my pi camera.)
thank you!
Edit: first time lapse using this code (camera is mounted in a temporary location, so haven't bothered with focus yet.) https://youtu.be/inLM1-AvhUo
Gary
-
Can you make a small guide, how to set this up on an sbc?
After cloning from github i don't know what to do...
I'm using another SBC with octoprint, webcam and octolapse. But the connection to the duet ethernet is not fast enough sometimes.
I would love to make timelapses with my deltaprinter.
Thank you for all your work
-
@bjoern85 did you try starting the script as documented in the README?
From your SBC terminal (or SSH):
./timelapse.py <folder> <duet_host> <webcam_url>
