ArduPilot / ArduPilot/MAVProxy
Optimise MAV FTP upload to improve performance
- Dominant language
- Python
- Stars
- 595
- Forks
- 773
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 18
Description
We have a report in Copter-4.4 that uploading a 30MB terrain file using MAVFTP takes >30min ([see report here](https://discuss.ardupilot.org/t/terrain-data-loading-on-sd-card-via-mavftp-is-slow/107750/3))
As part of the investigation I attempted to upload a 30MB terrain file (produced using https://terrain.ardupilot.org/) and confirmed that indeed MP does take at least 30min (it only uploaded 1MB of the file in 5min). See MP issue here: https://github.com/ArduPilot/MissionPlanner/issues/3229
To try and determine if MAVProxy was any faster (in the hopes that it would be thus confirming that the issue was in MP) I found that MAVProxy's "ftp" command simply doesn't work at least on windows.
I was running the latest MAVProxy (1.8.66)

The exact procedure was:
- started MAVProxy and connected to a CubeOrange running Copter-4.4.2 (stable) or Copter-4.5.0-dev (latest)
- copied the N43E143.DAT file to my Desktop
- attempted to ftp to the APM directory (I had also tried uploading to APM/TERRAIN earlier with no success)
- waiting >7min and checked the since of the file, it was still zero
```
STABILIZE> ftp put C:\Users\rmack\Desktop\N43E143.DAT APM/
Putting C:\Users\rmack\Desktop\N43E143.DAT as APM/N43E143.DAT
STABILIZE> ftp list APM
Listing APM
D LOGS
D STRG_BAK
D TERRAIN
D scripts
N43E143.DAT 0
UNKNOWN.bak 16384
```
By the way, if I ran the same ftp command but neglected to add the "/" after the "APM" I got this message spamming my console.

Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the Windows transfer with the MAVProxy ftp command, using the reported `ftp put C:\Users\rmack\Desktop\N43E143.DAT APM/` command and checking it with `ftp list APM`. Trace the ftp upload path and compare its behavior with the reported Mission Planner transfer. Done means the 30MB file uploads successfully instead of remaining at zero bytes, with improved transfer performance.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 42/100