BazookaJoe1900
commented
3 years ago @bresch I have tried the 3rd option. by adding this: ` rate_setpoint += _mc_yawrate_ff2 q.inversed().dcm_z() _yawspeed_setpoint;
But for some reason, when MC_YAWRATE_FF2 parameter get low, I lose authority on Yaw when flying manual. meaning, that though it seems the '+=" is FF and can be reduced or even eliminated it does actually made the control of the YAW itself. Any ideas?
bresch
Describe the bug Notable "bump"s on the actuator output when Yaw is changing. I noticed that reducing MC_YAW_P doesn't really affect the desired yaw rate from the yaw error. Even when its very low or even 0. That leads to 'bump' on the desired yaw rate. The yaw Rate is either 0/max rate (with some extra integral). On some scenario it cause small roll/pitch bumps. On some cases, some altitude bumps. It can be noticed on regular Iris module too as can be seen here: https://review.px4.io/plot_app?log=4e328378-466f-47e7-ba33-e45900ad1878 I debugged a bit and it related to the feed-forward that been set here: https://github.com/PX4/PX4-Autopilot/blob/6b4ccaa53e4e1c7ff45fe057bc2d1745dc7597f7/src/modules/mc_att_control/AttitudeControl/AttitudeControl.cpp#L101
discussed on Slack Here: https://px4.slack.com/archives/C50RWGQMT/p1616248080046600
Bazooka Joe 5 hours ago can we consider that as issue? should I open issue on Github?
Mathieu Bresciani 5 hours ago That's correct, the yaw setpoint only has its first derivative limited. This means that a change of yaw creates a step command in yaw rate. The feedforward was added to improve tracking performances during turns but also transmits the step to the actuators.
Mathieu Bresciani 5 hours ago can we consider that as issue? Well, it isn't a bug. It's how it was designed. There are a few options to improve it (some better than others...): 1) use the VelocitySmoothing trajectory generator to create a nice jerk-limited setpoint (with a smooth feedforward) 2) add a simple lpf to the feedforward parametrized by a time constant (0 would be "no filter" and -1 could be "no feedforward") 3) add a parameter to disable (or reduce) the feedforward (i.e.: feedforward gain)
Bazooka Joe 5 hours ago @mathieu_bresciani First, thanks for response. which of the solutions seems the right one for you? I am not that familiar with the side effects
Mathieu Bresciani 5 hours ago which of the solutions seems the right one for you? number 1 is the best (it doesn't affect tuning and just improves the setpoints) (edited)
Bazooka Joe 5 hours ago I can say, that I see the 'bad behavior' on my drone on case that I am yawing without flying. meaning commanding reposition with NaN on all prameters other than Yaw. (This option is not on QGC/mission planner. But I can PR a "hack" to do that)
Bazooka Joe 5 hours ago You can easily see that on the Iris SITL too (edited)
Bazooka Joe 5 hours ago does option 1 solves that case?
Mathieu Bresciani 4 hours ago Yes, the spike is clearly due to that yaw feedforward