Closed alexblack closed 8 years ago
I'm still experiencing this often, I can reproduce it by pointing the drone (and the GoPro) at the window (a source of bright light). I am wondering if the GoPro is damaged?
This is happening on my brand new (second) Solo with another brand new (second) GoPro 4 Silver
root@3dr_solo:~/ddc/examples/opencv# python SoloCamera.py
Capturing 10 images...
12.7108595118
21.2067023288
19.7777358633
56.5064464413
33.2158955921
36.2951514784
62.803084525
42.1957927989
45.057408044
37.115435327
38.3598467181
28.8849986571
27.119338424
55.1149656378
1.73423547838
VIDIOC_DQBUF error 62, Timer expired
Traceback (most recent call last):
File "SoloCamera.py", line 86, in <module>
ret, frame = cam.read()
File "SoloCamera.py", line 65, in read
check(solocam.solocam_read_frame(self.ctx, byref(bufp)))
File "SoloCamera.py", line 13, in check
raise OSError("Error in solocam C call (see stderr)")
OSError: Error in solocam C call (see stderr)
Exception AttributeError: "'NoneType' object has no attribute 'solocam_close'" in <bound method SoloCamera.__del__ of <__main__.SoloCamera object at 0x246b1b0>> ignored
root@3dr_solo:~/ddc/examples/opencv#
I ran root@3dr_solo:/var/log# tail -f kern.log
while reproducing the problem, and I see this output that looks related:
Apr 9 01:10:21 3dr_solo user.debug kernel: imx-ipuv3 2400000.ipu: CSI stop timeout - -44 * 10ms
Apr 9 01:10:26 3dr_solo user.debug kernel: imx-ipuv3 2400000.ipu: CSI_SENS_CONF = 0x00000950
Apr 9 01:10:26 3dr_solo user.debug kernel: imx-ipuv3 2400000.ipu: CSI_ACT_FRM_SIZE = 0x02CF04FF
Apr 9 01:10:26 3dr_solo user.warn kernel: alloc_contig_range test_pages_isolated(1cd00, 1ce52) failed
Apr 9 01:11:28 3dr_solo user.debug kernel: imx-ipuv3 2400000.ipu: CSI stop timeout - -44 * 10ms
Apr 9 01:11:28 3dr_solo user.debug kernel: imx-ipuv3 2400000.ipu: CSI_SENS_CONF = 0x00000950
Apr 9 01:11:28 3dr_solo user.debug kernel: imx-ipuv3 2400000.ipu: CSI_ACT_FRM_SIZE = 0x02CF04FF
Apr 9 01:11:38 3dr_solo user.err kernel: ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0
Solved this! The fix was to modify a line in /etc/inittab
to stop vidlaunch
from running on startup, then reboot the drone.
Our theory is that
vidlaunch
initializes the video system before us, giving us errors when we start itvidlaunch
is reactivated when the drone is moving, causing random timeouts in our video feedConfirm the fix by running lsmod
, expect mxc_v4l2_capture 22362 1
(Used by: 1, before the fix it is 3)
root@3dr_solo:~/ddc# lsmod
Module Size Used by
mxc_v4l2_capture 22362 1
ipu_bg_overlay_sdc 3749 1 mxc_v4l2_capture
ipu_still 1663 1 mxc_v4l2_capture
ipu_prp_enc 4397 1 mxc_v4l2_capture
ipu_csi_enc 2593 1 mxc_v4l2_capture
ipu_fg_overlay_sdc 4625 1 mxc_v4l2_capture
cdc_acm 14295 0
ath9k 94754 0
ath9k_common 19864 1 ath9k
ath9k_hw 363749 2 ath9k_common,ath9k
ath 17786 3 ath9k_common,ath9k,ath9k_hw
mac80211 358702 1 ath9k
cfg80211 209856 4 ath,ath9k_common,ath9k,mac80211
adv7610_video 5327 0
compat 16232 5 cfg80211,ath9k_common,ath9k,mac80211,ath9k_hw
usb_f_acm 4037 1
u_serial 7979 3 usb_f_acm
g_acm_ms 18540 0
libcomposite 26342 2 usb_f_acm,g_acm_ms
Sometimes when using SoloCamera from Python the camera component seems to crash with this error.