Octoprint: Feature Request - Integration of a second webcam (in a separate tab)

[hp-bioing]

Is there a way to include a second webcam into octoprint?

Working on a Octoprint driven bioprinter I would like to have one webcam as an overview cam and the other one mounted directly on the printhead for doing print inspection and furthermore testing some machine vision ideas.Would be great if I could have both in separate tabs within Octoprint.

Any hinds are welcome!

[vinmicgra]

+1

[dbrgn]

Support for an arbitrary number of webcams would be great.

[Nurgak]

This feature would be really nice to have, especially since the webcams nowadays are really cheap. In my case having one looking at the printed part and a second one that looking at the remaining filament would be very useful (or second point of view of the printed part).

[foosel]

Related to this: OctoPrint On Air #7 (00:13:45).

[hamselvdk]

Has this been started?

[joeydraft]

Not by me? :-)

JOEY OLSON
Owner / Executive Developer

Draft Design House, LLC
309 Main St
Eau Claire, WI 54701

(715) 514 - 4560
DraftDesignHouse.com http://www.draftdesignhouse.com/
Confidentiality Notice: This email may contain confidential and/or private
information. If you received this email in error please delete and notify
sender.

On Wed, Nov 22, 2017 at 11:01 AM, hamselvdk [e-mail]
wrote:

Has this been started?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/foosel/OctoPrint/issues/401#issuecomment-346412716,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX4Ab9ago23XU8myeOH-z8RAKsoaXyeJks5s5FN0gaJpZM4BmjYz
.

[jontek2]

+1

[BETLOG]

I have a feeling this is in the domain of a plugin.
Some 'simple' modification of css to include a second stream source field and image div would be within the scope of a plugin.
I already use a separate page with two cameras displayed, but to have them embedded directly into the octoprint UI would be far better.

[PixlEmly]

Update: Follow instructions below - much faster than working out which changes in the article I found are still relevant.

Someone's adapted the octoprint/pi self-setup tutorial to configure the system to process a second feed. It doesn't cover modding anything in octoprint proper as it's more for use with their own paid app but at the very least will make a second camera URL available to bookmark. Might poke at the rest and see about modding the ui to match.
https://printoid.net/2017/04/29/trick-12-support-two-cameras-in-printoid-premium/

nb: if you arent using their thing I'd skip over the external accessiblity steps and just do the main part to bring up the feed. I would also suggest at least a rpi3 and a powered hub for this.

[BETLOG]

From my notes, basically the same, but in a format I use to step through the process by copy/pasting:

sudo nano /boot/octopi.txt
edit with brain engaged, some options left in and remmed out because maybe useful with better network speed or as test.

#camera="auto"
camera=raspi
#camera=usb

#default
#camera_usb_options="-r 640x480 -f 10"

#YPCendoscope
#camera_usb_options="-r 640x480 -f 10"
camera_usb_options="-r 1280x720 -f 10"
#camera_usb_options="-r 1600x1200 -f 10"

#logitech old
camera_usb_options="-r 960x720 -f 10"

#default
#camera_raspi_options="-fps 10"

#raspicam
camera_raspi_options="-fps 10 -x 1280 -y 720"
#camera_raspi_options="-fps 10 -x 1600 -y 1200"

#additional_brokenfps_usb_devices=("046d:082b" "aabb:ccdd")

#camera_http_webroot="./www-octopi"
#camera_http_options="-n"

sudo nano /etc/haproxy/haproxy.cfg
replaces entire file

        maxconn 4096
        user haproxy
        group haproxy
        log 127.0.0.1 local1 debug

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        option http-server-close
        option forwardfor
        maxconn 2000
        timeout connect 5s
        timeout client  15min
        timeout server  15min

frontend public
        bind *:80
        bind 0.0.0.0:443 ssl crt /etc/ssl/snakeoil.pem
        option forwardfor except 127.0.0.1
        use_backend webcam if { path_beg /webcam/ }
        use_backend snakecam if { path_beg /webcam2/ }
        default_backend octoprint

backend octoprint
        acl needs_scheme req.hdr_cnt(X-Scheme) eq 0

        reqrep ^([^\ :]*)\ /(.*) \1\ /\2
        reqadd X-Scheme:\ https if needs_scheme { ssl_fc }
        reqadd X-Scheme:\ http if needs_scheme !{ ssl_fc }
        option forwardfor
        server octoprint1 127.0.0.1:5000
        errorfile 503 /etc/haproxy/errors/503-no-octoprint.http

backend webcam
        reqrep ^([^\ :]*)\ /webcam/(.*)     \1\ /\2
        server webcam1  127.0.0.1:8080
        errorfile 503 /etc/haproxy/errors/503-no-webcam.http

backend snakecam
        reqrep ^([^\ :]*)\ /webcam2/(.*)     \1\ /\2
        server webcam2  127.0.0.1:8090
        errorfile 503 /etc/haproxy/errors/503-no-webcam.http

restart haproxy or reboot

sudo service haproxy restart

start the instance

LD_LIBRARY_PATH="/home/pi/mjpg-streamer/" /home/pi/mjpg-streamer/mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 1280x720" -o "output_http.so -p 8090 -w /www/webcam2"

view the instances
http://192.168.178.26/webcam/?action=stream
http://192.168.178.26/webcam2/?action=stream
or with DNS
http://octopi3/webcam/?action=stream
http://octopi3/webcam2/?action=stream

make a page to view them all

nano /home/pi/mjpg-streamer/www-octopi/allcams.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
    <title>test</title>
    <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
    <link rel="stylesheet" href="style.css" type="text/css" />
        <style>
            body {
                background-color: #222;
                margin: 0;
            }
            #cameras {
                white-space: nowrap;
                width: 100%;
                display: table;
            }
            .image {
                vertical-align: middle;
                padding: 2px;
                display: table-cell;
            }

            .image img {
                max-width: 100%;
            }                        
        </style>
    </head>

    <body>
        <div id="cameras">
            <div class="image">
                <img src="http://octopi3/webcam/?action=stream" alt="cam1" />
            </div>
            <div class="image">
                <img src="http://octopi3/webcam2/?action=stream" alt="cam2" />
            </div>
        </div>
  </body>
</html>

view it
http://octopi3/webcam/allcams.html

make second stream persistent

sudo nano /etc/rc.local
edit with brain engaged, syntax and system critical file

LD_LIBRARY_PATH="/home/pi/mjpg-streamer/" /home/pi/mjpg-streamer/mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 1280x720" -o "output_http.so -p 8090 -w /www/webcam2"

exit 0

[BETLOG]

For this issue I think a plugin needs to either:
a) allow the existing webcam panel to have another page (URI to a html file) entered as it's value in settings. Right now it seems to be limited to links directly to image feeds only. This would allow for the display of an array of images in the existing webcam space, and opening of that secondary page when clicked. Negating the need for additional tabs, and equally intuitive to fullscreen plugin.
b) remove the cam feed from the controls tab entirely, and on a new tab (assuming it can present alongside the current tabs, and not in some redundant sub-menu-sub-tab like i have seen other tab adding plugins do) and add facility to insert multiple URIs, one for each cam. Preferably with grid/flow layout options like Custom Control Editor does. Preferably with option for an array of small fit-to frame images that individually expand as per fullscreen plugin when double clicked.

[PixlEmly]

640x480 at least, with a c270 and a c920 off a powered hub appear ok on a rpi1b - mine's max OC, but seems like if you have good and stable power, dual webcams is not actually too demanding.

 7064 haproxy   20   0   11964   6792   2032 R 18.8  1.4   1:27.56 haproxy
  332 pi        20   0  231476  67324   9572 S  7.4 14.1  13:25.93 octoprint
  357 pi        20   0   42816   4936   4168 S  1.9  1.0   0:55.65 mjpg_streamer
 7466 pi        20   0   41760   3508   3156 S  1.6  0.7   0:09.08 mjpg_streamer

[PixlEmly]

Also, should find which script is taking snapshots+assembling them and add in more lines to process snaps from the other camera(s) - I'm planning at least 3 ultimately:
1 - Macro of build plate.
2 - Overall view from further away
3 - filament view - see it's feeding ok.

[BETLOG]

I concur. I have also been interested in doing exactly that. Currently have cams on print and spool, borescope neeeds a hotend integrating design.. so is pending.
However, assuming a raspicam is the primary, that means the following are occupying the pi's usb connections: printer, usb camera 2, usb camera 3.
For those of us using a usb keyboard, and or a usb wifi modem, this means we run out of ports.
...just a general consideration.

[szafran81]

https://plugins.octoprint.org/plugins/multicam/ this should help.

[jneilliii]

Nice...I actually hacked together one too that adds it's own tab...

https://github.com/jneilliii/OctoPrint-MultiCamView

[PixlEmly]

@jneilliii Works quite well - with the minor issue that both buttons seem to get stuck disabled if you click back and forth a couple of times (Chrome 66.0.3359.139)
While watching a print I can imagine many users would switch around to check things out. A refresh clears it, but still.

[foosel]

Closing since there are even two plugins now.

[szafran81]

@jneilliii you should put it in the plugin repo.

[compatibilizer]

I don't know if this makes sense but, wouldn't it be better to handle each camera single-handed?
Pi never needs to run 2 cams together, if you're not aiming for a special project like real-time 3D reconstruction (which would be really cool, but definitely way above the capability of a raspberry pi)

All we need is to cycle between the cameras. The plugin could give you a "switch" that will "unbind current camera, bind the other one and restart the service".

Thus, the Pi would only need to handle one cam at a time, solving the power and processor bottleneck issues. Does it make sense?

[BETLOG]

@compatibilizer I'm sure that would be a logical option, but the assumption that nobody needs or wants to use more than one camera at a time is inherently incorrect.
Also; the act of killing and starting camera services is more potentially disruptive to smooth scheduling and USB bus control than simply running several concurrently. At the very least it would probably manifest as printer pauses, and cameras failing to (re)start, or throwing errors because the previous instance hasn't exited properly yet. If you ever experiment with starting and stopping a camera a few times manually, like when testing different resolutions/fps, you will discover that sometimes a cam needs to be killed and then started several times before the prior cam process successfully stops and can be restarted.
Simply displaying all of the available cameras in a variety of ways is much less complicated.

[bryanhunwardsen]

@foosel I have motioneyeos serving a few additional cam streams to octoprint via multicam plugin, however, additional streams (i.e. 192.168.1.225:8081) are only available in the local network and cease to function when accessing octoprint remotely on 80 via port forward. Is there something that can be done natively in octoprint to package these additional streams for consumption on 80 just like the primary stream attached to octoprint?

[foosel]

Is there something that can be done natively in octoprint to package these additional streams for consumption on 80 just like the primary stream attached to octoprint?

No. That "packaging" isn't done in OctoPrint but rather the reverse proxy in front of it (haproxy on OctoPi). OctoPrint can't do anything about this stuff since OctoPrint isn't the webcam server (and forwarding the webcam stream through OctoPrint would be a terrible idea due to performance reasons).

[PixlEmly]

Some notes on previous comments:

• Power demand on cameras is best offloaded with a powered USB hub - Pis are notorious for power issues in the best case, so this is unfortunately almost a requirement.
• See my output of top above - even on a pi from ~5 years ago mjpg_streamer is not using significant processing time - as long as your camera provides mjpg and not YUV/UYVY
• If you've followed the directions above you should already have 2 or more cameras active and accessible via "subdirectories" - separate cameras are selected with the URL itself vs ports via haproxy, which means you don't need to connect to the mjpg_streamer process on 808x, you just use /webcam, /webcam2, or whichever paths you've mapped - haproxy can even retrieve and serve content from other IP:PORT sources - just swap out as required.