Replies to This Discussion

Permalink Reply by Dan Gray on July 31, 2012 at 11:09am

Here's the screenshot and the TLog and Log files.

Attachments:

• APMLogVisualizerGraphOfTwirlThenRecovery.jpg, 153 KB
• 2012-07-31 08-12-55.tlog, 621 KB
• 2012-07-31 08-40 1.log, 555 KB

• ▶ Reply

DeveloperPermalink Reply by jasonshort on July 31, 2012 at 11:26am

Interesting, thanks. If pulling the throttle low fixed the issue then it is a Yaw Rate I problem.

We went to the Yaw_Rate_I parameter in 2.7, but it's a tricky one. It seems to have built up during that mode and once you go to Stab, it's still there, built up. in 2.7.1 we've reduced the i_max value to cope with buildup. It was too high for what it needed to do. It won't fix this bug, but it will prevent the spinning while in Stab and promote a fast recovery.

I'll look into it.

Jason

• ▶ Reply

Permalink Reply by Dan Gray on July 31, 2012 at 3:17pm

Thanks Jason,

Yes, I've seen integral make things go wrong many times in my line of work!

If I can help you get more data, please let me know.  This afternoon, I'm going to try again but use relative instead of absolute Conditional_Yaw.  I'll let you know what I find out.  

Dan

• ▶ Reply

Permalink Reply by Dan Gray on August 2, 2012 at 9:06pm

Jason and all interested.

I downloaded the code, and figured out how to compile it, so started working on the Condition_Yaw.

And, I do believe I figured out the trouble!

Now I can use the Condition_Yaw commands, so I can do nice panoramas!

I tested both directions and both relative and absolute, and other than in absolute, it does the 

condition_yaw 2 times if it hasn't reached the next waypoint, it appears to work properly.

I've been having trouble with this since I started, and now I'm happy I can use the command.

There were two issues (possibly 3) in the two functions:

do_yaw() and verify_yaw()

In do_yaw(),

1.

I had to set up the variable command_yaw_end if it was doing relative moves.

Not setting it up made it jump at the end of the conditional_yaw.

if (command_yaw_relative == 1){.........

command_yaw_delta = command_cond_queue.alt * 100;

//I added the following lines

if(command_yaw_dir == 1) command_yaw_end = command_yaw_start + command_yaw_delta;
else command_yaw_end = command_yaw_start - command_yaw_delta;
command_yaw_end = wrap_360(command_yaw_end);

//command_yaw_end was not being set in 2.7.1. This made the copter jump at the end. (dpg)

}

2. 

I made Casts to (floats) so the variable command_yaw_time was more accurate, and not zero under certain conditions.

command_yaw_time = (int) (((float)command_yaw_delta / (float)command_yaw_speed) * 1000.0); //casting to floats for precision (dpg)

I'm not sure that the casts are absolutely necessary, probably others may know better than me.

Now this is the BIGGY one that made my copter go twirly in yaw:

In verify_yaw(), the variable "command_yaw_dir" is a byte, and was set to -1 in do_yaw() if ccw.

There was a multiply by the -1, but it actually multiplied by 255 instead, making the yaw go NUTSO!

Here's what I did:

// else we need to be at a certain place
// power is a ratio of the time : .5 = half done
float power = (float)(millis() - command_yaw_start_time) / (float)command_yaw_time;

if(command_yaw_dir != 1) power = 0.0 - power; //dpg ***********NEW LINE

//notice the commented out part of the following line: * command_yaw_dir  That's where 

//the multiply by 255 instead of -1 happened.

nav_yaw = command_yaw_start + ((float)command_yaw_delta * power /* * command_yaw_dir*/ ); //dpg
nav_yaw = wrap_360(nav_yaw);
auto_yaw = nav_yaw;
//Serial.printf("ny %ld\n",nav_yaw);
return false;

Hope this helps!  Maybe it (or something similar) will be in 2.7.2 before long!

Dan Gray

• ▶ Reply