Timelapse pictures & videos with Duet and webcam on layer change

resam

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).

Railgunner13f

Bingo!
I am finally capturing the stills!
Where do I send the beer!

Phaedrux

Would you be able to post an example timelapse?

resam

https://www.dropbox.com/s/2ti52rimgepaq7e/2018-07-01-eggs-abs.mp4?dl=0
and
https://www.dropbox.com/s/z4az144426w9icp/2018-04-05-Einstein-bust.mp4?dl=0

Phaedrux

That's great. Exactly what I was hoping for. Hopefully I can find some time to get it setup soon.

resam

@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.

Phaedrux

@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.

resam

I'm running this on a RPiZeroW - good enough for 15fps streaming of 1280x720p and the snapshots with my script.

Danal

@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?

resam

@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.

T3P3Tony

@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.

resam

@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?)

Danal

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.

T3P3Tony

@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.

garyd9

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

bjoern85

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

resam

@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>

bjoern85

@resam thank you! and sorry for my late reply. i'm testing it right now.
it looks, like it works. somehow... i was able to download a single jpg file during the print, which has a size of 2gb but i could not open it.

edit: ...achtion=snapshot instead of ...action=stream would help, i guess

garyd9

I have to admit that my reply to this thread is, at least in part, a bump to keep it from dying... it's just too valuable.

On the other hand, I do have updated information, @resam, in regards to using this script with RR3 on a Duet3 (in standalone mode.)

For some reason, using the script from your github (pulled on 24th of Jan, 2020), the process would stop working after each print. It was almost as if the telnet session froze or locked up or something after the print finished and ffmpeg was run. I'd see the 'Print finished' message, the mp4 would be created, and then it wouldn't start again when a new print was started.

I've modified my version of the script to deal with that by breaking from the "while true" loop after a print is finished and inserting the code below before the exception handler (at the same scope as the "while true"):

conn = None
sock.shutdown(socket.SHUT_RDWR)
sock.close()

This should break the loop, shutdown and close the socket, and then loop back up for another connection attempt (which usually works fine.)

Take care
Gary

resam

Thanks @garyd9 - I haven't tested it yet on RRF3 (still need to upgrade my printers).
I'm a bit surprised because we do have error handling that should auto-reconnect if any failure with the telnet socket occurs: https://github.com/Kriechi/DuetRRF-timelapse/blob/d2b472ceb26491f07812c030e00ee1005d69487b/timelapse.py#L136

I'm happy to add more error handling - but at this point I'm not sure what actually hangs/blocks. Or did anything in RRF3 change regarding the way telnet connections are handled @dc42?