ArduPilot / ArduPilot/MAVProxy
mavproxy 'no link'
- Dominant language
- Python
- Stars
- 595
- Forks
- 773
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 18
Description
Is this likely to be a bug in mavproxy or its host or AP?
Im bringing up a new port of AP to flymaple. AP is latest git version. mavproxy talks happily to the new port but at apparently random times loses the link:
RTL> no link
link 1 down
no link
.... repeated forever.....
and prints no more data from the AP, although I can stlll get a prompt from mavproxy.
In that state:
I can see serial data on the serial line still coming from AP to the host (FTDI USB-serial). The mavlink host (OpenSuSE 12.3) reports no errors with the USB port, but at the time the link is lost the mavproxy log file mav.tlog.raw stops being appended.
I can see on the serial line heartbeats still being transmitted by mavproxy.
Killing and restarting mavproxy (without doing anything to the AP) brings the link back to life. It might run OK for up to 10 mins again before losing the link again.
I know its possible there is something wrong with my flymaple port, though
interestingly, when connected to MissionPlanner 1.2.79 on a PC, connected with the same FTDI cable, the mavlink connection will stay up forever. And the fact that the flymaple is still producing a stream of serial data after mavproxy thinks it sees no more data is compelling, as is the fact that stopping and restarting mavproxy also fixes it.
Could of course be an OpenSuSE USB-serial driver problem, though I have not seen similar problems with serial-USB FTDI dongles before.
This seems like mavproxy is not receiving any more chars from the USB-serial port. Ring a bell with anyone?
Anyone else running it OK on OpenSuSE 12.3?
I cant see any debug options in mavproxy to help diagnose this.
Suggestions?
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the intermittent link loss with MAVProxy on OpenSuSE 12.3, using the FTDI USB-serial setup and observing mav.tlog.raw. Compare the failing MAVProxy session with the stable MissionPlanner connection and the serial data and heartbeats described in the report. Done means isolating whether the failure is in MAVProxy or the host/USB-serial path and recording enough diagnostic evidence to act on it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100