Closed nikhilnagaraj closed 1 year ago
Hi @nikhilnagaraj, I just tried your script and have not yet seen any of these errors you are listing. Do you have an idea of how long the script has to run before you see the issues?
The wait_for_frame()
is not going to perform well in a while True
loop but I would expect that with the sleep()
you put in there it should be sufficient to not run into any delay.
Are you able to give us more details on your network connection? Which ethernet port are you using (it looks like eth0 from the json config but just want to confirm)? Are you connected through a router, wifi, etc?
Hi @lola-masson It usually occurs within the first 20-25 calls. I suspected that it was a network issue, but the thrown errors made me think otherwise.
Regarding the network connection, I am using eth0
and the VPU is on the same network as I am (not connected directly). I am able to ping the VPU and receive frames semi-regularly, so I am unsure if this is an issue with the network. However, in a few days, I will be testing this with a physical cable connecting the VPU to my device (or by pushing a docker image to the VPU) so I should have better feedback.
Might the issue of having to reset the RGB imagers to CONF and then RUN as listed here be related to this? I have definitely seen that I have to reset the RGB imagers to be able to receive any data if the delay between subsequent frame requests is long enough.
(Similar issue with the distance imagers, where changing the mode to standard_range2m
and then back to standard_range4m
seems to help).
It seems like this might be a bug on our end. The fact that you have to "restart" each imager by switching is CONF->RUN or standard_range2m->standard_range4m is strange, this should not happen and we are investigating. We will let you know as soon as we find the issue and provide a solution.
@lola-masson Any updates on this?
@nikhilnagaraj can you please contact us via email at: support.robotics@ifm.com
We tried to reach you via your linked email address on your profile on GitHub, but the emails can't be delivered.
@nikhilnagaraj can you please contact us via email at: support.robotics@ifm.com
We tried to reach you via your linked email address on your profile on GitHub, but the emails can't be delivered.
Done! :)
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
Describe the bug I am using the O3R225 - OVP800 combination to capture RGB and Pointcloud data. Ideally, I would like to capture images at random points in time (based on external inputs). However, the
wait_for_frame
function seems to be highly unreliable. Some of the errors that I have seen while invoking this function are:importlib._bootstrap.Error: No such file or directory
importlib._bootstrap.Error: Invalid argument
importlib._bootstrap.Error: Connection reset by peer
These errors occur more often while I try to capture data from the 3D port (they occur less frequently on the 2D port).
Expected behavior
wait_for_frame()
should reliably return a frame.Output/Screenshots If applicable, add console output and/or screenshots to help explain your problem.
To Reproduce
Configuration/Environment (please complete the following information):
WSL 2, Ubuntu 20.04.4 LTS
3.10.4
1.0.0
Camera Configuration
Additional context Add any other context about the problem here.