Unable to run mavproxy in the background

[dccourt]

I'm trying to run mavelous completely headless at boot time on a Raspberry Pi (Debian Linux).

I find that it runs fine when run within an ssh session in the foreground, but when run in the background, it bombs out pretty early on - just after presenting the "MAV>" prompt. I don't see any interesting logs being produced, sadly, even with --logging-level=DEBUG.

To repro, simply:
python mavproxy.py --module mavelous --master=/dev/ttyUSB1 --baud=57600 &

[dccourt]

For what it's worth, replacing line 1514 of mavproxy.py, currently

line = raw_input(mpstate.rl.prompt)

with

line = '\n'

appears to make it usable. We should probably consider allowing a command-line option to disable TTY input to mavproxy.

Want me to go ahead and draft a fix?

[pchickey]

Yes please! Thanks for reporting and troubleshooting.

But first can you try running a new version of mavproxy (from Tridge on Github)? We haven't taken in upstream changes from mavproxy in months and it may be better to fix this upstream and then pull in the latest mavproxy.

Pat

On Feb 23, 2013, at 5:20 PM, David Court notifications@github.com wrote:

For what it's worth, replacing line 1514 of mavproxy.py, currently

line = raw_input(mpstate.rl.prompt)

with

line = '\n'

appears to make it usable. We should probably consider allowing a command-line option to disable TTY input to mavproxy.

Want me to go ahead and draft a fix?

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/51#issuecomment-14001537.

[dccourt]

Sure, I can give that a whirl. Is it a direct drop-on replacement for mavproxy.py? I thought I'd seen somewhere that there are some mavelous-specific patches - but perhaps that was mavlink?

On 24 Feb 2013, at 01:43, Pat Hickey notifications@github.com wrote:

Yes please! Thanks for reporting and troubleshooting.

But first can you try running a new version of mavproxy (from Tridge on Github)? We haven't taken in upstream changes from mavproxy in months and it may be better to fix this upstream and then pull in the latest mavproxy.

Pat

On Feb 23, 2013, at 5:20 PM, David Court notifications@github.com wrote:

For what it's worth, replacing line 1514 of mavproxy.py, currently

line = raw_input(mpstate.rl.prompt)

with

line = '\n'

appears to make it usable. We should probably consider allowing a command-line option to disable TTY input to mavproxy.

Want me to go ahead and draft a fix?

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/51#issuecomment-14001537. — Reply to this email directly or view it on GitHub.

[pchickey]

Its a bit more complicated than that - mavelous is effectively 1. a python script loaded as a mavproxy module, which runs the backend and 2. the frontend html/js served by that plugin. At the start of the project, we had to pack the backend module and whole frontend inside a /modules/ subdirectory in the full distribution of mavproxy, because of the way the mavproxy module importer worked, depending on file paths relative to mavproxy.py.

Since then, upstream mavproxy's module system has been reworked a bit incorporating some feedback from John. I believe the idea was to keep the mavelous server module & frontend code separate from mavproxy and let python's module system resolve the mavelous module, but I don;t really know much of anything about python's module system, so maybe John can provide more info...

Anyway, the starting point for pulling in upstream mavlink would be to take the mavelous backend and install it in a /modules/mavproxy_mavelous subdirectory of the latest MAVProxy. You'll probably need to fiddle around with various names and relative paths in the mavelous backend to make this work.

FWIW, I'm also investigating switching away from MAVProxy to a completely different backend based on Kevin Hester's andropilot project - https://github.com/geeksville/arduleader. (I haven't made any concrete progress yet except for getting lots of help from Kevin setting up, but I'm going to hack on it today for a bit.) The andropilot backend has a two advantages that make it worth considering:

1. It runs natively on android with just a USB host connection to the 3DR radio. So far it has been difficult to shoehorn MAVProxy into running on Android
2. It should be easier to distribute as an executable - we can make downloadable packages for windows and mac that just has the compiled sources & JVM, so users don't have to worry about installing Python & the required python modules.

On Sun, Feb 24, 2013 at 2:29 AM, David Court notifications@github.comwrote:

Sure, I can give that a whirl. Is it a direct drop-on replacement for mavproxy.py? I thought I'd seen somewhere that there are some mavelous-specific patches - but perhaps that was mavlink?

On 24 Feb 2013, at 01:43, Pat Hickey notifications@github.com wrote:

Yes please! Thanks for reporting and troubleshooting.

But first can you try running a new version of mavproxy (from Tridge on Github)? We haven't taken in upstream changes from mavproxy in months and it may be better to fix this upstream and then pull in the latest mavproxy.

Pat

On Feb 23, 2013, at 5:20 PM, David Court notifications@github.com wrote:

For what it's worth, replacing line 1514 of mavproxy.py, currently

line = raw_input(mpstate.rl.prompt)

with

line = '\n'

appears to make it usable. We should probably consider allowing a command-line option to disable TTY input to mavproxy.

Want me to go ahead and draft a fix?

— Reply to this email directly or view it on GitHub< https://github.com/wiseman/mavelous/issues/51#issuecomment-14001537>. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/51#issuecomment-14006409.

[dccourt]

I got as far as determining that there's no relevant difference in the latest mavproxy. But when I tested my setup in the field at the weekend, I noticed that it still didn't launch mavelous automatically on boot, so I think there's still something I need to figure out before I formalise this into a fix.

Interesting to see the progress of Andropilot. I for one would be keen to see mavelous continue to support RasPi, whatever happens to the backend, although it does seem that the Android approach has a lot going for it.

[pchickey]

OK, thanks for looking into it, keep us posted.

We'll definitely be supporting running on a raspberry pi, no matter which backend we end up with.

On Tue, Feb 26, 2013 at 3:11 PM, David Court notifications@github.comwrote:

I got as far as determining that there's no relevant difference in the latest mavproxy. But when I tested my setup in the field at the weekend, I noticed that it still didn't launch mavelous automatically on boot, so I think there's still something I need to figure out before I formalise this into a fix.

Interesting to see the progress of Andropilot. I for one would be keen to see mavelous continue to support RasPi, whatever happens to the backend, although it does seem that the Android approach has a lot going for it.

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/51#issuecomment-14145974 .

[crashmatt]

Use screen -dm -S mavproxy /home/root/mav/mavproxy.sh

the use this to re-attach to the screen screen -r mavproxy

When in the mavproxy screen, do not CntrlC to exit if you want to keep it running. Do CntrlA - d to detach

[tstellanova]

Here's a workaround for running mavproxy in a boot script:

https://github.com/tridge/MAVProxy/issues/17

Allows you to pipe i/o to mavproxy as well

[crashmatt]

Todd, Not sure why this came to me but I have been running mavproxy at boot on a gumstix .

I use the screen command launched as detached. Then you can re-attach to it with terminal to do debugging. Works a treat.

/Matt

On 16 August 2013 21:38, Todd Stellanova notifications@github.com wrote:

Here's a workaround for running mavproxy in a boot script:

tridge/MAVProxy#17 https://github.com/tridge/MAVProxy/issues/17

Allows you to pipe i/o to mavproxy as well

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/51#issuecomment-22788935 .

[tstellanova]

Thanks for the info Matt, that definitely helps with debugging. Long term we want to be able to pipe commands to mavproxy so we may just end up running the forked version headless.

On Aug 16, 2013, at 1:41 PM, Matthew Coleman notifications@github.com wrote:

Todd, Not sure why this came to me but I have been running mavproxy at boot on a gumstix .

I use the screen command launched as detached. Then you can re-attach to it with terminal to do debugging. Works a treat.

/Matt

On 16 August 2013 21:38, Todd Stellanova notifications@github.com wrote:

Here's a workaround for running mavproxy in a boot script:

tridge/MAVProxy#17 https://github.com/tridge/MAVProxy/issues/17

Allows you to pipe i/o to mavproxy as well

— Reply to this email directly or view it on GitHubhttps://github.com/wiseman/mavelous/issues/51#issuecomment-22788935 .

— Reply to this email directly or view it on GitHub.

[crashmatt]

This thread came through to my gmail which is utterly confusing but lucky

You don't need to modify anything. Just use screen. It provides a virtual terminal for mavproxy to run in without displaying it. You can then re-attach to this screen using an ssh login or the standard terminal. Headless not required.

The script launched on boot:

"#!/bin/bash

cd /home/root/mav/

start a screen session for mavproxy but detach from it

screen -dm -S mavproxy /home/root/mav/mavproxy.sh

read -p "mavproxy launched in background. Use screen -r mavproxy to attach" -n1 -s -t3"

[tstellanova]

I agree screen is one solution if you want to interact manually with mavproxy after it's launched. It's not great if you want to pipe the output of mavproxy to another process, or pipe the output of another process to mavproxy. Sure, you could probably cobble something together with screen+mkfifo.

[crashmatt]

That is a communication method that I don't understand. Screen works with UDP connections so I falsely presumed that IP and server connections would also work. If you need a named data pipe of some sort then I have no idea.