New Parameters at GCS changeable and stored, but are always at ..._DEFAULT in library-code

For a new library I implemented a new group with new parameters as described here:
That’s a clear and easy to understand description and I checked my doing many times, but the parameters still have a strange behaviour:
I can see and change the parameters in GCS (MAVLink and MP) and the changed values are stored/read-back correctly in SITL. But in the library-code their value is always the (correct) …_DEFAULT value.
So it seems to me, that the read-back values are not written to the variables in library. But where is that done? Where should I search for my fault?

There are quite a few traps with parameters, the first index should start at 1, the full length including the prefix should be less than 16 characters. Can you post a link to your code?

Thank you Pete,
My index starts with 0 (as usual…), so I’ll try.
Sorry, my code is still local, so I don’t have a link yet.

@iampete I just pushed my changes:
I tested with SITL on Plane, so it would be great if you could have a closer look at the Plane-files and the AP_Mission_Relative-files in libraries/AP_Mission.

you should be down in the G2 param block, like efi on line 1245/1251 except at the end with index 26. Looks OK apart from that.

I tried it out, but sorrowly no success.

In the meantime I learned, that the ParametersG2 are only for vehicles, not for pure libraries - if I understood right.


It seems that G2 is usable also for pure libs, but it’s working via pointer. Looking for “button_ptr” and “report_send_time” shows an example for AP_Button.

I tried out AP_SUBGROUPINFO, AP_SUBGROUPPTR and g2, but the problem is still existing.
I spent so much time on that problem, so a hint from an experienced developer would be very welcome.

can you push to github again, i will take a look

I dismissed all intermediate versions, because they brought no success.
So my current version is the version on GitHub
I tested on SITL/Plane, so ignore the other vehicles please.

I gave you bad advice previously, you can actually do it all within AP_Mission. This removes the need to change any of the vehicle codes at all (I have only removed the plane changes and not tested the functionality). I have also make the move a enable param so it hides the others if you have it set to zero.

1 Like

To append the parameters in AP_Mission would have been my planned workaround. But without a separate group that hadn’t been smart at all.
In that way you suggested the result is absolutely as wanted. I tested it - it’s working :smiley: :+1:
Thank you very much Pete