We just complete the OPENROV 2.4. Everything seems to run well now during dry test except screen tends to freeze constantly when turn on motors using arrow keys.help!Eric
I don't know of any direct correlation between driving the motors and video issues. I have run in to issues in the past with spotty connectivity due to poor wiring of the medialink adapters. Just to eliminate connectivity, try setting up an ongoing ping between your computer and the ROV while experiencing the issue. The round trip times *should* be 2-3ms constantly. When I have had problems before I would see dropped packets or spikes to 70ms.
Also, check the CPU being used by the browser on your system. Older computers have had issues that go away when running a faster computer.
Final easy check. Try dialing back the video size to "SVGA" or "VGA" in the config.js file and powercycle. Perhaps less bits going through the stack will ultimately remove whichever bottleneck is triggering stability issues.
There are two+ potential issues that I am aware of that you (or anyone else with some spare cycles!) might look in to.
1) At least on the newer image running the latest Ubuntu image referred to in the wiki, I see that the Watchdog timer will spin up to a 100% cpu for a moment, that corresponds with video having 1-2s pause in delivery. I've done some initial scouring of the internet, and it might be as simple as requiring an Ubuntu upgrade. It might instead require some fine tuning like moving the Watchdog in to real-time mode. If any linux guru's are handy and want to dive in, that will hopefully point you to some places to look. Apparently the default install does not have the Watchdog generating a log file anywhere I can find, so simply ensuring it is logging might help point to what needs to be fixed.
2) There might be an issue with the browser displaying mjpeg video smoothly. It seems that you can sometimes run for a while and see what looks like a frame rate drop to 3fps. If you refresh the browser it seems to go away. Now refreshing does a couple things, it drops the socket.io connections from the browser to the beagle behind the scenses as well. Regardless normal 15fps video seems to return for a while after that. If someone wants to play with trying a plugin (flash, vlc) in the browser window instead of the direct mjpeg playback in the browser I am curious if you see this issue clear up at all.
3) There is some odd correlation between the contrast of the scene in the video and the CPU used by the beagle. Not sure the impact today, but it might be tied to issue #1 above. If you throw a towel over the ROV you will see 20%+ less CPU than leaving it exposed to a scene with bright spots. The CPU is almost all in the KWorker process. Any camera/linux guru's that can explain the correlation?
How are you powering the rov? with batteries? with a powersupply? what kind of batteries? how many amps can the powersupply deliver?
are you sure you've got enough power available? does the rov work if you lower the throttle setting to 1 or 2?
i'm suspecting that the whole rov reboots because of undervoltage when driving the motors.
Thanks. I will follow your tips.
Thanks. Will look into it.
I also need help with video freeze trouble.
Since I loaded the new image (OpenROV-05-09-2013.img) I have video and game pad problems. I did not update the Arduino code (Arduino-1.0.4) after loading the new image. Do I need to do so?
The video image freezes when the light levels are at normal room brightness,and also the exposure gets over exposed on the frozen frame, but can vary from normal exposure to a whiteout. When I turn off the room lights and just use the OpenROV's Leds the video camera image stops freezing most of the time and exposure appears good.
I have tried 2 different computers (see at bottom) and I use Chrome as the browser:
Using the Toshiba Qosmio Lap Top (the one I plan to use in the field) the video in normal room light appears to run at ~3 fps and will have some freeze frames when lighting is just right. I move my hand in front of the camera (6-10 inches and backlit) to get freeze frames. I think it freezes just under the right lighting conditions. Cockpit displayed voltage is 12.4v, displayed current is .835A with no LEDs or motors on. Cockpit keeps changing the time, voltage, current and CPU usage when a frame is frozen. The CPU usage may drop to as low as 4% during a frozen frame. The current also will drop a little. Most of the time if I move my hand the frame will unstick and start running at ~3 fps and exposure will look good. If I move my hand in
the same area where it froze it will freeze and unfreeze until the lighting changes enough.
With the room lights off and the LEDs set to 10% the video does not appear freeze and it runs at ~3fps. If I turn the LEDs up to 100% I can get it to freeze some times by waving my hand close to the camera (6 inches).
Using the HP Pavilion Elite HPE the video in normal room light appears to run at ~10 fps and will have some freeze frames when lighting is just right. I move my hand in front of the camera (6-10 inches and backlit) to get freeze frames. I think it freezes just under the right lighting conditions. Cockpit displayed voltage is 12.4v, displayed current is .835A with no LEDs or
motors on. Cockpit keeps changing the time, voltage, current and CPU usage when a frame is frozen. The CPU usage may drop to as low as 4% during a frozen frame. The current also will drop a little. Most of the time if I move my hand the frame will unstick and start running at ~10 fps and exposure will look good. If I move my hand in the same area where it froze it will freeze and unfreeze until the lighting changes enough.
With the room lights off and the LEDs set to 10% the video rearly freezes if I wave my hand close to the camera (6 inches) and it runs at ~5fps. If I turn the LEDs up to 100% I can get it to freeze some times by waving my hand close to the camera (8 inches)
I did not have video freeze when using an older image (I think it was from around 5/2013).. But when running this older image the video from time to time would turn to a small icon in the upper left corner of the video window (see Post by Stefan Lagner on November 12, 2013 at 5:00am) and I would have to refresh the cockpit from the browser to get the video image back.
Also now when I use my game pad the two thrust motors will not stop when the joy stick is in the center position. I have to move it slightly to the right to stop the motors. I have calibrated the game pad many times but the motors still run when the joy stick is centered. This did not happen with the older image.
My OpenROV serial # 315.
Computer used for the tests:
Toshiba Qosmio Lap Top with Intel Pentium M processer 1.86GHz with 1.0 GB of RAM
running Microsoft Windows XP Media Center Edition Version 2002, Service Pack 3
HP Pavilion Elite HPE model HPE-447c, AMD Phenom II X6 1045T processer, 2.700GHz 6 Cores, 8.00GB of RAM running Microsoft Windows 7 Home Premium Version 6.1.7601, Service Pack 1 Build 7601
Brian please see my reply to Eric.
We finally traced the problem to voltage upsurge. The screen froze is due the BB shut down to protect itself. It reboots itself after a while. We brought the problem to many computer technicians and finally nailed it down.
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.
Was there a solution to the voltage surge?