ArduPilot / ArduPilot/MAVProxy

MAVproxy infinitely re-requesting WPs after mission list by other GCS

Open
#918 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
595
Forks
773
Avg merge
2d 6h
Merged PRs (30d)
18

Description

We use MAVProxy as relay between UAV and GCS.

I found an issue in MAVProxy. After requesting mission download from UAV to GCS, MAVProxy in the middle starts send mission requests periodically. It often disturbs firstly started mission download process.

I did some research in file `mavproxy_wp.py` and discovered that:

Every MISSION_COUNT message is process and value of expected mission count is set, but operation mode self.wp_op is not changed [(code)](https://github.com/ArduPilot/MAVProxy/blob/2dfcea92597f6f37448d4c76a8b5f4b58956b37e/MAVProxy/modules/mavproxy_wp.py#L149):
```
if mtype in ['WAYPOINT_COUNT','MISSION_COUNT']:
self.wploader.expected_count = m.count
[...]
```

However in [(code)](https://github.com/ArduPilot/MAVProxy/blob/2dfcea92597f6f37448d4c76a8b5f4b58956b37e/MAVProxy/modules/mavproxy_wp.py#L214) timeout handler will always send new mission request if number of downloaded item is less then just received `self.wploader.expected_count`, even `if self.wp_op != "list"`:
```
def idle_task(self):
'''handle missing waypoints'''
if self.wp_period.trigger():
# cope with packet loss fetching mission
if self.master is not None and self.master.time_since('MISSION_ITEM') >= 2 and self.wploader.count() < getattr(self.wploader,'expected_count',0):
wps = self.missing_wps_to_request();
print("re-requesting WPs %s" % str(wps))
self.send_wp_requests(wps)
```

UAV will send mission list to MAVProxy, but due to `self.wp_op != list` this items will never be processed.

I added additional condition `and self.wp_op == "list"` in `idle_task` to workaround problem.

Maybe also target system/component ids and mission type fields in received messages ought to be checked?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in MAVProxy/modules/mavproxy_wp.py, reviewing the MISSION_COUNT handling and the idle_task() timeout path. Reproduce or trace a mission download arriving from another GCS, then verify that MAVProxy no longer re-requests items for an operation that is not listing a mission; consider the reported target and mission-type checks as part of the review.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli, networking
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.