class ParamsRaw ·- how does this work in the Python library?
hamishwillee opened this issue · 6 comments
- IN theory you can send all types here MAV_PARAM_TYPE but you only provide interfaces for a few
- In the Python API how are types managed? Specifically, you can use an API like this to get a real or a bool or whatever, and you know what type it is. However once you have the parameter (an int say), Python doesn't know if it float, int32, uint64 or whatever. So if you store this value and decide to send the parameter again later, how do you "remember" what the type of the incoming parameter was so you can send it appropriately?
So, the plugin only supports float and int32_t and that's explicit given the API e.g. get_param_int, and it will be the same in Python.
Yes. But that doesn't quite answer the question.
Imagine I'm in Python and I receive an int (which at that time I know is an int). Later I go to send a value to that parameter. How do I tell programmatically if I need it send it as an int or a float? I don't think I can query the type at that point, so I need to hold the type somewhere else. The question is really "does the Python API need to do more"?
More generally, if you extend this to support int64_t, would you rename int() to int32() ? If so, might be worth doing now to make it explicit.
I don't think I can query the type at that point, so I need to hold the type somewhere else.
Correct. With the current implementation the user of the API needs to know the param type, so a manual lookup to the param reference is needed. In a later version we might be able to query the param reference or include the file and thus have an API for that but right now we don't.
My point is that when you set a param you need to know what you're doing anyway, what the safe limits are etc. You don't just set params programatically because you know the types.
More generally, if you extend this to support int64_t, would you rename int() to int32() ? If so, might be worth doing now to make it explicit.
Fair point, we'll have to change that.
Great, I'll leave managing change to int32 to your management.
My point is that when you set a param you need to know what you're doing anyway, what the safe limits are etc. You don't just set params programatically because you know the types.
One of its "selling points" of parameter protocol in docs is that the GCS and MAVLInk spec can support autopilot specific parameters without having to know anything about them. While this is true, you're quite right that you can't do it safely, which is why we supply parameter metadata in firmware.
- Does the SDK need to add support to understand particular parameter metadata or is that a higher level thing (and always will be.
- Should a future update of the protocol include sending some/all metadata - ie safe limits on values, etc. My gut feeling is that this is probably very difficult, but would be nice if system could be independent of other paths to get parameter information.
- The thing is that this Plugin is called
ParamRawand notParamSafeForDummies😄. - I think it would be nice if the SDK could get the param meta data either through something like mavlink FTP or http from the drone, or alternatively http from the web, in the same way that we want to do it for the camera definition files.
Initially the goal of the SDK was to enable safe flying with little options. This means that the gazillion of dangerous parameters are actually not exposed and only a small subset is available via setter/getter, like the takeoff altitude which we can set which really just maps to a param. In my opinion the interface to PX4 is way too big, mostly because of all the parameters and we should try to hide and simplify more.
So just because 3DR wanted a backdoor to set a few parameters doesn't mean the SDK needs to become this great PX4 param set tool.
Fair enough! It would be nice to get metadata from the web and have more flexibility, but I do appreciate that is outside of scope (at least for now). Cheers.