ArduPilot / ArduPilot/MAVProxy
MAVproxy infinitely re-requesting WPs after mission list by other GCS
- 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