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 [email protected] 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//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 [email protected] 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 [email protected] 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//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 [email protected]:

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 [email protected] 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 [email protected]
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//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 [email protected]:

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//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 [email protected] 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//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 [email protected] 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 [email protected] 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//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.