Param set_value

[erlingrj]

Hi

I am having trouble understanding how the Param's work. The specific problem is related to the altitude_hold mode, I wanna be able to set the target_altitude myself, via the Python code. I though the easiest way to do this was to add the variable on the PARAM-list and then access it like:

cf.param.set_value("altHolde.targetAlt", desired_alt)

This is not working, firstly, the second argument HAS to be a string, why is that? Almost every parameter has a float/int as value, not a string/boolean expression. Secondly I can't get it to work, to try a simpler and more visual example, i tried to change the thrust through the params.

First I went to firmware/modules/src/stabilizer.c and added

PARAM_GROUP_START(Stabilizer)
PARAM_ADD(PARAM_FLOAT, thrust, &actuatorThrust)
PARAM_GROUP_STOP(Stabilizer)

Then I updated the bootloader and flashed via radio

And then I wrote my code like this:

**first connect the cf and stuff***

cf.param.set_value("Stabilizer.thrust", str(20000))

This yields no result, It really makes no sense to set the thrust as a string, but that's the only possibility. Doesn't the CF read the PARAM-list? If this doesn't work, do you have any ideas for how to read/write to variables like this? More specifically the target_altitude?

thank you

[erlingrj]

let me rephrase a bit. How do I use param.set_value("complete_name", value) ?
If I have a paramtere who's value is a float, how do I set it when set_value demands a string? I know that it should be possible since I can do it using the GUI!

And yes, I have tried to just write the value as a string. Like this:

cf.param.set_value("altHold.targetAlt", "150")

But this does not change the value of targetAlt to 150.

[arnaud]

Hi,

First, for the argument having to be a string I agree it makes little sense, I guess the reason is that cflib has been developed as part of the GUI project and the first thing to use PARAM in the GUI was the list of parameter. This list is filled up and updated using string. It would be fairly easy to modify the function to accept numbers as well and even to test for consistency (we get the type of each parameters from the copter). But even though it is ugly, setting parameters with string is how it currently works.

Setting the thrust like that with a parameter is not really supposed to work. Thrust and other setpoints have to be set using the commander packets. If you don't disable the commander it might overwrite the values.

One way to test the params is to use the GUI param tab and test sending values there. If you want to make sure param is working you can create a new global variable and set it up in param and log. Then with the GUI you will be able to set the value and see in the plotter that it works. You can also set values with your script and then connect the GUI to look at it in the plotter.

I am not familiar with the altitude hold but I guess you will have to first disable the commander thrust update from the altitude control and then set a fixed altitude setpoint instead.

[erlingrj]

Hi and thank you for your reply. I am not sure I made myself completly clear. So Ive made an example. I went to firmware/modules/src/stabilizer.c and added the following

static float teste = 0.0;

LOG_GROUP_START(test)
LOG_ADD(LOG_FLOAT, test, &teste)
LOG_GROUP_STOP(test)

PARAM_GROUP_START(test)
PARAM_ADD(PARAM_FLOAT, test, &teste)
PARAM_GROUP_STOP(test)

Then I hit "make radio bootloader build" and "flash via radio"

The I connected via the client and opened up the parameter tab. This must have messed up something because now I can't change ANY paramters. Ive tried to change a bunch of them, and they all just turn red and pop back to the original value.

The point that I want to make is that I have been uable to CHANGE the parameters via the: param.set_value-function. Take the example over:

cf.param.set_value("test.test", "150") Should set the float teste to 150. But it doesn't, why? There must be something wrong with the syntax, because It would have worked if teste was a bool, and I wrote:
cf.param.set_value("test.test", "True)

[erlingrj]

Okay, so now I somehow made it work. It must have been errors in my previous code that made the bug. Jeeesus Ive spent several hours trying to figure that out.

[arnaud]

Hi,

I tried exactly the same procedure (except that I flash with make cload from console) and for me it works. If you cannot change anything with the GUI client it is certainly related to why your changes does not work with "param.set_value". You can try to launch the client in debug mode with "./cfclient --debug=debug" to see if there is anything suspicious. In your program you can do this to enable debug messages:

Code: Select all

import logging
logging.basicConfig(level=logging.DEBUG)

One other thing to try is to open the config folder (in the gui menu setings/open config folder), and remove all the file under the folder cache. This is where the log and param table of content are cached.

Just to clarify, the setvalue function works that way (I copied one line from param.py:196):

Code: Select all

struct.pack(element.pytype, eval(value))

with element.pytype being "f" in the case of a float and "True" is apparently equal to 1 for python. I played a bit to test the behaviour in the console:

Code: Select all

>>> struct.pack("f", eval("0"))
'\x00\x00\x00\x00'
>>> struct.pack("f", eval("1"))
'\x00\x00\x80?'
>>> struct.pack("f", eval("True"))
'\x00\x00\x80?'

So I don't think param.setvalue is directly responsible for your problem, but something else in the param handling is.

[erlingrj]

Thank you for the help. I downloaded the original repos and tried again, now it works. One of the problems was that one of the PARAMs had a too long name. Turns out that this:

Code: Select all

PARAM_ADD(PARAM_FLOAT, enableAltHoldTargetInput , &enableAltHoldTargetInput)

Does not work, however if you shorten the name, it works

Code: Select all

PARAM_ADD(PARAM_FLOAT, enableTargetInput , &enableAltHoldTargetInput)

Took me a while to figure that out lol

[arnaud]

Glad you got it to work!
If name plus group do not fit in one radio packet it will indeed be a problem, maybe we send an error or something when that happen.