Double storage for rally points and geofence

[KonradRudin]

Solved Problem

If there is an error during uploading of the rally points or geofence, the old fence points get overwritten and are not accessible anymore.

Solution

• Extend dataman to have double storage for rally points and geofence the same way as is already done for missions
• On upload write the uploaded points t othe inactive slot and switch at the end when upload was successful.

Changelog Entry

For release notes:

Feature: Enable double storage slots for rally points and geofence

Test coverage

• Tested in SITL while observing the mission topic when uploading rally points and missions.

[dagar]

What's the memory cost?

[KonradRudin]

@dagar I tested on the fmu_v5x with SYS_AUTOSTART 1100 in SIH:
When using the SDCard:
main:

PR:

When writing mission on RAM:
main:

PR:

So around 200 Bytes for SD Card, an around 4.5 KBytes when mission is in RAM. Do you think this is an issue?

[mcsauder]

The memory cost goes up with each point on the polygon, correct? Factor of N?

[dagar]

Do you think this is an issue?

Nope, just wanted to make sure we're keeping an eye on it (memory is very tight on older STM32F4 boards).

[KonradRudin]

The memory cost goes up with each point on the polygon, correct? Factor of N?

Sorry for the late reply @mcsauder depends on what you mean. For the mission in RAM the memory for the maximum mission/geofence/rally points is already reserved, so there wont be any additional memory cost there (and that is the reason for the difference between this PR and main, since we need to reserve double the storage in memory for geofence and rally points). When the mission is written on the SDcard, the dataman module does not need more memory depending on the mission. The only thing that is taking currently more memory when you upload bigger geofences and rally points is that the geofence and RTL mode cache all the points in memory (mission only caches the next 10 points irrespecitve of length). But that is the same both for the PR and main. So the memory difference is still the same.

[mcsauder]

That makes sense to me. Are you able to demonstrate that a high degree polynomial geofence doesn't create a RAM problem? I haven't tried lately, but that was an issue I ran into.

-Mark

[mcsauder]

Sorry. NM, you've already addressed that.

[KonradRudin]

That makes sense to me. Are you able to demonstrate that a high degree polynomial geofence doesn't create a RAM problem? I haven't tried lately, but that was an issue I ran into.

-Mark

Well not completely but it is hard to check for all the different hardware and configs (the v5x i am testing on has still some margins at least for MC). That's why i checked the relative RAM difference but i do not know how close we already are for the other hardware and configs.

[bkueng]

Looks good, I did not spot anything.

[KonradRudin]

rebased on main