nikivanov / watney

Watney is a low-cost 3D-printable FPV rover
GNU General Public License v3.0
378 stars 39 forks source link

Rover Access via DDNS #18

Closed paalwilliams closed 4 years ago

paalwilliams commented 4 years ago

Hi @nikivanov ,

I am trying to set up the Watney for remote access, however, I am having issues with requests to the Janus Server (hosted on port 8089).

I am wanting the access to be as easy as possible, with the video feed and controls embedded onto another site.

I've tried a few things so far:

Zerotier: Works well, but with the user restrictions I will run into the limit, plus it adds setup for the end user, which is not preferred.

I have forwarded ports 5000, 8088, 8089, 7088, and 53, and adding DDNS, hoping that would solve the problem. With this configuration, it doesn't change anything on the local network access. However, I am unable to access the video feed from the rover remotely. With the DDNS and port forwarding, I was still able to load the index.html, and the heartbeat requests are going through, so I'm getting the SSID, latency, quality, and CPU, and can also control the rover, but do not have access to the video feed.

However, in both of these circumstances, I am still getting the same errors. (See images below). Error_3 Error_1 Error_2

The best I can tell, these errors seem to be related to CORS headers. I have not found a way to configure those in Janus. Any advice or related information would be greatly appreciated.

nikivanov commented 4 years ago

Hey Paal!

You may be better off asking someone on the Janus team. From what I remember, Janus also supports commands over websockets. You might want to enable websockets on the server and change how the javascript client connects to the server to use websockets. That should solve the CORS problem, but I've never tried it, so YMMV.

Please post your Watney on Thingiverse when you get a second - I love seeing them in the wild.

Nik

nikonowicz commented 4 years ago

Hey Nik -

Thanks for the reply! Paal and I are working on this together. As an aside, I will drop an image of the build on Thingiverse today.

Looking at the errors we're receiving, it seems that maybe we just need to drop in some code that the CORS Preflight is looking for. I believe we understand what code it's looking for, but we aren't sure where it should go. We're also looking into websockets and some related questions with the Janus team per your recommendation. That being said, do you have any theories as to what 'requested resource' within Watney it's referencing in the second screenshot when it says "No 'Access-Control-Allow-Origin' header is present on the requested resource" ?

Regardless, thanks for building Watney! It's a blast to use.

Drew

nikivanov commented 4 years ago

I think CORS is kicking in because Watney's interface is on port 5000 and Janus 8089. Going from localhost:5000 to localhost:8089 is considered cross-origin by your browser. I'm not strong on CORS, but I think you need to have both client and server to agree on allowing CORS. In my opinion, it'd be simpler to just switch to websockets for Janus API - the problem should go away on its own.

nikonowicz commented 4 years ago

I see - we will look into it. If we find a coherent solution (with either CORS or websockets) I will loop back around to share it with you and anyone else interested in using Watney in this way.

Thanks for your time!

nikivanov commented 4 years ago

Please post your Watney on Thingiverse when you get a chance!

nikonowicz commented 4 years ago

Thanks for the reminder - here it is! https://www.thingiverse.com/make:794163

nikivanov commented 4 years ago

Thanks! Love the all-white

nikonowicz commented 4 years ago

Hi @nikivanov -

Just a follow up. We were able to get this working. By updating the Janus configuration files to point to a TURN server that we hosted on EC2, we were able to allow users to communicate with the rover remotely using a DDNS. So the great news is that this is certainly possible, even if the Rover and Janus server are sitting behind a NAT. Just takes the right configuration.

As for CORS - in our case this error was appearing because of a bad port forward configuration. When we only forwarded the two ports necessary to themselves 5000:5000 and 8089:8089, this was fixed.

Thanks again for your replies before! Hopefully if anyone wants to do this in the future, this might help.

EDIT: We will be putting a little better documentation of what we did on my forked copy of Watney in the coming days for those interested.

nikivanov commented 4 years ago

Awesome! Please let me know when documentation is ready and I'll merge it into my repo as well. Cheers!

eerison commented 8 months ago

Hey @nikonowicz thanks for sharing your results.

Could you list here what changes did you do and what tun server have you used please