Where are the videos saved?

[Chris-HCC(KY)]

I know this may sound like a basic or crazy question but I have looked everywhere that I know of and cannot find the video file from the camera. Is it being saved? If so where can I find it? 

[Wesley]

They are saved inside the ubiquity folder on the pi SD card. The easiest way to get them off is to SSH into the pi and copy them off that way. I'm actually making a guide to get the files off with 3rd party software. I'll report back when I'm finished putting it together. Stay tuned!

[Skylar MSGC]

The code that runs the video stream saves the video to the same folder that it is run from. To be exact its the part of the code that is:
| tee -a video_name_here.h264 |

This command makes a copy of what is being seen on the camera and saves it to the location that the shell command file is run at. For most people this will be the /home/pi/Ubiquiti_Video folder. If you want to pull files from the Pi I would recommend looking into either Winscp (what we used here in Montana at the workshop) or FileZilla is another good program. Both of these are for Windows and FileZilla can also be installed on Mac(OSX). Otherwise Wesley could post a tutorial on how to get the video from the Pi, and the method he uses might be a little different but im sure works.

[Wesley]

Link to the PDF version of the Rev A guide. Feel free save it! Let me know how you guys like it or if there are any errors I can correct. Thanks!

spacegrant.colorado.edu/images/Eclipse/Guides/File-Transfer-How-To.pdf

[Patrick]

On the pdf for obtaining files from the pi it says there will be a guide on how to set pi up for Ad-Hoc, is that up? I assume thats the issue I'm having. The light blinks blue for a few seconds at start up then stops. I can see a wi-fi named MBUA which is what the uBiquiti is labeled but i cannot connect to it.

[peheelan]

Also is there a way to save video straight to the SD card?

[Skylar MSGC]

Well since your Raspberry Pi runs its operating system off the SD card, when you save it to the file specified in the tee -a "filename.h264" it is saved directy to the SD card.

[irowe]

If the stream ends due to low voltage from the batteries, or the connection is interrupted, is the file still saved? I've heard before that the pi does not like that very much.

[leviw]

If the pi shuts down while recording, the file will still be there but won't be properly terminated. We have made dozens of videos this way and have never had a problem, but it's not ideal.

You can insert a command to stop the video after a certain amount of time, but we haven't done that because we don't want to lose anything if the flight accidentally goes too long. Using something like a 4 hour safety net would probably be a good idea, but we haven't bothered.

If you start the stream using putty and the default commands from MSU, and you lose connection to the payload, the video will stop recording after a few minutes. Essentially, any programs associated with your login session END when your login session ends.

There are lots of ways to solve this problem and MSU has been talking about posting an updated version of the code. If you don't want to wait, here are instructions that will fix this problem by running the stream automatically on startup, which also means you don't need to use putty to connect to the pi.  You can just turn it on and connect to the stream with VLC.  If you lose connection, the video continues to record until the pi turns off.

[irowe]

Okay I will look into implementing the automatic stream. You mentioned that you run the stream through VLC. While we have done that to view the stream for testing, apparently if the stream runs for long enough it quits and the SD card is corrupted. Being a newer member to the team, I haven't actually observed this, but I've heard elsewhere that there are VLC codec issues. If we want to run a stream for full flight, what is your current solution for streaming/broadcasting? Excuse me if I am retreading old information, but we actually haven't run a stream for a flight in a while.

[leviw]

Using the steps in that link, we are able to turn on the payload, wait about 2-3 minutes for the pi to boot up and the two ubiquity modems to connect, then just open VLC player and open the stream normally. Basically it just cuts out all of the putty steps.

Because we don't use putty, the stream doesn't rely on our network connection, and as the balloon flies away or leaves our range, the video just continues recording.

About 2 weeks ago we had a test flight that ended quite high up in a tree. We couldn't get to it for about 8 hours and when we had, the battery had died. We took it home, pulled the sd card, loaded it into my linux laptop and pulled off the video file. It recorded the ~45 minute flight (we lost connection when our cutdown timer accidentally went off too soon) and about 5 hours looking at the ground afterwards. Then the video ends, presumably when the battery died.  We've been using this method during practice runs for about 6 months and haven't corrupted an sd card yet, but I won't say it's impossible.

If you're curious, you can also do some ground tests to better understand the current system, and my suggested solution.  It's easy to undo my solution if you find that you don't like it.

Under the current system, try starting the stream using putty, then turn off the ground station.  If you look at the payload camera there should be a little red light indicating the camera is being used.  After ~5-10 minutes of turning off the ubiquity modem, that light should turn off.  That means your linux session timed out and cancelled any programs you started in putty, which includes the stream.  If you watch the video from the pi, you should be able to see yourself turn off the ground station, but soon afterwards the video will just end.

Then try implementing my solution and compare.  The video shouldn't stop, you should be able to wait awhile, then turn on the ground ubiquity modem and reconnect to the stream.  The video should keep recording normally until you either kill the process, or turn off the pi.  Oh, if you decide you want to stop the stream without turning off the pi, you should be able to do that with putty and the linux command: sudo pkill raspivid

Anyway, that link is just one of many solutions to this particular problem.  I think it's a good solution, but maybe I'm biased.