DuetLapse3

[GoremanX]

@stuartofmt Very cool, great job! You just covered all of the complexities of my crazy use-case, and that's no small feat I look forward to trying it out as soon as my warranty replacement Duet 3 board arrives... which should be any month now...

[JohnOCFII]

I'm looking forward to trying this new version. I haven't moved beyond the original yet, and I've got dying process issues on my Pi that might be related to how I hacked that together.

John

[stuartofmt]

@JohnOCFII said in DuetLapse3:

I'm looking forward to trying this new version. I haven't moved beyond the original yet, and I've got dying process issues on my Pi that might be related to how I hacked that together.

John

I have put in quite a lot of defensive code compared to the original. So this version should, in general, be more robust. As a quick datum - last night I ran three instances concurrently on a Pi 3B+ each with a browser tab polling status every 60 seconds and as well startDuetLapse3 running. Each instance captured images every 60 seconds from the camera (also running on the Pi). So a reasonable "soak test". Each captured over 750 images (~ 2200 in total).

I then issued a "terminate all" from startDuetLapse3 and only two videos were successfully created. The problem was an out-of-memory error from ffmpeg. I've not seen this type of error before and guess it was three instances of ffmeg trying all at once to create a video. I'm going to try and increase the swapfile to see if that changes anything. The images are all there - so it is recoverable.

As an aside I have startDuetLapse3 running under systemctl with restart - so it is continuously running and will restart after a shutdown - so its "always there"

[stuartofmt]

@stuartofmt said in DuetLapse3:
I'm going to try and increase the swapfile to see if that changes anything. The images are all there - so it is recoverable.

I increased the swapfile and that does seem to have solved the issue. Success with 3 instances, each with over 1300 images (total ~ 4000). The Pi I tested on only had 100M of swapfile. I increased it to 1024M. During the test ~ 350M was used. I'm on Debian Buster so the change was an edit to /etc/dphys-swapfile followed by a reboot. I did check but there does not seem to be a simple way to limit memory usage in ffmpeg - so this looks like the way to go.

[GoremanX]

@stuartofmt Looks like I need to update the master image for my Pis! Out of curiosity, how much memory is on the boards you've been testing with? I'm a cheap bastard, I tend to stick to the base boards, so all mine have 1GB (older) or 2GB (current). I've been considering getting some fancy-schmancy 8GB boards for the next ones, but it's hard to justify that $40 premium just for memory I might never make use of

[stuartofmt]

@GoremanX said in DuetLapse3:

Out of curiosity, how much memory is on the boards you've been testing with?

From

cat /proc/cpuinfo | grep Model

Model                 : Raspberry Pi 3 Model B Rev 1.2

This model has:
1.2 GHz 64-bit quad core ARM Cortex-A53 and 1GB RAM
I have a 32GB card.
In all - it seems to cope well. Here is what it looks like with the following load:

• Camera streaming - 9 simultaneous connections (3 internal - 6 external taking snapshots ~ 2 per second) + 1 external constantly streaming connection.
• startDuetLap connectionse3
• DuetLapse3 - 3 instances capturing images every 5 seconds
• chromium - running dueui

Chromium is the biggest load ~ 17%. ffmpeg slips in periodically at about 12% and the DuetLapse3 instances each peak at 7% when they are busy .

The load average suggests this is handling it pretty well (lets say ~ 25% CPU utilization).

But as you can see - the previous 100M swapfile was not enough. 1GB may be a little big but it seems like it will be a "safe" number.

This is further supported by:

pi:~ $ uptime
 11:15:16 up 18:58,  3 users,  load average: 1.21, 1.08, 0.98

[GoremanX]

Finally got a chance to try this yesterday. It works perfect. I'm using reprap_notify to monitor the state of the printer. It polls the Duet 3 board every 30 seconds. When it detects that a print job has started, it starts an instance of DuetLapse3. When the job ends, it sends a terminate command via curl. I get an email notification of each event, and also if/when the printer pauses. All the files end up exactly where they need to. I have a second browser tab for monitoring the status of DuetLapse3. Everything appears to run reliably.

[stuartofmt]

@GoremanX said in DuetLapse3:

It works perfect.

Thanks for the feedback!
I'm sure you have not tried hard enough to break it

I do have a small update coming but this is just to protect against some ffmpeg limitations. ffmpeg tries to gobble up lots of CPU and Memory if multiple instances are running. Does not affect most users but surfaced in my stress testing.

[stuartofmt]

@GoremanX said in DuetLapse3:

When it detects that a print job has started, it starts an instance of DuetLapse3.

I'm curious as to the utility of this approach versus DuetLapse3 just sitting there waiting for a print job to start (-detect layer) ? I'm asking as it may suggest missing functionality or improvements.

@GoremanX said in DuetLapse3:

When the job ends, it sends a terminate command via curl.

DuetLapse3 will terminate itself when the print job completes - so wondering why you are sending a separate command ? A bug in a prior release ?

[GoremanX]

@stuartofmt I found that the layer detection starts capture too late sometimes. I prefer to use "dontwait" and start the process manually, even if it results in capturing initial Calibration and bed probing for nothing. I'd rather have too many photos at the beginning than not enough.

As for terminating manually, that's mostly to be 100% sure all processes got terminated. I send pid=all because in my case, a specific pi only ever monitors a single printer at a time. But having said that, I've also found that capturing ends a tad too soon. I never get a capture with the print head out of frame once the print is complete, which would be nice to have as the final frame of the video. Rather than end at the end of the last layer, it would be nice if it ended once the job is actually complete and took at least one last photo at that point before terminating

[stuartofmt]

@GoremanX said in DuetLapse3:

@stuartofmt I found that the layer detection starts capture too late sometimes.

Thanks for pointing that out. I may have a bug there (off by one layer). I'll take a closer look.

..... I've also found that capturing ends a tad too soon. ...... it would be nice if it ended once the job is actually complete .....

Again - thanks for pointing this out.

The Duet transitions to "idle" when the print job is complete. I can't be totally sure what it considers "complete". The last of the gcode command enqueued? The last movement completed? Something in between?
@dc42 any clarity you can provide would be appreciated.

In any case the problem is likely that there is no "last layer" transition. I.e. the start of the last layer is captured but not the end. One way around this might be to include end of job gcode to send the print head to X0,Y0 (G0 X0 Y0) followed by a relative move of the Z axis (G91 G0 Z1).

Another may be to force one last capture when idle is detected - but who knows where the head would be ?

I'll play around over the next few days and see if anything becomes clearer.

[stuartofmt]

@GoremanX

I took a look at my existing gcode. This explains why I had not seen the "ends a tad too soon" phenomenon.

G91           ;relative mode
G0 Z1         ;E Move the bed away a little note use of E after comment for correct layer count
G90           ;Back to absolute mode
G0 X0 Y0      ;Get the print head out of the way

This is what the last frame of my my last print ended up looking like.
(P.S. looks like a E retract may be helpful to eliminate that string )

[GoremanX]

@stuartofmt Ah, I get it. So you've got a move to get the print head out of the way before the end of the gcode file. I'll just add something similar, then, thank you!

[XerxasJade]

Hi,

I recently swapped from Danal's to this version, but I am having issues with the resolution of the images? In the old version I could use -r to force them to be taken at 1920x1080 but for some reason I am stuck with images that are 352x288

The code I am currently running is:
python3 ./DuetLapse/DuetLapse3.py -duet tronxyduet2 -detect pause -extratime 5

I tried to work out the camera parameters for this version myself but I have to admit Linux is not my strongest point. I am running this on a Pi V3

Also possibly related/unrelated when the print finished and it went to make the video, the video came out as 0kb..

For Reference I am running:
RepRapFirmware for Duet 2 WiFi/Ethernet 3.2.2 (2021-02-11)
Duet Web Control 3.1.1

[stuartofmt]

@XerxasJade said in DuetLapse3:

Hi,

I recently swapped from Danal's to this version, but I am having issues with the resolution of the images? In the old version I could use -r to force them to be taken at 1920x1080 but for some reason I am stuck with images that are 352x288

Hi - First let me say that, in terms of the method for creating video's - there is not much difference between Danal older version and mine. The main difference is if extratime is specified.

Basically though - it looks like there are two problems (1) the video not being created and (2) the resolution of the captured images.

For problem 1:
To use extratime on the Pi requires a more modern version of ffmpeg than is normally installed. I call this out in the documentation but if its unclear - let me know. What version are you running ?

ffmpeg -version

also what is the output (last line) of

ffmpeg -filters | grep tpad

It should be something like:
... tpad V->V Temporarily pad video frames.

If it's not there - your version of ffmpeg does not support extratime

Just by coincidence - I ran into the same problem today. I upgraded the Pi yesterday and it replace the more modern version of ffmpeg with an older one
The solution - if you want to use extratime is to follow the notes I supplied in github and to create a newer version .

I just recreated a newer version. It takes a long time (~ an hour) on the Pi - mostly waiting for it to compile. Anyway the video generation works again.

Once you have a new version of ffmpeg - you can recover your "lost" video's (with extratime) by going into the directory with the captured images and execute the following (or similar):

ffmpeg -r 10 -i "Camera1_%08d.jpeg" -c:v libx264 -vf tpad=stop_mode=clone:stop_duration=5  test.mp4

or if you just want to create a video with your current version of ffmpeg - try:

ffmpeg -r 10 -i "Camera1_%08d.jpeg" -vcodec libx264 -y test.mp4

Problem 2:
The standard image capture on DuetLapse3 (and Danals version) does not set image resolution. You did not say but I'm assuming you are using the Pi camera? If this is the case the defaut is full resolution . In general the image resolution is done by whatever application is capturing the images. What are you using ? I'm unclear what you mean by setting -r ?

The -r option on ffmpeg affects the frame rate (i.e. speed of timelapse) but not the resolution.

Bottom line - need some more information before we can solve the resolution issue but I'm pretty sure it lies outside DuetLapse3.

[XerxasJade]

@stuartofmt

Hey, Thankyou for the quick response.

I had completely missed the ffmpeg version issue. So it turns out I was running 4.1.6 so I'v updated that and i'll see how it goes on tonight's print.

Regarding the -r and resolution issue here is everything I know...

I am using a logitech 1080p webcam connected via usb - I previously had this exact issue with the old script but was able to fix it with the following command:

./DuetLapse/DuetLapse.py -duet "Hostname" camparms -parms -r 1920x1080

This was based on code discussed by baenwort and arhi from the old thread. For me it solved the issue.

I suspect the issue isn't with the duetlapse software and more likely me getting the syntax wrong, or that I need to set the camera somewhere else now.. But that is the bit i'm not 100% sure how to solve/find. I tried playing around camera1 parameters but didn't have much success.

Edit, I'm not sure what software is capturing the images, but i'm assuming fswebcam is doing it maybe?? this is where my linux knowledge runs out

[stuartofmt]

@XerxasJade said in DuetLapse3:

@stuartofmt
I am using a logitech 1080p webcam connected via usb - I previously had this exact issue with the old script but was able to fix it with the following command:

./DuetLapse/DuetLapse.py -duet "Hostname" camparms -parms -r 1920x1080

This is an area where I made changes to improve on the flexibility of the origin. This new definition of camparam (and vidparam) allows the user to specify arbitrary programs and switches depending on their camera. Put another way - you are not restricted to the camera types, programs and settings of the four standard types.

From the documentation:

-camparam1="[command]"

If omitted has no default. Used in conjunction with -camera1 to define how the images will be captured.
Note the use of the = and quoting of the command string. Single quotes should be used in the command string when needed.
There are 3 internal variables that can be used weburl (which has the value of weburl1), fn (which is the file for the captured images) , debug (which controls verbose logging)

example
-camparam1="'ffmpeg -y -i '+weburl+ ' -vframes 1 ' +fn+debug"

This example is the same as if -camera1 stream was used. The value of weburl1 would be substituted for weburl and the output goes the the file specification fn. the results are verbose of not is defermined by the internal variable debug. In general both fn and debug should be used. The use of weburl would depend on the capture method being used.

Notes on the use of -camparam1
The following are the standard commands for reference

-camera usb
'fswebcam --quiet --no-banner '+fn+debug

-camera pi
'raspistill -t 1 -ex sports -mm matrix -n -o '+fn+debug

-camera stream
'ffmpeg -y -i '+weburl+ ' -vframes 1 ' +fn+debug

-camera web
'wget --auth-no-challenge -nv -O '+fn+' "'+weburl+'" '+debug

So in your case you will need to specify -camera1 other because you are no longer using the default settings for usb.

You then need to specify -camparam1, in your case based on the default usb adding in your specific changes.

-camparam1="'fswebcam --quiet --no-banner -r 1920x1080 '+fn+debug"

resulting in a command line that looks like this:

python3  <your path>/DuetLapse3.py -duet "Hostname" -camera1 other -camparam1="'fswebcam --quiet --no-banner -r 1920x1080 '+fn+debug"

[XerxasJade]

@stuartofmt said in DuetLapse3:

python3 <your path>/DuetLapse3.py -duet "Hostname" -camera1 other -camparam1="'fswebcam --quiet --no-banner -r 1920x1080 '+fn+debug"

Thankyou so much, I had a feeling I was missing something I just didn't know enough, to actually know where to start looking

I would have never worked that out myself, I was close with a couple of things I tried but would have never thought to add the "-camera1 other"

I'll try it when my current print finishes, Thankyou So Much Your a Legend!!

[stuartofmt]

Released version 3.4.1. Much nicer to use the browser UI with some extra "goodies" to avoid the need to remote into your server. Some small functional tweaks based on feedback from the last release.

###Version 3.4.1###
Changes to DuetLapse3
[1] Changed the browser UI to a single page layout.
[2] The file function is restricted to the specific instance.
[3] File functions expanded to allow deletion of video files. startDuetLapse3 has more options.
[4] If using -detect layer capture starts on layer 0 (previously was layer 1).
[5] An additional image is captured immediately before a video is created, independent of other settings.
[6] If the version of ffmpeg does not support -extratime it is ignored.

Changes to startDuetLapse3
[1] Changed the browser UI to a single page layout.
[2] Added an optional argument (-topdir) to set the top level directory for file functions. If used - this would normally be set the same as DuetLapse or at the "duetip" level
[3] File functions expanded to allow delete and zip. This is "conservative" - will not allow deletion of files / directories of running instances. Can only zip directories.

Note: If it was not obvious - Clicking on the links either opens, displays or downloads the directory / file depending on your browser settings.

[JohnOCFII]

Finally getting around to replacing Danel's version.

I'm running this on CentOS Stream 8.

I received this error on my first test run. I haven't troubleshot yet, as I've got to head out the door, but looks like a character set/codec issue.

My command line:

python3 /opt/DuetLapse/DuetLapse3.py -duet railcore.localdomain -camera1 web -weburl1 http://octocore.localdomain:8081/snapshot -detect none -dontwait -seconds 2 -extratime 4

My error message:

pi@octocore:~ $ python3 /opt/DuetLapse/DuetLapse3.py -duet railcore.localdomain -camera1 web -weburl1 http://octocore.localdomain:8081/snapshot -detect none -dontwait -seconds 2 -extratime 4
Cleaning up phase:  startup
Traceback (most recent call last):
  File "/opt/DuetLapse/DuetLapse3.py", line 1732, in <module>
    init()
  File "/opt/DuetLapse/DuetLapse3.py", line 225, in init
    f_handler = logging.FileHandler(logfilename, mode='w')    
  File "/usr/lib/python3.7/logging/__init__.py", line 1092, in __init__
    StreamHandler.__init__(self, self._open())
  File "/usr/lib/python3.7/logging/__init__.py", line 1121, in _open
    return open(self.baseFilename, self.mode, encoding=self.encoding)
UnicodeEncodeError: 'latin-1' codec can't encode character '\u02f8' in position 61: ordinal not in range(256)
pi@octocore:~ $