|
Post by CofC_HiBal on Jan 19, 2017 10:39:07 GMT -7
Hey ladies and gents, I need some help with an issue i've been chewing on...
So the ground station will not be in the same location as the launch site. Our launch site will be on a boat approx. 8 miles off shore. The Pi's must be "puttied" into to turn the cameras on and to set the stream up. This connection must also take pace over the same wifi network. Could it be possible to SSH into the pi's on the boat from the shore? Currently the option is to connect the pis to the computer before the boat launches from shore, but this will require bigger batteries on the payload. It would also mean the batteries would need to run for 4 hours. Could running the cameras for that period fill/max out the SD card? The major draw back of this method is that if connection is lost, there will be no way to reestablish connection. The boat would have to return to port and I would have to drive 30 miles back to get the connection again.
So, whats the best way to SSH into the pi's from long distances?
Big thanks!
|
|
|
Post by Wesley on Jan 19, 2017 11:44:51 GMT -7
Assuming you have line of sight with the payload from the boat, you should theoretically be able to initialize from the boat. There are problems with doing this though. The first is the quality of your signal. 30 miles is right on the edge of our range for these payloads when they are in flight. When its still on the ground, obstacles such as buildings and even trees start to interfere with signal if not block it. I would strongly recommend that you use a launch ground station in conjunction with the main ground station. The only items you will need for the launch ground station is a laptop with a power supply and a ubiquiti rocket modem with the small MIMO antennas.This will allow you to confirm that the payload is healthy before you launch and even start the stream. Once the stream is started in one SSH session it should run until you kill it or the payload dies. So the idea would be to initialize the payload from the launch sight with minimal ground station hardware and then pickup the signal from the boat once your in range and then connect to the previously initialized stream.
|
|
|
Post by leviw on Jan 21, 2017 18:11:26 GMT -7
If you disconnect from a ssh session, any programs you were running will stop. So if you start the streaming program from ground station 1 (GS1) and later pick up the stream using ground station 2 (GS2), as soon as GS1 leaves range or closes putty, GS2 should lose the stream even if it still has a strong signal from the payload.
There are lots of solutions to this, like running the streaming command in something like screen or tmux, as another user, as a startup script, or disowning the process before GS1 disconnects. (There are probably 99 other ways, too.)
Personally, I think automatically starting the stream on startup sounds like the best idea because it means you don't need to ssh into the pi at all. Just turn the key on and about a minute later the stream becomes available.
|
|
|
Post by CofC_HiBal on Feb 17, 2017 9:51:09 GMT -7
If you disconnect from a ssh session, any programs you were running will stop. So if you start the streaming program from ground station 1 (GS1) and later pick up the stream using ground station 2 (GS2), as soon as GS1 leaves range or closes putty, GS2 should lose the stream even if it still has a strong signal from the payload. There are lots of solutions to this, like running the streaming command in something like screen or tmux, as another user, as a startup script, or disowning the process before GS1 disconnects. (There are probably 99 other ways, too.) Personally, I think automatically starting the stream on startup sounds like the best idea because it means you don't need to ssh into the pi at all. Just turn the key on and about a minute later the stream becomes available. so you're saying that we can just make start up script on the payload pi's so that they will boot and begin a stream. As you mentioned, the we would never need to ssh into the pi, so they could never loose connection. This sounds like an ideal solution and will to negate a lot of issues people are having. in our case =it would eliminate the need for a second ground station. What additionally would we need to do on the ground station side to support the "hot start pi" on the payloads? as always, thanks so much for your advice.
|
|
|
Post by leviw on Feb 17, 2017 20:08:39 GMT -7
Maybe one of the more experienced linux people will chime in here, but this is what I know:
There are several ways to run scripts when the pi starts up. Last weekend I added the streaming script to /etc/rc.local, which runs as root when the pi starts up. This happens before any users have a chance to log on. I assumed it would work because I've done this with other scripts that I want to run on boot.
What I found was that cvlc does not like to run as root. That is VERY odd to me because normally programs fail if they need permissions they don't have - but root has permission to do anything! This was the first program that failed because it was running as root. I was working on something else and didn't have time to find a workaround that day but I think you could still run the script as root, through the pi user, by prefixing it with `su pi`
I haven't been able to try that myself yet. If I figure something out I'll post a reply here, or maybe someone else has solved this already.
|
|
|
Post by Skylar MSGC on Feb 24, 2017 15:42:09 GMT -7
There are a few spots that you can put scripts to run them on startup. I usually use rc.local(file) or init.d(directory) to run a script on startup. Here is a stack exchange answer that may help in this case. (Make sure to put & after your command so that it runs in the background) raspberrypi.stackexchange.com/questions/8734/execute-script-on-start-upThere are several ways to run a script, but some ways are a little more unreliable than others so I would recommend that you research the methods and do extensive testing to make sure that your plan works correctly so on game day everything runs smoothly.
|
|
|
Post by Skylar MSGC on Feb 24, 2017 15:45:04 GMT -7
If you have used the Raspberry Pi and are semi-comfortable with unix systems, I would recommend Exploring Raspberry Pi: Interfacing to the Real World with Embedded Linux by Derek Molloy. This book shows the user a decent amount of useful commands and methods to using a raspberry pi and/or general linux systems.
|
|
|
Post by CofC_HighBall on Apr 1, 2017 14:04:42 GMT -7
Good news, we were able to connect and get live video without putty!
we had issues getting our computer to communicate with the GS even though it was connected via Ethernet. So we ran some software updates, much needed updates at that, and then began playing with the internet protocols on the GSLaptop.
We set the IP on the computer (internet proto v4) to 192.168.1.101 (an ip within the range of our ground station modem) then set the subnet mask 255.255.255.0 (same for everyone) then set a default gateway to 192.168.1.100 (also within the ip range)
we then plugged in a monitor and keyboard directly into the Pi payload and started the stream directly within the pi; we are still working on the start up script to run stream.sh with a turn of the key. The pi then pushed the video out to our GS and we were able to view it in the VCL media player. We tested this in the field and found that once started, the keyboard and monitor could be unplugged and the stream would continue(this is a great last resort.) Additionally the best part is that even if the signal is temporarily lost, the VLC media player would automatically reestablish the connection! If the connect was lost for more than 5 minutes, simply restarting VLC would reestablish connection. Overall, I think this method is robust enough to be used on launch day and will continue to test it. I will post the start up script once we have figured it out, as mentioned, they can be a bit finicky.
in conclusion, i think this is an ideal solution to anyone who must launch in a different location than where the GS will be located.
|
|
|
Post by leviw on Apr 1, 2017 14:25:13 GMT -7
Oops, I forgot to update my post above. In case you're still looking for a way to start the stream automatically (just by turning the key), check out my post " Configure video system to stream automatically on startup." It's working well for us and doesn't require a keyboard or monitor on launch day. The ground station can be turned off or the network connection interrupted, without interrupting the stored video. The vlc stream will still be available when the connection resumes.
|
|
|
Post by Manu on Jun 12, 2017 8:40:45 GMT -7
Hi,
We tried to update the video streaming payload and came across an error while using SSH client. Pi did not get connected.
It says "flowsocketconnector: failed to connect to target address. Windows error 10060: a connection attempt failed because the connector party did not properly respond a period of time"
Please share your solutions.
Thanks in advance.
|
|
|
Post by Skylar MSGC on Jun 12, 2017 10:25:14 GMT -7
What are the settings that you are using to connect to the pi?
Would you be able to provide a screenshot of bitvise or whatever ssh client that you are using.
What are your ethernet settings, have you set a static ip for the ethernet?
|
|
|
Post by Manu on Jun 12, 2017 12:24:32 GMT -7
I'm unable to attach a screenshot here. Could you please share your email so that i can mail it to you.
We followed the exact instructions in the video. We set all the parameters same as suggested in the video.
We did not change any ethernet settings. We have not set a static ip. How do i do it?
|
|
|
Post by Skylar MSGC on Jun 12, 2017 14:34:43 GMT -7
You can create an account so that you can upload a picture. If you are a guest you can not upload a screenshot.
|
|
manoj
Novice Ballooner
Posts: 5
|
Post by manoj on Jun 12, 2017 15:17:42 GMT -7
Here is the screenshot of the error.
|
|
|
Post by Skylar MSGC on Jun 12, 2017 15:50:00 GMT -7
|
|