GRIP with USB Camera

[Cobra Commander]

Originally Posted by SLAB-Mr.Thomas

GRIP on the roboRIO with our USB Lifecam 3000-HD works without camera error...

Do I still initialize the camera server when trying to use it with grip?

CameraServer server = CameraServer.getInstance();
		server.setQuality(50);
		server.startAutomaticCapture("cam1");

[ThomasClark]

If you initialize the cameraserver in your robot program GRIP probably won't be able to access it. Usually only one application can access a camera at a time on Linux.

To get similar functionality as CameraServer, you can use the "Publish Video" operation in GRIP.

[Cobra Commander]

I think we are really close to getting this working!

What is setting property #16?

We are getting this error on our deploy:

Jan 27, 2016 1:53:36 AM edu.wpi.grip.core.Main start
INFO: Loading file /home/lvuser/project.grip
VIDEOIO ERROR: V4L/V4L2: VIDIOC_S_CROP
VIDEOIO ERROR: V4L: setting property #16 is not supported
Jan 27, 2016 1:53:40 AM edu.wpi.grip.core.Main start
INFO: SUCCESS! The project is running in headless mode!

[ThomasClark]

Originally Posted by Cobra Commander

I think we are really close to getting this working!

What is setting property #16?

We are getting this error on our deploy:

Jan 27, 2016 1:53:36 AM edu.wpi.grip.core.Main start
INFO: Loading file /home/lvuser/project.grip
VIDEOIO ERROR: V4L/V4L2: VIDIOC_S_CROP
VIDEOIO ERROR: V4L: setting property #16 is not supported
Jan 27, 2016 1:53:40 AM edu.wpi.grip.core.Main start
INFO: SUCCESS! The project is running in headless mode!

Looking at the OpenCV source code, it seems like it has a lot of video capture properties available for V4L (the Linux video capture API), but most of them are only supported with V4L 2. If you're using V4L 1 and you try to set any property besides the few that are supported, OpenCV prints an error message

This is completely harmless. Since we don't do anything to manually configure camera settings in GRIP, any properties that get set are just by OpenCV trying to set up some defaults.

Is the project working otherwise? I noticed you have a SUCCESS message and no exceptions.

[Cobra Commander]

Yes! Everything appears to be working. I saw the error an I guess I panicked.

Everything appears to be operational, network tables and all.

Should I be concerned about this error? Everything seems to still work but, maybe.

Loading Dependency Injection Framework
Jan 28, 2016 3:48:21 AM java.util.logging.LogManager$RootLogger log
CONFIG: Configuration done.
Jan 28, 2016 3:48:22 AM java.util.logging.LogManager$RootLogger log
CONFIG: GRIP Version: 1.1.1
platform: /Linux/arm/
Jan 28, 2016 3:48:28 AM edu.wpi.grip.core.Main start
INFO: Loading file /home/lvuser/project.grip
VIDEOIO ERROR: V4L/V4L2: VIDIOC_S_CROP
VIDEOIO ERROR: V4L: setting property #16 is not supported
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Input must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Value must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Value must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Value must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Value must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Value must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Value must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Value must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionEvent
SEVERE: Value must have a value to run this step.
Jan 28, 2016 3:48:32 AM edu.wpi.grip.core.Main onExceptionClearedEvent
INFO: Exception Cleared Event
Jan 28, 2016 3:48:33 AM edu.wpi.grip.core.Main onExceptionClearedEvent
INFO: Exception Cleared Event
Jan 28, 2016 3:48:33 AM edu.wpi.grip.core.Main onExceptionClearedEvent
INFO: Exception Cleared Event
Jan 28, 2016 3:48:33 AM edu.wpi.grip.core.Main onExceptionClearedEvent
INFO: Exception Cleared Event
Jan 28, 2016 3:48:33 AM edu.wpi.grip.core.Main start
INFO: SUCCESS! The project is running in headless mode!

It says the image must have a value but, it appears to be getting an image from something.

[ThomasClark]

While the project is loading, the steps start running before the camera is ready. This isn't really concerning, and it should be fixed in the next release.

[joeojazz]

Hi Thomas I am still not able to get my camera (Microsoft 3000 USB) to be found in version 1.1.1. Every time I enter 0 the error pops up "A problem occurred trying to start the frame grabber for Webcam 0". I know this camera works do testing it on the robot and on other computers that have the older version of Grip on them.

Sincerely,
Joe

[ThomasClark]

Can you try it on the other computers with a newer GRIP? AFAIK nothing has changed with USB cameras between the last few versions of GRIP, so it may be a driver issue.

[Crossle86]

Originally Posted by ThomasClark

If you initialize the cameraserver in your robot program GRIP probably won't be able to access it. Usually only one application can access a camera at a time on Linux.

To get similar functionality as CameraServer, you can use the "Publish Video" operation in GRIP.

We did this but the feed to the DS was very slow, too slow to be useful.

Also, we have code that uses the NI camera support to switch the DS feed between multiple USB cameras...but we can't use it if GRIP is running. Is there some way or could a way be added for the robot code to feed images to GRIP instead of GRIP commandeering the camera? We are interested in GRIP but do not want to give up our existing camera server code.

[joeojazz]

Figured it out that the drivers of the camera had not been fully downloaded. Thanks for your help.

[pluto7443]

Hey, so we are having some issues with getting the network tables to work. I was wondering if you guys who got it working could elaborate on how you got that side of things working? We're using C++.
Thanks!

[s-taylor]

Hi, all.

My problem is similar to others in the thread, but not quite the same.
I can get GRIP 1.2.0 running just fine on my laptop, using the MS Lifecam 3000 USB. it publishes to NetworkTables on the RIO, and then the DS is able to act upon it to control the robot as expected.

So far, so good.

But when trying to deploy the GRIP to the robot (so it can run headless on the RIO), I get this error:

/usr/local/frc/JRE//bin/java -Xmx50m -XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError -jar '/home/lvuser/grip.jar' '/home/lvuser/project.grip'
Loading Dependency Injection Framework
Jun 05, 2015 8:40:12 PM java.util.logging.LogManager$RootLogger log
CONFIG: Configuration done.
Jun 05, 2015 8:40:12 PM java.util.logging.LogManager$RootLogger log
CONFIG: GRIP Version: 1.2.0
platform: /Linux/arm/
Jun 05, 2015 8:40:17 PM edu.wpi.grip.core.Main start
INFO: Loading file /home/lvuser/project.grip
Jun 05, 2015 8:40:19 PM edu.wpi.grip.core.Main start
INFO: SUCCESS! The project is running in headless mode!
Jun 05, 2015 8:40:19 PM edu.wpi.grip.core.PipelineRunner$1 startUp
INFO: Pipeline Starting
OpenCV Error: Assertion failed (ssize.area() > 0) in resize, file /home/javacpp-presets/opencv/cppbuild/linux-frc/opencv-3.0.0/modules/imgproc/src/imgwarp.cpp, line 3208
VIDEOIO ERROR: V4L/V4L2: VIDIOC_S_CROP
Jun 05, 2015 8:40:19 PM edu.wpi.grip.core.Step runPerformIfPossible
WARNING: The CV resize operation did not perform correctly.
java.lang.RuntimeException: /home/javacpp-presets/opencv/cppbuild/linux-frc/opencv-3.0.0/modules/imgproc/src/imgwarp.cpp:3208: error: (-215) ssize.area() > 0 in function resize

	at org.bytedeco.javacpp.opencv_imgproc.resize(Native Method)
	at edu.wpi.grip.generated.opencv_imgproc.Resize.perform(Resize.java:58)
	at edu.wpi.grip.core.Operation.perform(Operation.java:61)
	at edu.wpi.grip.core.Step.runPerformIfPossible(Step.java:139)
	at edu.wpi.grip.core.PipelineRunner.runPipeline(PipelineRunner.java:196)
	at edu.wpi.grip.core.PipelineRunner.access$200(PipelineRunner.java:32)
	at edu.wpi.grip.core.PipelineRunner$1.runOneIteration(PipelineRunner.java:76)
	at com.google.common.util.concurrent.AbstractScheduledService$ServiceDelegate$Task.run(AbstractScheduledService.java:189)
	at com.google.common.util.concurrent.Callables$3.run(Callables.java:100)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

Note no startup errors prior to the ssize.area() error.
I do start GRIP from RobotInit as specified:

        /* Run GRIP in a new process */
       try {
            new ProcessBuilder("/home/lvuser/grip").inheritIO().start();
        } catch (IOException e) {
            e.printStackTrace();
        }

I've tried rebooting the RIO prior to deploying, just in case some other instance of GRIP was already running.

I also made sure the CameraServer is not running.

I'm GUESSING that the camera isn't sending any images to the first pipeline stage (resize)... but there's insufficient debug info in the log to tell me what might be wrong.

I checked that the GRIP file is using device 0, and this matches what is in the RIO dashboard (which says "cam0").

Thoughts?
-Scott

[ThomasClark]

Originally Posted by s-taylor

I'm GUESSING that the camera isn't sending any images to the first pipeline stage (resize)... but there's insufficient debug info in the log to tell me what might be wrong.

I would agree with that. The camera is sending "empty" 0x0 pixel, 0-channel images, probably because it didn't initialize correctly. A few other people have had basically the same problem, so we've been trying for the past week to reproduce this, but we haven't got it to happen with at least an actual error message about the camera.

One this I would recommend trying out is the v1.3 release candidate 1. The only thing it changes about cameras is that they now try to restart if they don't work the first time. The problem might be as simple as cameras not connecting the first time because they're initializing or something weird.

Let me know if this helps.

[1024Programming]

Originally Posted by ThomasClark

I would agree with that. The camera is sending "empty" 0x0 pixel, 0-channel images, probably because it didn't initialize correctly. A few other people have had basically the same problem, so we've been trying for the past week to reproduce this, but we haven't got it to happen with at least an actual error message about the camera.

One this I would recommend trying out is the v1.3 release candidate 1. The only thing it changes about cameras is that they now try to restart if they don't work the first time. The problem might be as simple as cameras not connecting the first time because they're initializing or something weird.

Let me know if this helps.

THANK YOU! Been waiting for command line arguments for a long time!

[s-taylor]

Thanks, Tom! I'll try installing that tonight.

BTW, we are finishing our build season in the WPI pits (since we don't have access to Burncoat HS during winter vacation)... so we will be on campus tonight from 6-10 if you happen to be around and want to see an instance of this issue "live". My email is s-taylor@att.net if you want to contact me outside of this thread.