What is the practical limit to the number of waypoints / mission items for PX4?

I understand the SDcard as the typical storage location for the onboard mission. I believe this is controlled buy MIS_ONBOARD_EN parameter defaulted to 1. https://pixhawk.org/firmware/parameters#mission

Is there a practical limit to the number of waypoints and/or mission items that can be in the mission? We plan on doing large survey flights with potentially hundreds of waypoints and mission items (like start/stop cameras, etc).

How about mission size stored on SDcard vs stored in local memory on the processor (MIS_ONBOARD_EN = 0?)?

There is not really a practical limit. Right now we’ve set and tested it to 2000 waypoints.

I see. I am running into a limit of 256 waypoints when planning survey missions in Qgroundcontrol and uploading to a Pixracer. Greater than 256 waypoints returns this message in Qgroundcontrol:

Is there a recommended way for us to increase this limit?

Ahhh… I see this recent PR now that increases the limit. I look forward to using this in upcoming stable release. :slight_smile:

Has there been any additional changes to dataman in the last few years?
We are currently running into a waypoint limitation of 500 on a Holybro Pixhawk 6X when uploading through QGC.

From what we understand mission waypoints are stored on the SD Card, and accessed though dataman. Dataman pre-allocates 62560 bytes to the file if we have it create a new file on the SD Card, or format the SD and reflash irrespective of the size of the SD Card.

Is there any way to increase the waypoint limitation, or is it somehow linked to the onboard memory of the Pixhawk and not the size of the SD Card, or is it perhaps configurable that we can change it if we recompile PX4?

Hey @bubbles I stumbled on this thread and quickly checked the code. The 500 waypoints limit is hardcoded here:

I don’t know all the implications but it seems it was changed from 256 to 2000 with the previously linked pull request and now it got reduced again to 500 with this pr because of RAM usage

If that’s not enough I suggest you bring up the discussion e.g. in a GitHub issue or the community Q&A call.

Hey @MaEtUgR, thank you for the response.
Per Magic value for NUM_MISSIONS_SUPPORTED in navigation.h explanation I located the NUM_MISSIONS_SUPPORTED parameter and successfully increased it and flashed an FC. The mission items upload to the SD correctly, confirmed by redownloading of the plan.

I understood the PR comment “reduce NUM_MISSIONS_SUPPORTED from 2000->500 so RAM backend is viable on typical F7”, to mean targeted at RAM only devices and not to mean that the RAM usage will be greatly influenced when flying missions from the SD card. I’ll have to work through the code in more detail to understand if dataman does some form of preloading from the SD card and then caches the mission items in RAM or if it only reads from the SD as needed. Perhaps you can shed light on this?

Furthermore, are there any guidelines as to how you typically test the running stability of a build? I’ve had a look at the standard test flights Tests Flights | PX4 User Guide and though very useful they are limited to behaviour and not necessarily parameter monitoring. For the above I’m guessing a long running flight while monitoring resource usage.