Error setting up Pi4 with HQ Camera

I’m getting an error running the initial setup when it tries to setup the camera.
Failed to initialize linux tool TypeError: Cannot read property ‘width’ of undefined
at GStreamer.start (/usr/lib/node_modules/edge-impulse-linux/build/library/sensors/gstreamer.js:76:38)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async /usr/lib/node_modules/edge-impulse-linux/build/cli/linux/linux.js:370:13

This is using the HQ Camera (CSI port) and not a USB webcam. I guess the width property is just not available for that camera?

E: running in verbose mode it prints this:

I guess this is the culprit from gstreamer.js:

let cap = device.caps.filter(c => {
            return c.width >= 640 && c.height >= 480;
        })

All the caps list a width and height of 32 for the CSI cam.
Skipping that check makes it work but no video feed goes to the dashboard.
Running gst-device-monitor-1.0 manually gives: https://pastebin.com/87NHsb2g
Sounds to me the width and height might not be parsed correctly from that output, it only takes the first int in that array at:

let width = (l.match(/width=[^\d]+(\d+)/) || [])[1];
let height = (l.match(/height=[^\d]+(\d+)/) || [])[1];

Edit 2: Ok I got it working by hardcoding a resolution of 640x480 in the gst-launch parameters. Now its transmitting frames to the dashboard.

video/x-raw,width=640,height=480,

Hi, I have the same Error on this.

Is there any solution about this problem?

@timonsku thanks a lot for the debug logs…

If you run this:

gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=1 ! video/x-raw,width=4056,height=3040 ! videoconvert ! jpegenc ! multifilesink location=test%05d.jpg

Does this give you a test00000.jpg file that looks like webcam output?

Or even:

gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=1 ! video/x-raw ! videoconvert ! jpegenc ! multifilesink location=test%05d.jpg

@timonsku @SunBeenMoon I’ve pushed v1.2.1 of edge-impulse-linux. Can you see if this helps?

npm update -g edge-impulse-linux

I have the HD camera come in later this week.

edit @timonsku: Could you also run this:

v4l2-ctl --list-formats-ext --device /dev/video0 

Thank you for your update @janjongboom :grinning:

I tried again, but there is another problem.

pi@raspberrypi:~ $ npm update -g edge-impulse-linux
npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated request-promise@4.2.6: request-promise has been deprecated because it extends the now deprecated request package, see https://github.com/request/request/issues/3142
npm WARN deprecated har-validator@5.1.5: this library is no longer supported
npm WARN deprecated debug@4.1.1: Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
npm WARN checkPermissions Missing write access to /usr/lib/node_modules/edge-impulse-linux
npm WARN checkPermissions Missing write access to /usr/lib/node_modules
npm ERR! code EACCES
npm ERR! syscall access
npm ERR! path /usr/lib/node_modules/edge-impulse-linux
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, access '/usr/lib/node_modules/edge-impulse-linux'
npm ERR!  [Error: EACCES: permission denied, access '/usr/lib/node_modules/edge-impulse-linux'] {
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'access',
npm ERR!   path: '/usr/lib/node_modules/edge-impulse-linux'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/pi/.npm/_logs/2021-04-13T07_29_59_905Z-debug.log

pi@raspberrypi:~ $ edge-impulse-linux --clean
Edge Impulse Linux client v1.2.0
? What is your user name or e-mail address (edgeimpulse.com)? SunBeenMoon
? What is your password? [hidden]

? To which project do you want to connect this device? SunBeenMoon / RPI
? Select a microphone (or run this command with --disable-microphone to skip selection) bcm2835_headphonbcm2835 Headphones - bcm2835 Headphones
[SER] Using microphone hw:1,0
[SER] Using camera mmal service 16.1 starting...
Failed to initialize linux tool TypeError: Cannot read property 'width' of undefined
    at GStreamer.start (/usr/lib/node_modules/edge-impulse-linux/build/library/sensors/gstreamer.js:76:38)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async /usr/lib/node_modules/edge-impulse-linux/build/cli/linux/linux.js:370:13

@SunBeenMoon Sorry, you need sudo for that command.

sudo npm update -g edge-impulse-linux

OMG! I made a stupid mistake! :sweat_smile:

Thank you for your kind reply @janjongboom :grinning:

It works well!! I’ll try to make model with RPI!!

2 Likes

The update seems to hang up my Pi. As soon as it gets to starting the video service the SSH connection starts to time out and I need to reboot to regain control.
I had this also happen when I hard coded a higher resolution than 640x480 in my hotfix (tried 1280x1024 and 10280x768), though it might be due to resolution modes not supported or not within in the defined stepping?

Here is the output of v4l2-ctl:

ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'YU12' (Planar YUV 4:2:0)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [1]: 'YUYV' (YUYV 4:2:2)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [2]: 'RGB3' (24-bit RGB 8-8-8)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [3]: 'JPEG' (JFIF JPEG, compressed)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [4]: 'H264' (H.264, compressed)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [5]: 'MJPG' (Motion-JPEG, compressed)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [6]: 'YVYU' (YVYU 4:2:2)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [7]: 'VYUY' (VYUY 4:2:2)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [8]: 'UYVY' (UYVY 4:2:2)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [9]: 'NV12' (Y/CbCr 4:2:0)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [10]: 'BGR3' (24-bit BGR 8-8-8)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [11]: 'YV12' (Planar YVU 4:2:0)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [12]: 'NV21' (Y/CrCb 4:2:0)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2
        [13]: 'RX24' (32-bit XBGR 8-8-8-8)
                Size: Stepwise 32x32 - 4056x3040 with step 2/2

@timonsku Hmm… yeah for those targets it should now skip resolution selection and use the default. Does:

gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=1 ! video/x-raw ! videoconvert ! jpegenc ! multifilesink location=test%05d.jpg

Yield a working file or does this hang as well?

I’m getting in a HQ Camera somewhere this week.

Same issue when running that command, this is how far it gets:
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock

This might be some helpful information:

The driver uses MMAL under the hood which makes a distinction between a video and still modes. In video mode via v4l2 it seems to only support the resolutions listed in that camera readme (first link) so 640x480, 720p and 1080p. If you are now getting the default resolution that would be 32x32px which might be the reason why it hangs as the driver expects that you choose a resolution based on that stepping in the range of 32x32 - 4056x3040 though this seems to only hold true if you open the camera in still mode which I guess v4l2 is not doing and is instead opening it in video mode, restricting what resolutions you can choose.
Might be worth opening a bug report in the userland repo: https://github.com/raspberrypi/linux
As a hotfix choosing a 640x480 res when finding a MMA (Broadcom specific) API device might be an apropriate workaround for now.

Alternatively a fall back for MMA device AND the Raspberry Pi platform would be to use their raspistill tool instead of gstreamer https://www.raspberrypi.org/documentation/raspbian/applications/camera.md

That tool talks to the MMA API directly and uses the picture mode. It also encodes JPEGs in hardware afaik which gstreamer is likely not using.
You can get a very similar result very easily with its time lapse mode. Docs here: https://www.raspberrypi.org/documentation/raspbian/applications/camera.md

F.e. should yield an endless jpeg stream:
raspistill -w 640 -h 480 -tl 0 -o image%04d.jpg

@timonsku Thanks for the update. I’m gonna dive into it when I get the hardware in.

The annoying thing with all the various tools is that it’s really hard to get a tool that works on every camera under the sun. We’ve gone through a number of iterations already, running into issues like some Logitech cams not following MJPEG spec leading to unreadable files, weird Chinese webcams that default to 2 fps with ffmpeg, issues with frame rate, etc. Gstreamer with the current pipeline seemed to finally do the trick :wink: but the debugging continues.

1 Like

Oh I’ve been there its a clustf*ck :slight_smile:
Especially in the ARM world, everyone is spinning their own peripherals for interacting with media devices and hardware acceleration.
Gstreamer was certainly a sound choice. I’d say the Pi is likely the only case where adding a special case maybe makes sense because its so dominant. Nvidia was nice enough to offer good gstreamer support for their Tegra stuff. With the Pi its a bit hit and miss, only few multimedia things are supported via standard APIs and then often a bit spotty. This is mostly Broadcoms fault, Pi foundation is trying to pick up the slack.

Defaulting to 640x480 might be a good choice for now though as a default resolution, that should be supported by the vast majority of cameras and or offer a cli flag to set width and height of the camera feed?

Hi @timonsku yep, great suggestion. I’ve got the camera now, and I see the freezes when trying to get data at max. resolution but override to 640x480 works fine. Will push this live tomorrow when we release 1.2.3 of the Linux CLI :tada:

1 Like