Video freezing: ROV 2.5 with beta software

#1

I finished putting together OpenROV 2.5 #517 in early December, but I didn't get around to putting in the water until now. I tested it in a pool, and every is working well, except the camera is freezing very often. It is running the 2.5 beta software (https://github.com/OpenROV/openrov-software/releases/tag/v2.5.0-Beta).

I can't really tell if this is a hardware or a software problem, but the video freezes when the ROV is angled slightly upwards while floating on the surface of the water. It also freezes when placed on a surface (out of the water) and tilted slightly upwards. It seems to freeze when there is large contrast and the frozen frame was often overexposed.

I also tried connecting to the video stream using VLC, and if I tried to connect while the video was frozen, it simply buffered. This makes me think the camera could be turning off or there may be a mechanical connection problem.

Other people have suggested changing the streaming resolution, but I don't believe this is the problem because when it freezes, it stays frozen until I move the ROV or wave my hand very close to the camera. I think if the problem was a bottleneck, the video would simply lag or freeze for a few seconds.

Another suggestion is that the wrapped USB camera cord is getting interference from the LED wires. However, the video still freezes if the LEDs are off.

It may be a mechanical wire connection problem, simply because it seems that the placement of the ROV has to do with the freezing. The video does not freeze if I twist and bend where the wires enter the e-chassis, but it could be at another location. The video also does not freeze if I am holding the ROV and moving it around. When the video freezes, everything else in the cockpit still updates and ping is still around 3-4 ms. CPU usage stays around 30-50%

Any thoughts/suggestions?

#2

There is an ongoing issue with camera in high contrast situations pausing. If your in the situation, it would help it you could look at the /var/logs/kernel.log (or whatever the kernel log is called) and see if there are messages regarding issues with the I2c connectivity with the power management chip and notes of failure to change clock speed. The last unit I was holding that was having this problem was logging these errors, and upon reboot the the errors went away... as did the video pausing.

-B

#3

The log is /var/log/kern.log. It is a pretty long file (5105 lines) with all lines from Nov 21. A lot of the lines are even from the same second. I'm not sure if the clock was ever set, so I don't know if that means anything. Are there specific keywords I should be searching for?

#4

grep for 'i2c' or 'power' if you can.

#5

These are the first couple of search results for each keyword. As you can see, the lines start repeating.

for 'i2c':

Nov 21 22:04:01 OpenROV kernel: [ 0.156918] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz

Nov 21 22:04:01 OpenROV kernel: [ 0.158558] input: tps65217_pwr_but as /devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/input/input0

Nov 21 22:04:01 OpenROV kernel: [ 0.170482] omap_i2c 44e0b000.i2c: unable to select pin group
Nov 21 22:04:01 OpenROV kernel: [ 0.171286] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz
Nov 21 22:04:01 OpenROV kernel: [ 0.173898] omap_i2c 4819c000.i2c: unable to select pin group

Nov 21 22:04:01 OpenROV kernel: [ 2.539211] i2c /dev entries driver

Nov 21 22:05:02 OpenROV kernel: [ 0.156943] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
Nov 21 22:05:02 OpenROV kernel: [ 0.158579] input: tps65217_pwr_but as /devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/input/input0

Nov 21 22:05:02 OpenROV kernel: [ 0.170486] omap_i2c 44e0b000.i2c: unable to select pin group
Nov 21 22:05:02 OpenROV kernel: [ 0.171290] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz
Nov 21 22:05:02 OpenROV kernel: [ 0.173877] omap_i2c 4819c000.i2c: unable to select pin group

Nov 21 22:05:02 OpenROV kernel: [ 2.539186] i2c /dev entries driver

for 'power':

Nov 21 22:04:01 OpenROV kernel: [ 2.267658] musb-hdrc musb-hdrc.0.auto: *** power=250

Nov 21 22:04:01 OpenROV kernel: [ 2.324953] musb-hdrc musb-hdrc.1.auto: *** power=250

Nov 21 22:04:01 OpenROV kernel: [ 2.509746] hub 1-0:1.0: individual port power switching

Nov 21 22:04:01 OpenROV kernel: [ 2.509818] hub 1-0:1.0: power on to power good time: 10ms
Nov 21 22:04:01 OpenROV kernel: [ 2.509879] hub 1-0:1.0: local power source is good
Nov 21 22:04:01 OpenROV kernel: [ 2.509996] hub 1-0:1.0: enabling power on all ports

Nov 21 22:04:01 OpenROV kernel: [ 2.964562] tilcdc 4830e000.fb: No power control GPIO

Nov 21 22:04:07 OpenROV kernel: [ 14.844261] hub 2-0:1.0: individual port power switching

Nov 21 22:04:07 OpenROV kernel: [ 14.844302] hub 2-0:1.0: power on to power good time: 10ms
Nov 21 22:04:07 OpenROV kernel: [ 14.844330] hub 2-0:1.0: local power source is good
Nov 21 22:04:07 OpenROV kernel: [ 14.844420] hub 2-0:1.0: enabling power on all ports

Should I look further into any of these lines? (Also, if there's a way to format this better, let me know.)

#6

Is there any progress or are there possible solutions to this problem? If you would like me to try anything on my OpenROV, just let me know.

Right now, my ROV is pretty much unusable because the cockpit video is so unreliable.

#7

Hey Franton,

Sorry for going dark for so long. I'll fire my ROV up tonight and compare. The current Beta image is in sore need for a refresh as there are significant performance improvements on the browser that can also mess with video. It is possible if the computer you are running on is not fairly powerful/recent that you can max the cpu core being used by the browser that kills the video rendering as well. Again, fixed in more recent software and a separate issue from the pausing that happens from the beagle side of the equation that your helping me troubleshoot through the log files.

-Brian

#8

Hey Franton,

Can you try logging in to the beaglebone and issuing the following command when you are having video freezing issues to see if it makes any difference. This assumes that you are not running above 90% on the chrome (or other browser) process:

sudo /usr/bin/cpufreq-set -g performance

#9

Brian,

Sorry for not responding sooner, but I booted the beaglebone up and I could not get the camera to freeze, even in high contrast situations. I was going to test it in the pool again to make sure that nothing else causes the video to freeze, but the pool closed due to mechanical problems. If freezing does occur, I will try the suggested command.

Thanks,

Franton

#10

Hi Brian

I just finished my 2.6 build and tested in the pool today.

I was getting the Issue with Video Freeze, even on deck It seemed to happen every time in one direction when I spun it around and I suspect it was due to lighting. Has there been a fix for this yet as I will be doing more testing tomorrow morning in the pool. I saw your notes on capturing the log entries and I will try to do that when it happens. I am using the 2.5 Stable image with the changes made for IMU in AConfig.h Everything else seems to work from the cockpit when the freeze occurs and can still drive it and turn lights on and off, the Telemetry seems to still work ok. Refreshing the Browser with f5 seems to get it back after a few try's but will freeze again.

#11

I will try changing the video to SVGA in the config.js file and see if that makes a difference.

#12

After changing the Video to SVGA I am happy to report that everything worked perfectly on today's trial run in the pool. I am very happy with the new 2.6 Controller and motor thrusters what a fun day. some Video clips to follow shortly.

#13

Pool Test Video

Part 1
https://www.youtube.com/watch?v=_c6nONCElQY&feature=youtube_gdata

Part 2
https://www.youtube.com/watch?v=Gwwtnd2YDME&feature=youtube_gdata

#14

Hi David

I couldn’t help but notice how clear the video was and the detail. Which camara were you using and was this video sent up the teather

Dave Hinton

#15

Hi Dave

The USB camera is the same as what is used on the OpenROV, Genius F100

The Tether I was using had 500' of 22awg wire.

The Video was switched to SVGA in the config.js file to reduce the freezing that I was getting on previous tests.

#16

Switching to SVGA also got rid of the video freezing problem for me. Is HD video too much for chrome?