Darwin Camera: EMI?
Darwin Camera: EMI?
by dfreelan
Thu Jan 09, 2014 1:50 am
Our team is experiencing an issue where the camera likes to cut off after 1-5 minutes of walking around.
We have reason to believe this could be an EMI issue, both because of the error message below:
and also because the cable in the camera is completely un-shielded.
I've only been able to fix the camera by rebooting the robot, or plugging the camera out and back in.
When turning the camera off with rmmod and turning back on with modprobe, and that doesnt work. After modprobe, dmesg simply tells me it cannot connect to the device.
In total, here is my evidence I have to make a conclusion with:
1. That silly kernel message
2. Cannot replicate this bug with all the software running on the robot and the servos manually turned off (right button)
3. Cannot replicate bug with only cognition going (this is the program which queries the camera)
4. I have never been able to recreate the bug while holding the robot (putting less strain on the servos)
5. (this needs more testing, could just be happenstance) appears to happen faster when the battery is low. seems to last on average longer when a newly charged battery is in. So this might be a voltage problem?
6. The only time I replicated this when the robot has been plugged into the wall has been when I also had the battery plugged in.
7. never been able to replicate this with only the AC in
Has anybody encountered something similar? find out it was something else? Any hardware fixes?
We have reason to believe this could be an EMI issue, both because of the error message below:
- Code: Select all
Jan 7 22:38:27 darwin51 kernel: [ 3983.828178] hub 3-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
Jan 7 22:38:27 darwin51 kernel: [ 3984.036153] usb 3-2: USB disconnect, device number 2
and also because the cable in the camera is completely un-shielded.
I've only been able to fix the camera by rebooting the robot, or plugging the camera out and back in.
When turning the camera off with rmmod and turning back on with modprobe, and that doesnt work. After modprobe, dmesg simply tells me it cannot connect to the device.
In total, here is my evidence I have to make a conclusion with:
1. That silly kernel message
2. Cannot replicate this bug with all the software running on the robot and the servos manually turned off (right button)
3. Cannot replicate bug with only cognition going (this is the program which queries the camera)
4. I have never been able to recreate the bug while holding the robot (putting less strain on the servos)
5. (this needs more testing, could just be happenstance) appears to happen faster when the battery is low. seems to last on average longer when a newly charged battery is in. So this might be a voltage problem?
6. The only time I replicated this when the robot has been plugged into the wall has been when I also had the battery plugged in.
7. never been able to replicate this with only the AC in
Has anybody encountered something similar? find out it was something else? Any hardware fixes?
