APM in Linux (continuation of BeaglePilot): Telemetry issue

[Víctor MV]

Hi everyone,

I'm hoping that some of you, experienced users with MAVLink and telemetry can give me some insight in the current problem that i'm facing:

I'm trying to connect the telemetry radio to the BeagleBone Black USB port and launch ardupilot using that interface (/dev/ttyUSB0) for the telemetry (-A flag).

While everything seems to work fine hardware-wise (both radios have a solid green light and the red blinking, sign that they are receiving data) i'm not able to launch any GCS properly.

My last test has been with MAVProxy:

victor@frcsim:~/Desktop$ sudo mavproxy.py --master /dev/ttyUSB1 --baudrate=57600 --mav09 --nowait

WARNING: You should uninstall ModemManager as it conflicts with APM and Pixhawk

Logging to mav.tlog

MAV> O! O! O! alink 1 down

O! Flight battery warning

O! aO! A3Dd&*O! O! O! !O! O! !O! O! AO! O! AO! aO! O! aO! 3Dd(+O! O! O! 3Dd+0JO! O! O! O! O! O! O! !O! O! !O! O! AO! O! A3Dd))@O! O! !O! O! O! 3Dd)0Flight battery warning

O! AO! O! AO! O! O! O! O! !O! 3Dd')1RO! O! aO! O! aO! O! A3Dd(,^O

! O

! O! O! O

! O

O !O! O! !O! O! aO ! 3Dd)-

! O! !O! O

I tried with different baudrates and different settings but it doesn't seem to work as i would expect. The vehicle however flights properly. Here's a log that i record yesterday https://github.com/erlerobot/drones_logs/blob/master/pxf/copter/11-9-2014/1.BIN (FYI i'm having an issue with the GPS which i believe it's related to a bad GPS unit).

Any comment will be appreciated.

Thanks,

Víctor.

[Jonathan Challinger]

Probably need to uninstall modemmanager

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Víctor MV]

Hi Jonathan,

Thanks for the suggestion.

However I've been working with mavproxy through TCP sockets the whole summer without modemmanager and i didn't had any problem. Switching to a serial device shouldn't change anything. I believe this fact is unrelated but i'd give it a try.

--
You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/idGQKyv8jEQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Jonathan Challinger]

modemmanager behaves badly by assuming all serial devices are modems

[Kevin Hester]

Victor,

Is there a reason you are using --mav09?  All the current code is mavlink 1.0 based.

Kevin

[Víctor MV]

Hi Kevin,

No specific reason. I tried also without it and even with the auto-detection flag.

i was hoping that taking a look at the log might give some insight. I tried uploading them to droneshare but for some reason i get a conflict with the date (which might be unrelated to the radios actually). Looking at the raw data looks good on me (besided the fact that the data is wrong, GPS hardware issue i believe).

I fetched a PX4 and will reproduce the process with it now which should allow me to discard harware issues with the radios. I also want to try with plane (so far i've been trying copter) to see if there's a vehicle issue.

Víctor.

[Víctor MV]

The hardware is fine, tested it with with screen on each one of the radios. Should be software-related.

[Víctor MV]

Hi everyone!

There's definitely something that i'm missing. Maybe MAVProxy is being launched incorrectly or maybe using the USB  instead of one of the SPIs is causing some issue (using the USB client for connecting the telemetry device to the BBB).

I just tried Plane, getting similar results https://gist.github.com/vmayoral/f5e507b1b38a49b20639. Still not working.

[Ben Nizette]

Hi Victor,

So, to make sure I'm on the same page: You've got a BBB with APM/Linux
on it and a telemetry radio connected to that over USB. On a separate
computer, you've got the other half of the radio link attached to
MAVProxy and it's the output from this second machine that we're
seeing in your snippets?

In OP, you are using a Linux machine and in the Plane gist, you're
using a Mac, is that right? So we can rule out anything
platform-specific on that end of the link? In OP you have the
baudrate at 57600 which is correct, in the Plane snippet you have the
baud rate at 115200 which is incorrect afaict. Can you confirm that
the behaviour shown in the Plane snippet continues when run at 57600?

ModemManager only affects serial devices that look a little bit like a
modem, so it won't have had any effect when running over TCP. You
should uninstall it. However, given the second set of results come
from a Mac, it's unlikely to be the underlying problem.

My first attempt at debugging from here would be to send something
human-readable down the link (e.g. a bunch of GCS_SendText calls in a
loop in the APM code, or whatever the function is called) then fire up
screen at the receiving end. Even better, fire up a terminal capable
of hex output so you can double-check the framing bytes too. If the
radios are known good (and it seems they are) then this will split
between something in MAVProxy and something in APM/Linux. Of course
the latter is much more likely.

If you can confirm that in fact APM/Linux is sending the wrong bytes
then you've got a well-enough defined debugging problem. Stick some
printfs or something at the lowest level of the MAVLink code you can,
right where it writes to the output device, and check the values. If
you've got this far then my best bet would be for a timing/buffering
issue; something not blocking when it should or an off-by-1 or
something that causes a buffer read to overrun where it should. Just
a thought: Has your code base got Tridge's UART buffering fix from a
few weeks in it? I don't know whether that only affects the GPS ring
buffers or whether it might affect the telemetry ones also?

Anyway, that's enough of that for now, post back with any further
results and I'll take a look!

Cheers,
Ben.

[Víctor MV]

Ben,

Thanks a lot for your suggestions. Really helpful.

I'm using the diydrones/ardupilot code with latest commit so hopefully i shouldn't get affected by previous issues.

So, to make sure I'm on the same page: You've got a BBB with APM/Linux
on it and a telemetry radio connected to that over USB.  On a separate
computer, you've got the other half of the radio link attached to
MAVProxy and it's the output from this second machine that we're
seeing in your snippets?

That's correct.

 

In OP, you are using a Linux machine and in the Plane gist, you're
using a Mac, is that right? So we can rule out anything
platform-specific on that end of the link?  In OP you have the
baudrate at 57600 which is correct, in the Plane snippet you have the
baud rate at 115200 which is incorrect afaict. Can you confirm that
the behaviour shown in the Plane snippet continues when run at 57600?

The behavior is the same whether i run it at 115200 or at 57600. 

Although i'm a newcomer to the telemetry radios, I believe that with the AP_HAL_Linux they are launched at 115200 which is why i was using that value (maybe i got confused?). I actually tried modifying this value to 57600 and making the tests again. In this case i got something like:

mavproxy.py --master=/dev/tty.usbserial-DN002236,57600

Logging to mav.tlog

MAV> FRAM: Online

bb$FC#E#bbbbEO!!$@GO!!O!O!!@O!O!

That first line showing "FRAM Online" is an improvement!

I kept digging using the method you suggested. Put a couple of traces and found out that the code actually changes the bauds of the serial port here so I made a quick fix there and....:

mavproxy.py --master=/dev/tty.usbserial-DN002236,57600

Logging to mav.tlog

MAV> FRAM: Online

Init ArduCopter V3.3-dev (345d4353)

Free RAM: 4096

FW Ver: 120

----------------------------------------

load_all took 258us

STABILIZE> Mode STABILIZE

Issue located. A few comments:

As far as i've read, it seems that 3DR Radios are configured for 57600. Although i'm totally new to the radios I will assume that this a firmware related aspect. If so, that'll mean that in order to work with the radios with a baud rate of 115200 you need to flash the firmware with the right configuration.

Since i didn't flash them but just used them as they came that'll explain this behavior and why I was not able to make it work.

Jonathan, Kevin and Ben, thanks a lot for your support!

In case anyone is interested, here is the fix. 

[Jonathan Challinger]

Use --baudrate 57600 to set baudrate to 57600 in mavproxy.

[Víctor MV]

Jonathan,

I thank your suggestion but i did try that already and it did not work for me. Furthermore the issue was in the autopilot side.

In case i am mistaken i'd love to get an explanation how is possible to change the autopilot software at runtime from a MAVProxy flag. Specially when the bauds in ardupilot seemed to be hardcoded in config.h.

[Jonathan Challinger]

May've been modemmanager changing the baudrate at the time?

[Jonathan Challinger]

Baudrate parameters are SER*_BAUD

[Jonathan Challinger]

http://copter.ardupilot.com/wiki/arducopter-parameters/#Telemetry_Baud_Rate_ArduCopterSERIAL1_BAUD

[Víctor MV]

Seems you were right Jonathan! Thanks for the link (i definitely need to study the parameters). Probably changing this value should do it.

http://copter.ardupilot.com/wiki/arducopter-parameters/#Telemetry_Baud_Rate_ArduCopterSERIAL1_BAUD

You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/idGQKyv8jEQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Ben Nizette]

Hi Victor,

Great! You've found the problem and param, that's good.

The radios have internal parameters that are configured by AT commands
that control things like on-air data rate, ECC use, frequency bands
and - serial port baud rate. You can probably (?) run them at 115200
but you will need to change those radio parameters. This is separate
from any Ardupilot anything, though can be configured through Mission
Planner. I think there's also a standalone config tool at
http://vps.oborne.me/3drradioconfig.zip but I haven't used it.

Note that the 115200 references in the code point to serial port
endpoints tied to USB ports (or at least, they should).

Anyway, congrats!

Ben.