FILE_DOES_NOT_EXIST on calling the drone.ftp.list_directory() to fetch internal directories file

[jhadevansh08]

How to Recreate

Code 1

#!/usr/bin/env python3

import asyncio
from mavsdk import System

async def run():

    drone = System(mavsdk_server_address='localhost', port=50051)
    await drone.connect(system_address="serial:///dev/ttyACM1:57600")
   
    print("Waiting for drone to connect...")
    async for state in drone.core.connection_state():
        if state.is_connected:
            print(f"-- Connected to drone!")
            break
       
    print("directory list", await drone.ftp.list_directory("/"))

    # Run the asyncio loop
    asyncio.run(run())

Output 1

directory list ['Dbin', 'Ddev', 'Detc', 'Dfs', 'Dobj', 'Dproc']

Code 2

---

#!/usr/bin/env python3
 
import asyncio
from mavsdk import System
 
async def run():
 
    drone = System(mavsdk_server_address='localhost', port=50051)
    await drone.connect(system_address="serial:///dev/ttyACM1:57600")
   
    print("Waiting for drone to connect...")
    async for state in drone.core.connection_state():
        if state.is_connected:
            print(f"-- Connected to drone!")
            break
       
    print("directory list", await drone.ftp.list_directory("/Dbin"))

if __name__ == "__main__":
    # Run the asyncio loop
    asyncio.run(run())

Output 2

raise FtpError(result, "list_directory()", remote_dir)
mavsdk.ftp.FtpError: FILE_DOES_NOT_EXIST: 'File Does Not Exist'; origin: list_directory(); params: ('/Dbin',)

Even for any folder given , I am getting the same error

[julianoes]

I think the D stands for directory and you might want to list the directory using:

    print("directory list", await drone.ftp.list_directory("/bin"))

Does that work?

[jhadevansh08]

Tried that.
Getting the same error.

[julianoes]

Oh ok. Is this against PX4 or ArduPilot?

[jhadevansh08]

I am using PX4.

[julianoes]

Ok cool, thanks for the info. I should be able to reproduce this. I'll put it on my todo list. If this is urgent and blocking you, consider throwing something in the hat.

[jhadevansh08]

I removed 'D'.
It's working now ,somehow.
Just a small issue when FILE_DOES_NOT_EXIST comes , even if I try to access the root directory after that, it is showing the same error.
Thanks

[julianoes]

I'm not sure I follow. Can you explain the exact steps to get into that case?

[jhadevansh08]

So if I am trying to access a directory which gives me FILE_DOES_NOT_EXIST error. After that, even if I try to access any directory, it will give me this error.

[julianoes]

Aha! That doesn't sound right indeed.

[julianoes]

I can reproduce the issue. I'm looking into it.

[julianoes]

It looks like we get a nak from PX4:

[05:33:44|Info ] MAVSDK version: v2.10.1-dirty (mavsdk_impl.cpp:26)
[05:33:44|Debug] Ftp debugging is on. (mavlink_ftp_server.cpp:20)
[05:33:44|Info ] Waiting to discover system on serial:///dev/ttyACM0:57600... (connection_initiator.h:20)
[05:33:44|Debug] New system ID: 1 Comp ID: 1 (mavsdk_impl.cpp:720)
[05:33:44|Debug] Ftp debugging is on. (mavlink_ftp_client.cpp:21)
[05:33:44|Debug] Component Autopilot (1) added. (system_impl.cpp:365)
[05:33:44|Warn ] Vehicle type changed (new type: 2, old type: 0) (system_impl.cpp:216)
[05:33:44|Debug] Discovered 1 component(s) (system_impl.cpp:508)
[05:33:44|Info ] System discovered (connection_initiator.h:62)
[05:33:44|Debug] MAVLink: info: GCS connection regained	 (system_impl.cpp:242)
[05:33:44|Info ] Server started (grpc_server.cpp:169)
[05:33:44|Info ] Server set to listen on 0.0.0.0:50051 (grpc_server.cpp:170)


[05:33:49|Debug] Processing FTP message to target compid: 190, our compid: 190 (mavlink_ftp_server.cpp:41)
[05:33:49|Debug] FTP opcode: 129, size: 1, offset: 0, seq: 1 (mavlink_ftp_server.cpp:72)
[05:33:49|Debug] FTP: opcode: 129, size: 1, offset: 0, seq: 1 (mavlink_ftp_client.cpp:127)

I'm running mavsdk_server separately as explained in http://mavsdk-python-docs.s3-website.eu-central-1.amazonaws.com/#debug-connection-issues, and I'm setting export MAVSDK_FTP_DEBUGGING=1.

[julianoes]

Ok, so you're right in that it's some sort of state issue where it doesn't recover if it has once received a "not existing".

[julianoes]

It looks like we always need to send a TERMINATE_SESSION command, which I omitted for certain calls. Thus PX4 always just responded with the last ack/nak.

Fix coming: mavlink/MAVSDK#2309