paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] dev branch: change of rotorcraft commands range an


From: Luke Barnett
Subject: Re: [Paparazzi-devel] dev branch: change of rotorcraft commands range and some rotorcraft guidance fixes
Date: Sun, 1 Apr 2012 14:12:01 +0800

Hi Felix,

I tested this today (pulled latest from dev) and the pwm actuators do not seem to be working correctly. When I throttle up all is ok until a little over mid stick and then the motors cutout. Throttle back to around mid stick and they resume again. It seems the supervision_cmd values after this point are being set to less than supervision_min_motor so that is causing them to cut out. If I debug the actuators_pwm_supervision, then I can clearly see that the PWM values for the motors has been set to the SUPERVISION_MIN_MOTOR value.

I did a quick test and hacked the code in supervision_run (supervision.c) to the following

supervision.commands[i] = SUPERVISION_MIN_MOTOR + (0.1 * in_cmd[COMMAND_THRUST]);

and that work as expected with no cutout of the motors at higher throttle.

>From what I can tell however, this should be the same as the previous code as THRUST_COEFF = 256 and SUPERVISION_COMMAND_SCALE in my case would equal (2000 -1030) / (9600 * 256).

Any ideas what the issue may be?

Thanks
Luke

 



On Sat, Mar 31, 2012 at 4:08 AM, Gautier Hattenberger <address@hidden> wrote:
Hi Felix,

In my opinion, there is no reason for two different control loops to have the same gains. In fact I think we should not even use the same names for the variables. I agree it is a pain to declare and configure, but still the "good" way.

Gautier

Le 29/03/2012 23:49, Felix Ruess a écrit :
Hi Luke,

If I'm not mistaken they should now be effectively half of the previous gains in the case of pwm_actuators and stabilization quat_int. The assumption is that the commands were previously from -200 to 200 and I changed them to -MAX_PPRZ,MAX_PPRZ, so 9600/200 = 48 
48 is what I set the new gain scale in the stabilization_attitude_quat_int for... but there also was a GAIN_SCALE of 2 in actuators_pwm_supervision which I got rid off in the process...
but I'm not sure if the commands really had a range of 200 in the pwm_supervision case.

In case of the stabilitzation_euler_int I set a new CMD_SHIFT to 11 instead of 16, so effectively the gain prescaler is now only 32 times as high as before (instead of 48). But I thought it would be better to set them lower instead of changing CMD_SHIFT to 10 and effectively setting the prescaler 64 times as high.
So I guess we maybe should set a multiplier just like in stabilization quat instead of using only a shift (to be able to set it to 48) as well....

But I guess what the best solution would be is to set the gain scales in both cases to such a value that the same commands and gains result in the same final actuator commands. In an ideal  case there would be no need to change the gains at all if you e.g. switch from stabilization euler to quat.
This would need some further calculation of what result you get with which gains, adjusting the gain scales accordingly and of course more testing. But I think that would be best way....

@Gautier, Christophe & co... what do you think?

Cheers, Felix

On Wed, Mar 28, 2012 at 2:16 PM, Luke Barnett <address@hidden> wrote:
Hi Felix,

I'll test this out and let you know how I get on. With regards to the gains, do you have an idea of the expected change for PWM actuators to the gain values that I have already? 

Thanks
Luke



On Tue, Mar 27, 2012 at 10:01 PM, Felix Ruess <address@hidden> wrote:
Hi,

I merged pull request 169 into the dev branch, which means that you will have to re-tune your control gains if you are using the rotorcraft firmware.

This was necessary in order to properly support all kinds of actuators with different ranges without having to resort to hacks and having to set different gains for different actuators.
Now PWM actuators should also work nicely regardless of what stop/min/max values the controllers expect and adaptive hover should be fixed with that as well.
If you are using pwm_supervision actuators, you also need to configure the value to send to the controllers to stop the motors (before that was fixed to 1000us, but that doesn't fit for every controller):

  • cleaned up rotorcraft stabilization and guidance
  • removed not properly functioning nav tracking algorithm
  • same guidance loop for hover and nav (except that nav uses a reference)
  • horizontal guidance (hover, nav) should now be running properly for quaternion stabilization as well

If you have comments, questions or a setup to test this, feedback is always welcome :-)


Cheers, Felix

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel




_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]