Closed jflalonde closed 9 years ago
jacenfox
commented
9 years ago The capturing automatically stopped without any operation. When I picked the camera back, camera and PI are still online, but the capturing didn't work. It stopped at 9:40am.
jflalonde
commented
9 years ago That’s too bad, but at 9:40pm all images must have been completely black for several hours!
Wait. This email was sent at 19:57 but you said it stopped at 9:40pm. That’s after you sent the email. What time did it actually stop?
On Oct 31, 2014, at 19:57 , jacenfox notifications@github.com wrote:
The capturing automatically stopped without any operation. When I picked the camera back, camera and PI are still online, but the capturing didn't work. It stopped at 9:40pm.
— Reply to this email directly or view it on GitHub https://github.com/lvsn/CameraNetwork/issues/13#issuecomment-61346357.
jacenfox
commented
9 years ago It is 9:40am this morning... Sorry for the mistake.
jflalonde
commented
9 years ago Oh no! :( That’s a lot of data lost…
On Oct 31, 2014, at 20:57 , jacenfox notifications@github.com wrote:
It is 9:40am this morning... Sorry for the mistake.
— Reply to this email directly or view it on GitHub https://github.com/lvsn/CameraNetwork/issues/13#issuecomment-61350559.
jacenfox
commented
9 years ago That would be better, if our system could send an email to us, once the capturing stopped. We can restart our capturing in case of losing data, especially for the un-stable objcam station.
When I setup the objCam, I was using the following command in my computer to detect whether the objcam is capturing. I hope this would help us. There must be other proper way to do this job.
if [ ssh pi@camnet2.duckdns.org "ps -ef | grep ros | grep -v grep | wc -l" -gt 0 ]
then
echo working
else
paly sounds
fi
soravux
commented
9 years ago That's some cool Bash-fu right here!
I am a bit curious as of it's scope, though: you meant that the ros service stops after a while? May it be the case because of some WiFi connection lost, and since the ros service couldn't talk to it's master, it stopped?
Could it be the same thing that happened with the skycam because of the DTI issues we had yesterday morning with some slob hijacking our network?
To fix both cases, It would be best if the roslaunch command were in some kind of loop (either a bash loop or some repetitive cron job), as when it stops, it would be relaunched. This would resume operation once the network connection is re-established. We'll have to be cautious though: It may fill up the drive space in launching logs.
But thing is, I though the ros service was started using this script which should automatically relaunch a new instance if it stopped, which should conceptually be similar as your code...
I'll check that on the skycam pi at the beginning of the week.
jacenfox
commented
9 years ago The ROS stops in objcam pi. When I start the capturing I won't do any thing in the pi, everything is stable except WiFi, so I thought WiFi is the reason why the capturing stops. For the skycam, I really wonder why it stopped yesterday.
jflalonde
commented
9 years ago Good point Yannick. Jinsong, we had issues with someone plugging in our network illegally yesterday. That could've explained the network issues.
Sent from my iPhone
On Nov 1, 2014, at 12:59, jacenfox notifications@github.com wrote:
The ROS stops in objcam pi. When I start the capturing I won't do any thing in the pi, everything is stable except WiFi, so I thought WiFi is the reason why the capturing stops. For the skycam, I really wonder why it stopped yesterday.
— Reply to this email directly or view it on GitHub.
soravux
commented
9 years ago Closing since we have a good explanation to what happens. Maybe open a new ticket for the system resilience to network failures, if the need arise.
When watching the skyCam that should be running, it appears as "idle". Check with Jinsong.