search

iNavFlight / inav

INAV: Navigation-enabled flight control software
https://inavflight.github.io
GNU General Public License v3.0
3.19k stars 1.49k forks source link

INAV Mavlink Datastream stops with crossfire on arming #4040

Closed wx4cb closed 5 years ago

wx4cb commented 5 years ago

Current Behavior

FC: Matek F405 Wing FC INAV Version: 2.0.0 (and 2.0.1) RC Link: TBS Crossfire full module on taranis (latest version) to crossfire micro. Link Details: CRSF on UART 5, MAVLINK and MSP on UART3 @ 57600

Current behaviour is, I get full data coming down over the bluetooth link to the crossfire module (set to bridge on channels 3/4) As soon as I arm, I get no data - IE the data stream stops. INAV Mission planner on android just repeats (by voice) the last data interspersed with "no data or no connection". QGround Control does the same. Mobile flight on IOS does the same thing.

See attached video link. This has been verified on 2 matek F405 boards in 2 different models, 2 different IOS devices and 3 different android devices.

Steps to Reproduce

  1. Setup crossfire bluetooth link
  2. Connect with android or ios device
  3. Get data
  4. Arm
  5. Lose Data

Expected behavior

No data dropouts

Suggested solution(s)

Not sure. Don't understand why

Additional context

https://pastebin.com/MpR7Gu3N

INAV version string: INAV/MATEKF405SE 2.0.0 Aug 20 2018 / 19:22:34 (dbdd1656a)

wx4cb commented 5 years ago

My only question... do I need both mavlink AND msp? or just one or the other? btw, here's a video explaining the issue: https://www.youtube.com/watch?v=l4of7IcIwn4

wx4cb commented 5 years ago

OK. Just out of curiosity, I disabled MSP on that port and it worked. except i wasn't getting GPS data.

When I disabled Mavlink on that port and enabled MSP, it worked fine. So I think there's an issue with the mavlink data stream somewhere along the line as it's not sending out the gps coordinates or anything else other than pitch/roll etc

stronnag commented 5 years ago

In a simpler use case (MSP unarmed, MAVLINK armed), via 3DR, it works perfectly; at least with mwp as the GCS. When armed I receive the full set of MAVLINK telemetry, attitude, GPS data, RSSI, voltage etc.

After disarm, MSP polling resumes correctly. So I don't see any firmware issue.

wx4cb commented 5 years ago

Not saying its an inav issue at all specifically, im just trying to rule out a pebkac (user) error.

@stronnag Do you have time to post your ports tab for me?

stronnag commented 5 years ago

I'm just trying to eliminate complexity (and closed source tools that preclude analysis) .... my 3DR link is set up with serial speed 115200 and air speed 64k, so close to 57600 over the air. It is a pure transparent serial (no MAVLINK framing) as I normally prefer LTM.

# serial
serial 20 1 115200 38400 115200 115200
serial 0 257 115200 38400 115200 115200
serial 1 64 115200 115200 0 115200
serial 2 0 115200 115200 0 115200
serial 3 2 115200 115200 0 115200
serial 4 0 115200 115200 0 115200

# version
# INAV/MATEKF405 2.1.0 Nov  8 2018 / 19:01:54 (f740c47c1)
# GCC-8.2.0

image

stronnag commented 5 years ago

My only question... do I need both mavlink AND msp? or just one or the other?

Depends on what you're trying to acheive. In my case, I like to see MSP when not armed and a telemetry protocol (preferably LTM) when armed. That way I can do things things like upload missions and verify other conditions (sats / epv/h etc) pre-arming.

With CRSF, from discussions with other (mwp) users, it supports MAVLINK much better than just a transparent serial connection. However, I'm not sure that ezgui / mp4inav / mobile flight support MAVLINK and QGround Control does not support MSP. ezgui / mp4inav support both MSP and LTM.

wx4cb commented 5 years ago

Hmm interesting. So set them to 115.2 as opposed to 57600?

Also, use map and ltm? The crossfire is acting as a serial bridge

stronnag commented 5 years ago

The speed is not really relevant as long as it's fast enough to sustain MAVLINK (needs at least 19200), Otherwise, it's up to you and the GCS you are using.