Setting parameters when autonomous / set kalman state

Discussions about autonomous flight in general, regardless of positioning method
Post Reply
Kaiser1401
Beginner
Posts: 7
Joined: Tue Apr 21, 2020 11:36 am

Setting parameters when autonomous / set kalman state

Post by Kaiser1401 »

We are working on an autonomous swarm and I had some trouble where drones seem to hang when certain commands where issued on the drone.
Whenever I wanted to debug via radio / usb connection and the console prints, everything was fine. So this took me a while... ;)

Turns out I was writing parameters

Code: Select all

paramSetFloat()
within my function. When parameters are changed these are reported back to the connected client. This function blocks! If there is no client it will wait till there is one.

Is there a reason the clientupdate is implemented blocking? Also found the compiler switch to deactivate this (define

Code: Select all

SILENT_PARAM_UPDATES
), still I do not see the reasoning for the blocking.

What I am trying to do in the first place is setting the state estimation to a new value (e.g. not providing a meassurement but actually overwriting the internal state). Is there a nicer function than setting the

Code: Select all

("kalman","initial*")
parameters and thereafter

Code: Select all

 ("kalman","resetEstimation")
?

( PS: it would be nice to have a way to have "inline" BBCode for fixed width fonts to refer to functions in text rather then blocks. )
arnaud
Bitcraze
Posts: 2466
Joined: Tue Feb 06, 2007 12:36 pm

Re: Setting parameters when autonomous / set kalman state

Post by arnaud »

I do not think this function was meant to be blocking. What is happening is that when you set a parameter from inside the Crazyflie, it sends a packet to the client with the new value. If no client is connected, the packet TX queues become full and so the function blocks until it can put its packet in the queue. This is to keep the original assumption about parameters: they can be read once by the client and they are not changing dynamically in runtime. This packet allows the client to still keep track of changing parameter.

So, for your use-case, the SILENT_PARAM_UPDATES build flag seems like a good one to use. Another solution would be to not send these packet if no client is connected, they are only needed if someone is connected over CRTP anyway so I think this would be an OK behavior.
Post Reply