MAVProxy ignores input?

I have set up a Raspberry Pi 3 to communicate with the Pixhawk via MAVProxy. When it works, it great, but there are many times where it does not.

When I send commands sometimes, like "wp list" or "mode auto" or "mode manual" etc..nothing changes. I have to say the same command several times before it registers. 

Has anyone experienced this problem? Is there a fix?

My ultimate goal is to automate how the Pi sends command via MAVProxy, but if the commands don't register that will be a problem for me (unless someone knows how to get around that).

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • That's really weird.  I think you may have hit some kind of fault or bug with that raspberry!

    rsj said:

    The pi3-miniuart-bt made it even worse.

    Went back to disable-bt

    I added this to my boot config.

    enable_uart=1

    dtoverlay=pi3-disable-bt


    Then I did

    systemctl stop hciuart

    systemctl disable hciuart

    and rebooted.

    The same problem still occurred. What's crazy is when I turn the pixhawk on and I get kicked out of the ssh session, the lights on the ethernet port go out. When I turn of the pixhawk the lights on the ethernet port turn back on and I can ssh into it. 

    Don't know if this matter, but I am using the most recent version of Jessie Raspbian from the RPi website.

  • The pi3-miniuart-bt made it even worse.

    Went back to disable-bt

    I added this to my boot config.

    enable_uart=1

    dtoverlay=pi3-disable-bt


    Then I did

    systemctl stop hciuart

    systemctl disable hciuart

    and rebooted.

    The same problem still occurred. What's crazy is when I turn the pixhawk on and I get kicked out of the ssh session, the lights on the ethernet port go out. When I turn of the pixhawk the lights on the ethernet port turn back on and I can ssh into it. 

    Don't know if this matter, but I am using the most recent version of Jessie Raspbian from the RPi website.

  • Oh yeah it's bringing back (bad) memories now.  You can get some ideas from here:

    https://github.com/fnoop/maverick/blob/master/manifests/maverick-mo...

    So do:

    systemctl stop hciuart

    systemctl disable hciuart

    Also make sure /boot/config.txt contains:

    enable_uart = 1

    rsj said:

    Yup I'm fully up to date with raspbian. The pi3-disable-bt overlay does indeed show up in my /boot/overlays/README as well.

    After reading the overlay it mentions doing sudo systemctl disable hciuart and that still didn't fix my problem. There is another overlay pi3-miniuart-bt which may fix my problem. I will give that one a shot and see if it works.

    Name:   pi3-miniuart-bt

    Info:   Switch Pi3 Bluetooth function to use the mini-UART (ttyS0) and restore

            UART0/ttyAMA0 over GPIOs 14 & 15. Note that this may reduce the maximum

            usable baudrate.

            N.B. It is also necessary to edit /lib/systemd/system/hciuart.service

            and replace ttyAMA0 with ttyS0, unless you have a system with udev rules

            that create /dev/serial0 and /dev/serial1, in which case use

            /dev/serial1 instead because it will always be correct.

    Load:   dtoverlay=pi3-miniuart-bt

    Params: <None>

  • Yup I'm fully up to date with raspbian. The pi3-disable-bt overlay does indeed show up in my /boot/overlays/README as well.

    After reading the overlay it mentions doing sudo systemctl disable hciuart and that still didn't fix my problem. There is another overlay pi3-miniuart-bt which may fix my problem. I will give that one a shot and see if it works.

    Name:   pi3-miniuart-bt

    Info:   Switch Pi3 Bluetooth function to use the mini-UART (ttyS0) and restore

            UART0/ttyAMA0 over GPIOs 14 & 15. Note that this may reduce the maximum

            usable baudrate.

            N.B. It is also necessary to edit /lib/systemd/system/hciuart.service

            and replace ttyAMA0 with ttyS0, unless you have a system with udev rules

            that create /dev/serial0 and /dev/serial1, in which case use

            /dev/serial1 instead because it will always be correct.

    Load:   dtoverlay=pi3-miniuart-bt

    Params: <None>

  • Very odd!  Have you made sure you're fully up to date with rasbian?  The pi3-disable-bt overlay was added later on.  There are other similar overlay options so might be worth exploring.

    I wonder if you've got some sort of wierd getty problem, where it switches the getty to AMA0 if it's available?  I think there's some cmdline.txt option that will disable it, been a while since I tried connecting with the raspberry. 

    rsj said:

    The weirdest things just happened. 

    I went into the boot config file and added the overlay. When I rebooted, I couldn't ssh into the Pi (connection refused). I removed the Pixhawk connection to the Pi and then I could ssh into it. The second I plugged in the Pixhawk again, it crapped itself and I got kicked out of the ssh session then couldn't ssh back in. Went through the process a couple times to make sure it wasn't a fluke.

    Went back to the boot config file and commented the part I added, then I could ssh into the pi again and have the pixhawk attached. Still can't get AMA0 to work though.

    I think you are right and the problem has to do with S0 vs AMA0. I will figure out how to get AMA0 to work in the mean time and I will let you know what happens.

  • The weirdest things just happened. 

    I went into the boot config file and added the overlay. When I rebooted, I couldn't ssh into the Pi (connection refused). I removed the Pixhawk connection to the Pi and then I could ssh into it. The second I plugged in the Pixhawk again, it crapped itself and I got kicked out of the ssh session then couldn't ssh back in. Went through the process a couple times to make sure it wasn't a fluke.

    Went back to the boot config file and commented the part I added, then I could ssh into the pi again and have the pixhawk attached. Still can't get AMA0 to work though.

    I think you are right and the problem has to do with S0 vs AMA0. I will figure out how to get AMA0 to work in the mean time and I will let you know what happens.

  • Also, try detaching your 3dr radio and arduino device and only have the Pi, see if that helps.  The python that underlies mavproxy (I think, certainly it underlies dronekit and I think they both use pymavlink) doesn't handle multiple devices attached to the same controller well.  Since firmware 3.3 the pixhawk routes mavlink and it can upset an attached companion computer.

    rsj said:

    It seems as if I may have spoke to soon. When turning it on today, the problem seems to be back. However, it occurs less frequently and mainly when using the "mode" command. 

    When I want to change modes it will ignore multiple times before it accepts. I checked to make sure BRD_SER2_RTSCTS was still set as 0, and it was. I even checked via MAVProxy...

    param show BRD_SER2*

    MANUAL> BRD_SER2_RTSCTS  0.000000

    I tried increasing the baud rate to see if that would help, but still the same issue.

  • That might possibly be another problem.  ttyS0 on the pi 3 isn't reliable as the clock speeds change with CPU power management.  Move the UART back to AMA0 as I noted in the post below and it should be more reliable:

    http://discuss.ardupilot.org/t/connecting-raspberry-pi-to-pixhawk/9784

  • It's a Raspberry Pi 3

    I use /dev/ttyS0

    I followed the instructions here

    http://ardupilot.org/dev/docs/raspberry-pi-via-mavlink.html 

    But when I used the mavproxy.pi command I got errors and it turned out I had to use S0 instead. My startup command is:

    sudo python mavproxy.py --master=/dev/ttyS0 --baudrate 57600 --aircraft Rover

    Communicating with Raspberry Pi via MAVLink — Dev documentation
  • How are you accessing the pixhawk from the pi?  Through ttyAMA0?

This reply was deleted.

Activity