Today I re-tuned my small 3.5" Bee35 and enabled loiter coordinated turns. However… this seems to do excessive rolls when turning.
If my understanding of things are correct I would expect lateral acceleration (Y axis) inside turn to be 0, and just increased G in Z axis, but looks like this is not the case.
Am I missing something, or this turn is not in fact coordinated?
I think that’s what a co-ordinated turn should look like but I, particularly at low speed, do not see this. I am not certain this is unintentional but I haven’t had time to investigate - IIRC the feature was more about the direction of the velocity vector, which is not quite the same thing…
FYI @Leonardthall
This indeed is my experience anecdotally
Now I wonder how coordinated turns are in AUTO and GUIDED modes.
GUIDED and AFAIK AUTO do not attempt to coordinate turns, GUIDED maintains commanded heading and AUTO does configured yaw behavior (keep heading, point at next WP, point along CoG etc.).
I completly vibecoded some changes for loiter coordinated turns, seems small code change, but tomorrow I will have a nice weather with low wind which seems a nice oportunity for yolo flight test 
UPDATE: Well… behavior in flight was a bit strange. Loiter still steady when no input, but when flying straight got small oscillations, however in turn was stable-ish (with Y acceleration close to 0 and no agressive roll at the beginning, but still small oscillations). AltHold works normally. Luckily GPT has some idea why, and rolled back part of changes and leave only one according to - “You were right, let me try again”. Latest GPT finding is that:
Vector3f AC_PosControl::get_thrust_vector() const
{
Vector3f accel_target_ned_mss = get_accel_target_NED_mss();
accel_target_ned_mss.z = -GRAVITY_MSS;
return accel_target_ned_mss;
}
should be more like this:
Vector3f AC_PosControl::get_thrust_vector() const
{
Vector3f accel_target_ned_mss = get_accel_target_NED_mss();
accel_target_ned_mss.z -= GRAVITY_MSS;
return accel_target_ned_mss;
}
Fingers crossed for next Yolo flight
Small update - only with code change from post above, Turn seems to be less aggressive and I do not see initial aggressive roll, but still Y acceleration is not close 0. However I see also improvement in keeping altitude on breaking and turning in loiter with that change.
If anyone is interested, log from flight with change only from post above: https://drive.google.com/file/d/11U_f9WUknhkrRHcIiHgQHem0T9avbFt5/view?usp=sharing
Will probably go back to this issue in 3 weeks, as I have issue with vibrations levels on one of my quads when making non coordinated turns.
Today I did some test using circle flight mode with option to face toward flight direction instead of center of circle.
Looking on IMU[0].AccX and IMU[0].AccY there has to be something wrong with my understanding of those values. Velocity should be constant so why AccX is changing? Also centrifugal force and angular acceleration should be constant, so why AccY is changing? Sine period seems to be 1 full rotation. Would wind explain that? I would not expect slow wind to cause -1g to 1g swing on AccY
That is a smasll 3.5" drone and when loitering before initiating circle roll and pitch was man 1.3deg for roll and -2.28 for pitch.
… because it’s not 1g but 1 m/s^2?
Ok. let’s start with the definition of a coordinated turn.
A coordinated turn will result in the aircraft heading being alinged with the velocity vector.
This is the broadest definition that holds for changing speed and turn rate.
In the case of an aircraft that navigates with a single thrust vector in the body fram z axis this will mean that the body frame y axis acceleration is zero.
Now let’s apply that to a real multirotor using coordinated turns in Loiter. The code applies a lateral acceleration target that is calculated based on the forward velocity and the commanded turn rate. That defines the ideal kinematic path the aircraft will take. This is passed to the position controller and it reacts to any position or velocity errors and corrects them by adding an additional acceleration.
A 1 m/s^2 correction is a 5.85 degree angle offset.
Any change in pitch or yaw command will change the trajectory and the aircraft will need to follow that change resulting in corrections. The same will happen for any wind or external disturbance. Any heading error will move the y axis acceleration away from zero.
This is the pitch and yaw rate:
In a fixed rate turn Loiter is asking for exactly the centripetal acceleration required for a perfect coordinated turn. Any change in pitch or yaw command has 5 controllers all dynamically working together to follow a changing path while dealing with all the imperfections of the real world.
Maybe 5 degrees of roll variation isn’t too surprising
You are right. Had this revelation to myselff tomorrow morning
Yes… After realizing acceleration is in m/s^2 not G I think I was just chasing a ghost.
Only thing that I am wondering right now is why change accel_target_ned_mss.z = -GRAVITY_MSS; to accel_target_ned_mss.z -= GRAVITY_MSS; makes things slightly better especially at the beginning of turn, where roll is not that aggressive. Also, math behind that change seems to be OK, as original code just ignores current z acceleration and replaces it with -1G.
Anyway, I think, topic of coordinating turns can be closed.
Testing in Realflight shows soft 360 degree rotations with a up swing. I always thought of loiter as a way to lock position when making rotation’s for my camera work. Any drift in positions as i see in Realflight is not the desired effect. Having said this I will be trying my new Quad soon testing the results. In my case Realflight has narrowed it down to quads and bi motors that show performance issues.
Baseline video
It represents a complete, full rotation around a single point, forming a perfect circle.
The quad in the video in a 3D printed frame when people said that plastic did not fly well,
