
20-03-2016, 22:26
|
|
Registered User
 FRC #0180
|
|
Join Date: Feb 2013
Location: Florida
Posts: 11
|
|
|
Re: LifeCam USBCamera changing settings from Java
Quote:
Originally Posted by robert1356
I don't understand the HSL threshold error - I still see that, but it works fine. I think it's a sequencing bug (starting the threshold process before they provide a valid input image). You should see a message later in the traces that indicates that errors have been cleared and everything is normal.
What do you mean "publishing the contour report WITH IMAGES"?
I did see that sometimes I would have to restart the Outline Viewer to get it to see the GRIP changes. Network Table weirdness.
Step back and do things one step at a time. Make a GRIP pipeline that just pulls in the Lifecam, publish the video and the framerate, make sure that works. Add pieces and publish, etc.
BE CAREFUL ABOUT BANDWIDTH and CPU UTILIZATION.
320x240 definitely was slow on the roboRIO. (all we did was a HSL threshold and contour)
we dropped to 160x120. One problem with GRIP is that you can't get the camera to generate a smaller frame size, you have to do a resize in GRIP - this is wasteful and bad. Grip is pulling in a 720p or 640x480 image (not sure which) and they you resize in GRIP to something that you can operate on and transmit to the driver station. Resize is an expensive operation, especially if you do one of the interpolations.
You can check CPU Utilization by logging into the roboRIO (from a terminal / command line) and typing:
top
look at the java process with GRIP.
On the RPi I had the CPU pegged, GRIP was taking 2/3 processor, jpg-streamer was taking 1/3. I dropped the frame rate and frame size to get the CPU utilization down to about 80%
What we tried on the roboRIO ---
What I was originally doing was:
HSL threshold
publish frame rate right out of the source (that let me know that it was actually generating frames)
contour
contour filter
publish contour report
created a mask with original image and contours
published the mask
It worked fine when we would run manually and deploy robot code (basically during testing). But when I added the code to have the robot code launch GRIP, we started seeing memory issues and fairly regularly, it would crash the JVM, generating a core-dump file in the process. Core dump files are HUGE and it would eat up all the device storage space. When the robot code tried to relaunch, it would hang because it attempts to create some files (preferences for example) and it couldn't because the file system was out of space. This is a VERY bad situation - robot code won't run. When this happened, I had to manually delete the core-dump files to get robot code running again. This is why I switched to the Pi - too risky to have the robot code / JVM crash in the middle of a match.
|
This makes me nervous... I haven't filled the filesystem, but the executable crashes with out of memory. Didn't see a core. Before GRIP, I see only 25M free, so I know its close.
|