robotpy cscore seg fault on Raspberry Pi


#1

Hi All,

I’ve been working on getting a camera to work on an Rpi.

I built opencv per the instructions found here:
https://raspberrypi.stackexchange.com/questions/69169/how-to-install-opencv-on-raspberry-pi-3-in-raspbian-jessie

apropos, I used the sources from https://github.com/opencv/opencv/releases
(hence, using 3.4.3)

I then built robotpy cscore per the instructions at https://robotpy.readthedocs.io/en/latest/install/cscore.html#install-cscore (non roborio platforms).

As you’ll see below, I have a couple print statements wrapped around the call to grabFrame. I get the 1st, but not the 2nd. So, it appears getFrame is seg-faulting.

Any idea what I am (or did) wrong?

Code looks like:


    cs = CameraServer.getInstance()
    cs.enableLogging()
    
    cam = UsbCamera('logi c170', 0)
    cs.addCamera(cam)
    
    cam.setResolution(640, 480)
    
    # Get a CvSink. This will capture images from the camera
    cvSink = cs.getVideo(camera=cam)
    
    # (optional) Setup a CvSource. This will send images back to the Dashboard
    outputStream = cs.putVideo("Rectangle", 640, 480)
    
    # Allocating new images is very expensive, always try to preallocate
    img = np.zeros(shape=(480, 640, 3), dtype=np.uint8)    

    while True:
        # Tell the CvSink to grab a frame from the camera and put it
        # in the source image.  If there is an error notify the output.
        print('grab')
        time, img = cvSink.grabFrame(img,0.5)
        print(time, img)

Output looks like:


INFO:nt:NetworkTables initialized in client mode
DEBUG:nt.th:Started thread nt-dispatch-thread-0
DEBUG:nt.th:Started thread nt-client-thread-0
DEBUG:nt:client connected
DEBUG:nt.th:Started thread nt-net-write-0
DEBUG:nt.th:Started thread nt-net-read-0
INFO:nt:CONNECTED roborio-1289-frc.local port 1735 (Robot)
DEBUG:nt.th:Started thread entry-notifier-0
INFO:cscore:logi c170: Connecting to USB camera on /dev/video0
INFO:cscore:logi c170: set format 1 res 160x120
INFO:cscore:logi c170: Connecting to USB camera on /dev/video0
INFO:cscore:logi c170: set format 1 res 640x480
INFO:cscore:logi c170: set FPS to 30
INFO:cscore.cserver:CameraServer 'serve_Rectangle' listening on port 1181
grab
Segmentation fault


#2

I’ve never tried 3.4.x, but I can’t imagine there’s a good reason why it would break in that way. It would be good to know why the segfault is occuring – can you install GDB and get a stack trace and post that here?


#3

See below. I’m assuming the executable I use is python3 - it appears to have generated an appropriate stack trace.


pi@dex:~ $ gdb /usr/bin/python3 core
GNU gdb (Raspbian 7.7.1+dfsg-5+rpi1) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python3...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 5661]
[New LWP 5667]
[New LWP 5662]
[New LWP 5666]
[New LWP 5672]
[New LWP 5671]
[New LWP 5670]
[New LWP 5664]
[New LWP 5663]
[New LWP 5674]
[New LWP 5669]
[New LWP 5673]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `/usr/bin/python3 ./PiVision.py'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7101c0b8 in cv::imdecode(cv::_InputArray const&, int, cv::Mat*) ()
   from /usr/lib/arm-linux-gnueabihf/libopencv_highgui.so.2.4
(gdb) bt
#0  0x7101c0b8 in cv::imdecode(cv::_InputArray const&, int, cv::Mat*) ()
   from /usr/lib/arm-linux-gnueabihf/libopencv_highgui.so.2.4
#1  0x7133530c in cs::Frame::ConvertMJPEGToBGR(cs::Image*) ()
   from /usr/local/lib/python3.4/dist-packages/cscore/_cscore.cpython-34m.so
#2  0x71338bc4 in cs::Frame::GetImage(int, int, cs::VideoMode::PixelFormat, int) () from /usr/local/lib/python3.4/dist-packages/cscore/_cscore.cpython-34m.so
#3  0x71338e0c in cs::Frame::GetCv(cv::Mat&, int, int) ()
   from /usr/local/lib/python3.4/dist-packages/cscore/_cscore.cpython-34m.so
#4  0x71331434 in cs::CvSinkImpl::GrabFrame(cv::Mat&, double) ()
   from /usr/local/lib/python3.4/dist-packages/cscore/_cscore.cpython-34m.so
#5  0x00000000 in ?? ()
(gdb) Quit
(gdb)



#4

A little more… I’ve been looking at the opencv code for imdecode (in modules/imgcodecs/src/loadsave.cpp) and see the following:


Mat imdecode( InputArray _buf, int flags, Mat* dst )
{
    CV_TRACE_FUNCTION();

    Mat buf = _buf.getMat(), img;
    dst = dst ? dst : &img;
    imdecode_( buf, flags, LOAD_MAT, dst );

    /// optionally rotate the data if EXIF' orientation flag says so
    if( !dst->empty() && (flags & IMREAD_IGNORE_ORIENTATION) == 0 && flags != IMREAD_UNCHANGED )
    {
        ApplyExifOrientation(buf, *dst);
    }

    return *dst;
}

Admittedly my c++ fu is rusty - but in the comma assignment statement for buf, where is ‘img’ coming from? Given the stacktrace doesn’t show a call to imdecode_ this has my spidy-sense tingling. But I really can’t believe that this would get through to a tagged version of the code. So, I’m more than likely wrong.


#5

That’s weird, why do your libraries have ‘2.4’ in them? Do you have a different version of opencv installed? I don’t think it’s linking to the right version…


#6

May well could be.

I was using an old SD card that has a bunch of other stuff on it.

FWIW, I bought a new card, put Stretch-Lite on it, and then followed the instructions at https://www.pyimagesearch.com/2015/10/26/how-to-install-opencv-3-on-raspbian-jessie/ except that I cloned the sources from github, and made sure to do a git checkout of tags/3.4.3. I made sure to use the instructions for python3 as well.

I did use the virtual environment method, and have gotten to the point where I’m getting a frame with no segfault.

No data in the frame either, but that’s for another thread :slight_smile: