Hey, oops you’re right sorry - mavlink-router is the default mavlink proxy. mavlink-router doesn’t have a console/‘screen’ available - it’s a simple proxy. From your
maverick status output - your FC proxy is still running mavlink-router (mavlink-router@fc).
If you specifically want mavproxy, and looks like you’ve specified that in localconf.json, then you need to run a
maverick configure to activate it - switch mavlink-router to mavproxy.
If you don’t specifically want mavproxy for your main FC proxy, I would just leave mavlink-router as is - it’s much lighter weight and simpler.
If you do activate it, then you can access mavproxy console through screen, but you won’t get any of the gui stuff. For that you’d need to switch off the built-in proxy altogether and run your own.
Just to re-iterate, Maverick has a mavlink proxy already running in the background (either mavlink-router, mavproxy or cmavnode). So you don’t run ‘mavproxy.py’ as it’s already running. This is normal in an embedded environment such as a UAV - you want the proxy running automatically as a service in the background. If you want to run mavproxy as a GCS (ie the ui stuff) - then you can run it, but just connect it to the existing proxy output port, which it looks like you’re doing. Your first screenshot above is successfully connecting to the running FC proxy and it looks fine. The second is also connecting fine but you’re getting a display error. This is because you’re ssh’d into your raspberry but without an X tunnel. From a linux desktop, you’d do something like:
ssh -Y email@example.com
And then it should work. If you’re using windows, I’ve no idea how to setup an X server. You’d be better off downloading mavproxy for windows and connecting directly to tcp:maverick-raspberry.local:5770.
Hope this makes sense. It’s a bit complicated, because of the flexibility and modular nature of the setup. It needs to be simplified (which it has been a little in 2.0), but in particular documented better.