Bitcraze Forums

phiamo wrote:If possible ignore it and try using / adapting https://bitbucket.org/phiamo/crazyflie- ... hover_mode
the gui atm forces you to set all axis, and if your controller doesnt have them, it wont work, not sure if it is a req having enough axis or if we just let people live without it ...

Got it!

Curious question though: How come I had to move the config file from ./lib/cfclient/configs/input to ./conf/input after I pulled it? Why are there two directories for input conf files?

guff wrote:Curious question though: How come I had to move the config file from ./lib/cfclient/configs/input to ./conf/input after I pulled it? Why are there two directories for input conf files?

As far as I understand one is the "distribution" folder (if you'd create a distributable version from the sources, anything in there would go in the package), the other is for your local settings.

phiamo wrote:I would love to see if you folks could do some code review, and play around with parameters too.

I did not have the time to look at any detail but I still have some comments:
- The zaccelAverage should be determined during calibration at startup. It is exactly what the accelerometer Z axis delivers on a motionless unit.
- A Kalman filter is not really useful in the case of a system without any known physical behavior. The variance (P) and the Kalman gain (K) quickly approach a constant steady state ( P = 1/2*(sqrt(Q*(Q+4*R))-Q), K = 1-R/(P+Q+R) ). The whole filter then reduces to a simple low-pass filter ( x = x+K*(measured-x) ), similar to the one already used for the noise reduction of the accelerometer readings.
- I think it would generally useful to compensate the battery voltage dependency of the motor control values ( pwmDuty = controlValue * constant / batteryVoltage ).

phiamo wrote:- The zaccelAverage should be determined during calibration at startup. It is exactly what the accelerometer Z axis delivers on a motionless unit.

Agree, i was thinking of the same!

Additionaly the thrust that is applied to the cf manualy when the hover mode is activated during the flight should be kept constant as inital value and the hover mode should only add or substract to that value when the pressure changes and/or there is some z-acceleration.

beat wrote:- A Kalman filter is not really useful ...

Nope it was just there to hide another bug i introduced ;.)

beat wrote:- I think it would generally useful to compensate the battery voltage dependency of the motor control values ( pwmDuty = controlValue * constant / batteryVoltage ).

Yeah that would really be nice, but i am not sure howto find out the constant ,,,

Not sure where you looked in the latest in branch doesnt have the zaccelAverage anymore ...

Good points there!

Also, Philip, I have a question about the significance of this line of code, noticed within commit 3002963 and recent Hover versions, at line 102 in modules/src/stabilizer.c:
Does this make an assumption about the mass of the Crazyflies? I ask because at this value, my Crazyflie can't get off the deck. If I increase it to about 43000, it will hover above the deck. At larger values it hovers at proportionally higher altitudes. I think I understand the intent of the parameter and know it is not intended to set a hover altitude.

This makes me wonder if the approximate mass of the flight article is needed among these parameters. Otherwise, modified Crazyflies, such as those with protective frames, could react much differently than the stock flight article to Hover.

Just a thought!
Rich

Behavior of the latest commit, 2ed723b, is different, with the Crazyflie climbing immediately with the stock parameter set (after updating debug=0).
Rich

rmirwin2 wrote: Does this make an assumption about the mass of the Crazyflies? I ask because at this value, my Crazyflie can't get off the deck. If I increase it to about 43000, it will hover above the deck. At larger values it hovers at proportionally higher altitudes. I think I understand the intent of the parameter and know it is not intended to set a hover altitude.

Yeah this values is atm just for testing there and might be "discovereable" somehow .. i need it as a base so the pid controller doesnt need controll the full 65000 thrust but only a diff to a "ground hovering"

and yes i have build some bumpers too and need to adjust it everytime i fly

so if we could somehow implement that we do not need to set this and the fly finds out values itself, perfect, until then i need smth like that to have a better resolution in the pid controller

The old version was just instable for me, but just tried yesterday evening and with this version I can not get the cf to fly at all. The cf is connected: I see the horizon moving if I move the cf, the pressure values in the console are prinmted and I also see the thrust value in the client when I push my joystick, but the motors don't spin. I updated the firmware and the client.
With the default firmware and client erverthing works as usual.