Safely accessing FATFS in flight for very large mission files stored on SD card

Hi everyone,

I am working on a custom ArduPilot setup and I am currently facing a mission storage size limitation.

My mission file is very large, around 512 KB, so the existing SD mission storage support in ArduPilot is not enough for my use case. From what I understand, the current implementation only supports up to 64 KB of mission storage on SD card, and that data is loaded into the vehicle’s RAM before flight. For my application, 64 KB is far from sufficient.

Because of this, I modified the source code so that the mission file is stored directly on the SD card, and mission items are read from the SD card during flight instead of being fully preloaded into RAM.

To make this work, I removed the FATFS access restriction while armed by relaxing:

FS_CHECK_ALLOWED(-1)

At this point, my implementation is already working in practice: the vehicle can arm and fly, and the mission can be read from the SD card in flight.

However, I would like to ask the community:

  1. Is it safe to allow FATFS access while the vehicle is armed/in flight?

  2. Could this cause any unexpected side effects, such as timing issues, scheduler delays, SD card contention, logging conflicts, or other stability/reliability problems that may not be obvious at first?

  3. Is there any recommended or more standard way to support much larger mission files (for example around 512 KB) in ArduPilot?

  4. Has anyone already implemented a similar approach for large mission storage, such as:

    • streaming mission items from SD card on demand,

    • using a dedicated buffered reader/cache,

    • extending the existing mission storage backend beyond 64 KB,

    • or another safer design?

My concern is that although the code works, removing this protection may introduce risks that I have not yet discovered.

Any guidance on the safety of this approach, or suggestions for a better implementation path, would be greatly appreciated.

Thanks.

1 Like