@jcasman you can also replicate the same test I did on the Z1 with the SC2.
It’s theoretically problem that the SC2 is responding differently. change the anme to theta_endurance_test.sh and change the comments at the top if the SC2 is successful
Update February 20, 2021 - SC2 Failed Script Test
The above 500 picture endurance test using
/osc/status failed for me with the SC2. The camera locks up.
@jcasman, can you run the script above on the SC2 and help me test it? I tried to increase the delay to 2 seconds and the camera still locks up.
I’m going to try a longer delay first and then if the camera still locks up, I am going to use
The SC2 camera only locks up when many shots are taken in rapid sequence.
This is the test. I ran it on a Raspberry Pi. You may have better results from WSL2 or a mobile phone. Keep trying different scenarios.
Update February 20, 2021 late morning - SC2 Wi-Fi Stability Issue
@jcasman when you publish the tests with
takePicture, please start a new topic. This topic originally started with
startCapture. To make the tests on
takePicture with the SC2 easier to find, start a new topic called, ‘SC2 takePicture repeat shots and camera status’ or something similar.
I just tried another test with the robot on the SC2 and had to replace the camera with a THETA V. I was not able to establish a stable Wi-Fi connection for hundreds of sequential shots between the SC2 and the RPi4. This may be due to the Wi-Fi chipset and use of 2.4GHz. There may be Wi-Fi interface in my office. I’m not sure. I think we can get the SC2 to work reliably for long-term sequential use, but at the moment, it is showing unexpected behavior under stress tests. We should document the test equipment and script when the test is done.
Update February 21, 2021 - SC2 working with long delays between shots
I’m building out my test results at the link below.
I’m consistently getting the output like this:
waiting 5 seconds for the next shot
Test of taking picture and then checking to see if picture is ready for download
The status ID is 8844
Elapsed time: 0 seconds. State: inProgress
Elapsed time: 1 seconds. State: inProgress
Elapsed time: 2 seconds. State: inProgress
Elapsed time: 3 seconds. State: inProgress
Elapsed time: 4 seconds. State: inProgress
Elapsed time: 5 seconds. State: inProgress
Elapsed time: 6 seconds. State: inProgress
Elapsed time: 7 seconds. State: inProgress
Elapsed time: 8 seconds. State: done
picture ready for download at http://192.168.1.1/files/thetasc26c21a247d9055838792bad
With a non-HDR filter, the picture consistently takes 8 seconds to be ready for the next picture.
Thus, you can create a fake progress bar by using the elapsed time.
If I don’t insert a delay between shots, I can’t accurately check the
inProgress as the camera locks up.
Test with 5 second delay after
done is received
I’m redoing the test again with a 5 second delay, 200 shots. This is a delay of 5 seconds after I receive the status as
done. This means that I am waiting a total of 13 seconds between shots, not including the download time. In this test, I am not downloading the image after each shot.
Result with 5 second delay: test failed
Test with 8 second delay after done is received
Redoing test with 8 second delay. This is 8 second after I receive the
done status. Time between shots is at least 16 seconds.