Feature request: extend the number of waypoints

[ghost]

Hi all,

today I wanted to set up a mission in QGC for a long flight time / high resolution survey and received the following error:

Received mission iten out of sequence
(MAV_MISSION_INVALID_SEQUENCE). Sequence: 1.

It obviously stems from the current maximum number of waypoints, which seems to be 718:
https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/ReleaseNotes.txt#L751

I would be great if this limit can be extended.

Thanks an best regards,
Thorsten

[WickedShell]

@ThorstenDP This is not an error from exceeding the number of waypoints. If you exceed the waypoints we continuously replace the last waypoint in the list with the newly uploaded one. MAV_MISSION_INVALID_SEQUENCE is only sent when a GCS uploads a waypoint that the autopilot was not requesting. This is a GCS mission handling error (possibly caused by packet loss/radio relays) and not an artifact of hitting the waypoint limit.

[ghost]

@WickedShell Thanks for your reply!
Can you provide some more details on "we continuously replace the last waypoint in the list with the newly uploaded one"? What happens if I want to upload 720 WPs? Will WP 719 be dropped?

[WickedShell]

@ThorstenDP that used to be true for awhile anyways, just tested in SITL and when I attempted to upload 750 waypoints I got a MAV_MISSION_NO_SPACE ACK which is definitely the better behavior. (If you test in SITL/real hardware with a mission with more waypoints and don't get that let me know as that would be a bug.) https://github.com/ArduPilot/ardupilot/blob/master/libraries/GCS_MAVLink/GCS_Common.cpp#L497 is the relevant line that sends the NACK

[auturgy]

Michael, do you mind if I re-open this?
It's come up before, and with the endurance of systems improving all the time, it is something worth looking at. The current approach for very large missions is to script them via a companion computer or ground station, which works well, but adds a layer of complexity that some users aren't comfortable with. Being able to use the SD card might be nice.

[WickedShell]

@auturgy I mind in the sense that we already have issues for those :) #4424 tracks missions on SD cards, #4172 is a increase space for linux boards PR (we don't have space for more waypoints in the current one) #2391 tracks the request to have flexible storage space per element which is the only proposal other then SD cards to get normal PH boards more mission space.

I just didn't see this as adding anything new to track other then being a similar meta issue to the ones I've linked. So it can be reopened, but I'd like to only reopen it if we have a distinctly narrow focus.

[auturgy]

Got it. Linked to 4424 makes sense.

[ghost]

Is the limitattion on Pixhawk boards related to the 1MB limit of the older boards?

[WickedShell]

It's related to storage on FRAM rather then flash. There was a recent bit of work I believe to enable using flash rather then FRAM for storage of waypoints (IIRC this was used on Skyviper), however that is not used on any of the Pixhawk related builds.

[ghost]

Ok! Thanks a lot for all the details! Much appreciated!

[hamishwillee]

@WickedShell Sorry to necrobump this, but does ArduPilot still have the above behaviour?
If so, it can now report MAV_MISSION_TOO_MANY_ITEMS to indicate that the mission is too big, and IMO it should.

[peterbarker]

How's this relate to MAV_MISSION_NO_SPACE, which we currently use?

[hamishwillee]

@peterbarker Thanks - looks like a duplicate - @DonLakeFlyer - can you please confirm why MAV_MISSION_TOO_MANY_ITEMS is needed if there is MAV_MISSION_NO_SPACE? They sound like the same thing (I missed this).

• Peter, do you actually return this? Does the mission return to it's previous good state?

[DonLakeFlyer]

can you please confirm why MAV_MISSION_TOO_MANY_ITEMS is needed if there is MAV_MISSION_NO_SPACE?

No idea.

[peterbarker]

ArduPilot returns MAV_MISSION_NO_SPACE in the case the MISSION_COUNT packet's contents indicate a mission larger than that we can store. The currently onboard mission (or rally-point-list, or fence set) remains unchanged in this case. https://github.com/ardupilot/ardupilot/blob/master/libraries/GCS_MAVLink/MissionItemProtocol.cpp#L72

This is actually somewhat sub-optimal as it goes purely off count. Technically we could store mission items more compactly - trigger-servo should take less space to store than a waypoint, for example. We do not attempt to use that fact in our current implementation, and it would significantly complicate the protocol as we can't determine whether a mission will fit until it doesn't, and we don't have space anywhere to store both the current mission and the one being uploaded to reject the new one and retain the old one.

Frankly, MAV_MISSION_TOO_MANY_ITEMS doesn't make much sense from an implementation perspective. I reckon you'll always run out of space before a simple item count will be in danger of overflowing. Even then, MAV_MISSION_NO_SPACE covers that if you squint hard enough.

[hamishwillee]

@peterbarker Thanks. I'm going to delete MAV_MISSION_TOO_MANY_ITEMS. PX4 can safely keep uploading until it runs out of memory, but either way, I see no real difference on what a GCS would do if it got one or the other (it should revert to original and invalidate version being updated).

My interest in this is to update the docs on ArduPilot difference from the mission spec in https://mavlink.io/en/services/mission.html#ardupilot

I THINK that based on what you are saying this line is now incorrect: "If you try and upload more items than ArduPilot can store the system will "accept" the items (i.e. not report a failure) but will just overwrite each new item to the same (highest) slot in the mission list."

Instead, if you don't think there is enough space you return MAV_MISSION_NO_SPACE (conservatively). Right?

Would I also be correct that ArduPilot now supports GeoFence and Rally points "to the spec"?

[peterbarker]

@peterbarker Thanks. I'm going to delete MAV_MISSION_TOO_MANY_ITEMS. PX4 can safely keep uploading until it runs out of memory, but either way, I see no real difference on what a GCS would do if it got one or the other (it should revert to original and invalidate version being updated).

Sounds good.

PX4 Firmware actually does pretty much the same as ArduPilot.

My interest in this is to update the docs on ArduPilot difference from the mission spec in https://mavlink.io/en/services/mission.html#ardupilot

I THINK that based on what you are saying this line is now incorrect: "If you try and upload more items than ArduPilot can store the system will "accept" the items (i.e. not report a failure) but will just overwrite each new item to the same (highest) slot in the mission list."

Wow. I've never known that to be true.

Instead, if you don't think there is enough space you return MAV_MISSION_NO_SPACE (conservatively). Right?

Yes. Same as PX4 Firmware.

Would I also be correct that ArduPilot now supports GeoFence and Rally points "to the spec"?

Well... I'm not sure I've read the spec :-)

Strictly speaking we may not be compliant as we have some fun interactions while continuing to support the old protocols. i.e. there are interesting manipulations possible via mavlink which won't be covered in the spec.

[hamishwillee]

Thanks @peterbarker - I'll update that doc though.
My understanding was that PX4 uploads the whole mission into memory (card), runs the mission feasibility checker, then if it succeeds, sets the newly loaded mission as the current mission. This enables a flow where you can fail that upload as OOM with no affect on the current mission. Contrasting with ArduPilot as documented above, where the mission would upload and just overwrite. I have no idea what is right/wrong for this, but I didn't make it up - got the info from either James or Michael DuB. If you're telling me it is different I'd be really happy to update!

Re "to the spec" ArduPilot is probably "compliant" since I understand QGC didn't change and now you're supported. Doing "more than the spec" is usually fine as long as the documented stuff doesn't break. I'll confirm with Don.

[peterbarker]

https://github.com/PX4/Firmware/blob/master/src/modules/mavlink/mavlink_mission.cpp#L851

That's when handing MISSION_COUNT