APM Copter: lag in the sbus decoder (latest PX4IO)

[Marco Robustini]

Today I tried the last master with APM Copter and I noticed a lag on the response of the controls.
A little bad delay, 0.1/0.2 seconds of lag from my sticks input and the quad reaction.
Analyzing the flashlog I noticed that there is no delay between my input and the movements of the quad, so I think there is a problem in the last PX4IO.
I tried with FR-Sky X8R sbus receiver (Taranis tx) and Futaba 7008 sbus rx (Futaba T14SG tx), same result, I've not tried yet with a ppmsum rx.
Dongrade the firmware to the official 3.1.2 and all work fine.
Has anyone else experienced this?
For those who make a flew as fast as me, this lag makes the quad ungovernable, I don't know if this will depend on the latest sbus changes or others, I tried without EKF.

Bests, Marco

[Andrew Tridgell]

Hi Marco,

I doubt it is SBus induced lag. I flew master on a plane today several
times, flying in manual, using a SBus receiver (a FrSky X6R). I didn't
notice any lag, and lag would be very noticible when flying fixed wing
in manual.

To test it what I suggest you do is this:

1) connect a SBus receiver to your PX4, but also connect one of the
PWM outputs from the receiver to an input on the APM2

2) connect the same output channel on your PX4 to a 2nd input channel
on the APM2

then load APM:Plane on both the PX4 and the APM2, and setup the PX4 to
be in manual mode, so it is passing input to output.

Then using your transmitter to move that channel. The APM2 will see the
same channel via two paths, one via the PX4 and one directly from the
receiver. Log the two signals, and graph them. Any lag induced by the
PX4 should be very obvious.

Cheers, Tridge

[Marco Robustini]

Thanks Tridge for reply, soon a video here when you can see what i mean.
Excluding sbus maybe the problem is elsewhere but is noticiable here, wait the video in very slow motion.

Cheers, Marco

[Holger Steinhaus]

Hi Marco,

I had exactly the same feeling yesterday. Started to re-tune some gains, but nothing helped. I use an SBus receiver.

Holger

[Robert Lefebvre]

Is this in stabilize mode?

I wonder if the problem is the "smoothing" function now running on stabilize?  There should be some parameters you can change to make it sharper.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marco Robustini]

Hi Holger, yes, 20 minutes for the comparation in a video, stay tuned.

Bests, Marco

[Marco Robustini]

If this issue is related to the new smoothing function please remove this crap from the code, LOL! :-)

Marco

[Randy Mackay]

     crap can be removed by setting RC_FEEL_RP to 100.  That should be the default in any case I think.

-Randy

[Robert Lefebvre]

Yeah Randy, I was just looking through the code, and I saw that it seems 100 is the default.  Check that you have that Marco.

Also, look for a parameter called Accel_RP_Max.  I can't see what it defaults to.  Set it to 100000.

When I set this up originally, it was still possible to get a very sharp response.  But I can't figure out the new algorithm with RC_FEEL, and haven't flown it myself yet.

[Robert Lefebvre]

Ah, oops, it defaults to 54000.  That should be plenty, but try setting it to 100000 just to be sure you're maxing it out.

[Marco Robustini]

Here the video:

https://www.youtube.com/watch?v=YdjrK4xoVGc&list=UUPcCCiqkWYZmvxVgHhDZDHA

I'm busy for a month with the plane version, first test of the copter today and after 10 seconds i've found this issue,
Why the others active testers doesn't found yet? ;-)

Marco

On Wednesday, April 2, 2014 1:03:21 PM UTC+2, Marco Robustini wrote:

[Robert Lefebvre]

I'm not actually flying trunk Marco, I'm still flying a branch based on my initial implementation.  I think nobody else "found" the problem because they actually like how it flies now.  Actually, that is not looking too bad to me Marco.  You're inputting REALLY sharp stick inputs.  You're asking a lot from it.

The idea for the angular rate accel damping, was that copters which are tuned with really aggressive PIDs for good attitude accuracy in winds, were much too sensitive to really minor stick inputs.  Just the jitter on the sticks, which all humans have, was enough to get the motors jerking the copter around.  This is really bad for video work, as I'm sure know.  It's also the cause of the "bounce back" that you get in acro modes.  

So I was trying to fix all that.  The bounce-back in acro mode happens because you moved the stick faster than the copter can possibly accelerate the pitch or roll.  So an error builds up, and after the motion stops, the controller fixes the error.  With the way I had done it, you could tune the acceleration rate to something quite high.  It would still feel crisp, but you wouldn't be capable of asking the copter to do something it couldn't do.

Here's a video of from when I started all this.  In the video, the code is active on the roll axis, but not pitch.  And I didn't learn until recently, that there was a bug which meant it was only *decelerating* at about half the rate it should, so the stops were a bit softer.  Anyway, you can see the copter still responds sharply.  And you can hear the difference in the sound of the motors on the pitch axis.  They are too sharp.  It's very jumpy and hard to control pitch smoothly like that, but it fights winds really well.  The roll axis has the same PID gains, but is much easier to control.

https://www.youtube.com/watch?v=ROnwYCZReDs

This also helped smooth out Stabilize mode.  If you have a camera ship, you could lower the accel rates to smooth out the motions of the copter.  You could run very high PID's to fight winds aggressively, but it would prevent you from jerking the copter too hard, upsetting the gimbal.  However, using low values, would lead to a lag if you input sharp inputs.  But really, this is up to the user to tune these.  If you want smooth for a really big octo carrying a big camera, you use 360 deg/sec/sec.  If you want sharp, you could use 1080 deg/sec/sec, which is about as much as any multi-copter can do anyway.  Heck, you could set it to 2000 deg/sec/sec if you wanted, which is 3D Helicopter territory.  The algorithm couldn't *make* the copter do what you ask, but it would make it *try*. 

About the same time, Jason came up with a different concept, which I believe was simply a low-pass filter on the RC Input to smooth the pilot's commands.  This can also create a lag.  I don't know what his filter frequencies were.

Then, Leonard combined both ideas into a single implementation, and that is what you are flying.  I don't think it's "crap", but might just need to have it's parameters set to something you like.  Maybe RC Feel of "100", whatever that is, is not high enough for you.  For sure, you should try increasing the acceleration rate to 108000 from 54000.

Back in February, I forwarded some comments to Randy and Leonard from when I reviewed their code.  Among them was:

2) Get_Smoothing_Gain can only be between 2 and 12, based on rc_feel of 0-100.  Smoothing_Gain seems to be expected to be between 1 and 50 in angle_ef_roll_pitch_rate_ef_yaw_smooth().  Not a big deal as it's dimensionless, but just sayin.

Leonard responded that he thought 12 would be enough, and even that 8 would be as much as most people would want.  I can't really comment, as I haven't flown it, and the numbers are dimensionless.

In addition to changing the accel rate to 108000 (1080 deg/sec/sec), you might also try increasing RC_Feel.  It looks to me like you might be able to push it as high as 480, before the constrain in angle_ef_roll_pitch_rate_ef_yaw_smoth() will limit it.  RC_Feel of 480 will give you the Get_Smooth_Gain of 50, there's a constrain on that above 50.

But I caution, I have no idea how the rest of that function works, I can't follow it.  Something else might break down and fail if you go that high, so proceed with caution.

If you wanted to try my original implementation which has a accel limiting, but no filtering, I sent you that info way back in February, but I never heard anything back from anybody.

Rob

--

[Jason Short]

easy there...

A lot has changed between 3.1.2 and 3.2. The later has the onion and any number of issues could be in the code since all of the control has been refactored. 

The input filter called RC_Feel is completely disabled with 100. 

I have not flown this new code yet, but I'm guessing there are some small issues based on the shear size of the changes.

Jason

[Robert Lefebvre]

Are you sure that it's disabled at 100 with the code in trunk right now?  I don't see that at all. 

[Jason Short]

Ah, it's all gone now and replaced with new code. I take my comment back. It may well be this new code.

Jason

[Marco Robustini]

Hi Jason, yes, download the flashlog in the first post, the problem is not the RC_FEEL.

I can understand that for newbies to have a bit of lag can be useful but I tried to do a bit of flying "sports" in Stabilize and I almost crash twice just because he lost reactivity response.
I tried also to activate the EKF and I noticed two things:

- when the quad go to home and go up to reach the safety altitude i've a lot of twitch in the motors during the climb
- when the quad is returning to the home turn the nose to the waypoint and when is over the home turn the nose in the takeoff position, dunno why if i've WP_YAW_BEHAVIOR to 0


EKF in Loiter and ALT-Hold here work fine with the default parameters, only this twiching during the climb (i think also during Auto mission).

- Marco

[Marco Robustini]

Hi Robert, i don't think to ask anything strange, that only works as before! ;-)
I'm amazed that only Holger noticed it, I've noticed immediately, after more than a month since I was flying with APM Copter, a bit of seconds after the first takeoff and the feeling is "orrible for this", i don't mean for the stabilization/attitude, is really nice with my setup.

Cheers, Marco

[Robert Lefebvre]

Marco, please try the settings I proposed.

[Maurice Barnes]

Marco,

I have been testing latest too and did notice there is a lag but unlike you I actually welcome the change. I can understand that if you havent been following then it would be a shocker. The smoothing out has actually help stabilize the copter as Robert has stated and the aggressive yawing during Auto Missions have also smoothed out coupled with the new Spline code the copter flies like a dream. Maybe you guys could consider a more aggressive profile for say the Acro mode  because there will be Sport fliers out there who need very quick response. I like the idea of the user being able to select the amount of smoothness/responsiveness they would want.

I also noticed the yaw behaviour of facing the direction it was armed in when returning home. I thought this was the way it was supposed to work originally and was just fixed. You are correct that it doesnt matter what YAW behaviour is set to. I will do some more testing later this week.

Regards,

Maurice

[Marco Robustini]

Thanks Maurice for you point of view.
What I mean is that any command against to eventually stop the quad now has a very noticeable lag (for me), but also to get it started.
It's obvious that this thing for shooting video or for taking photos brings no disadvantage, but I am sure that many will notice it when it comes out the 3.2.0 if this thing will not be settled.
I'm a tester, so when I see something strange than before I communicate it, that's all.
Consider, however, that any other electronics (commercial) does not have this lag during the "manual mode", honestly I've not tried in Acro, tomorrow I'll do some more thorough tests.
Another thing I've noticed is a "kick to the quad" when flight mode is changed, were not there before.

Marco

[Robert Lefebvre]

Marco, I guarantee you all the other controllers also have a lag, they have to, it's impossible for anything to be instantaneous.  We have always had some lag.  The question is only "how much lag".  It appears the default parameters are too laggy for you.  Just a matter of turning them up.

[Holger Steinhaus]

Hi Marco,

very good video! I think this is exactly the behavior I see here, even if I fly a very different copter here (it's not nearly as agile as yours is).

I wouldn't say that the copter is unpleasant to fly now. But lags usually add up as the development advances, so it's probably a good plan not to accept any of them without a very good reason.

Holger

[Josh Welsh]

Yeah that’s exactly right.  None of them are instantaneous, but Marco is right to at least bring it up to see if it is expected.  I think this one will be a welcome change, especially for those with cameras and gimbals hanging underneath their copter.

 

Rob you said something earlier that I wanted to get some clarity on since I know we’ve discussed the Acro bounce quite a bit.  Also curious about Leonard’s thoughts here if he has time..

 

The bounce-back in acro mode happens because you moved the stick faster than the copter can possibly accelerate the pitch or roll.  So an error builds up, and after the motion stops, the controller fixes the error.

 

Is it an over-simplification to just “clear the error” out of the control loop as the sticks return to center?  Or, if you wanted to get fancy, reduce the amount of error proportionally to the reducing amount of stick deflection commensurate with the perceived max angular rate of the copter?  That sounds like an oversimplification in the sense we’d be just sort of wiping the board clean on the error, but it’s been bugging me so I thought I’d ask..  You say the controller fixes the error – currently that fix is by bouncing the copter, correct?

[Robert Lefebvre]

Josh, I used to have an algorithm on yaw that did almost exactly what you suggest.  This problem first showed up on yaw (almost 2 years ago) because yaw was the first controller which was rate based, but error tracking.  This was to accomplish a "heading lock" effect.  Roll and Pitch used to be totally open-loop rate control, but about a year ago or so, also became rate based and error tracking, so now they bounce as well.

Anyway, as I said, I had this thing where, if we are actively yawing, it would accumulate errors, and try to fix them, but then as soon as the stick was returned to center, the copter would be commanded to stop, and as soon as it stopped, the error was zeroed out.  So, it would yaw under control, but it would basically stop wherever it was it stopped.  It would not bounce back.  It was in for a little while, but then over-written.

I've actually been thinking about something similar to your other suggestion.  That being that the accumulated angle error in rate mode decays with time.  I believe this is how most flybarless heli controllers work.  I'm not sure if this would actually reduce the bounce by itself.

[Marco Robustini]

I'm used to from 25 years to fly rc model that go where i take them with my thumbs, the feeling with the latest trunk is different, only this I said.
Rob: i fly Mikrokopter and DJI, the sticks responce is immediate.
Tomorrow i try with the parameters you suggested, I hope to resolve this thing, because in my opinion for the "experts" this is a downgrade, if we want to satisfy 99% of users will want to say that I conformer with the new standard, but i don't like it... :P

My two cents

- Marco

On Wednesday, April 2, 2014 1:03:21 PM UTC+2, Marco Robustini wrote:

[Robert Lefebvre]

Marco, there is always a delay.  With direct RC control, it takes some time for the Tx processor to encode the analog signals from the sticks, 21ms to transmit a control frame, some amount of time for the Rx to decode the frame, then send it out to the servos.  Then wait for the servos to actually move... I'd bet you've got at least 50 ms of lag all-in.

My point is just, it's not a question of if there IS lag, because there is always lag.  We just need to make sure that we can reduce it to the point where you are happy.

--

[Marco Robustini]

Sure, i know well the "lag" question in the command, all the tx system for obvious reasons introduce a lag, but for example with Futaba rx and "fast setting" is <4 ms, with others system is 20 ms.
Well, this little time is noticiable if you have more experience, especially if you're a 3d heli pilot.
Now, i know APM Copter is not a 3d heli (LOL) but as I said I preferred to have less lag in the command, as before.
I just asked how to bring it back as before, if possible, then if users will be happy with this new type of controller if I will be myself with them, but i kill Stabilize mode from my copter... ;-)

Marco

[Marco Robustini]

In my system I do my best to keep everything as fast as possible, SimonK firmware, lightweight propellers, tx system with low latency and now i found lag inside the code.
I assure you, today making that video I almost hit the wall on the right, normally I slalom through the trees you see in front of them, now I can not.
This thing will notice the many other, log what I'm writing ... ;)
I remember when V3 code has released, during alpha test i've found in Loiter some "twiching" and many developer told me that could be a problem of my configuration.
After the release a lot of users signaled the same problem and found it was a bug in the code.
Now please take into account this thing because the same will happen soon, thank you.

Bests, Marco

[Robert Lefebvre]

Marco, I understand what you're saying, and I value your input. But I'm telling you, this problem did not exist in my original implementation.  This is now Leonard's code in trunk, I'm just trying to help explain to you what's going on, because I'm not sure when Leonard will respond.  I've tried to help suggest some parameters to change which might help you, but if you can't get it working, then you'll have to talk to him about it.

Please let us know what happens when you try changing them.

[Marco Robustini]

Sure, tomorrow i try again, thanks bro!

Marco

[Randy Mackay]

     Thanks for the feedback.  So if it's not the RC_FEEL_RP then it's probably one of these parameters (as Rob may have mentioned):
           ATC_ACCEL_RP_MAX   -- default is 54000
           ATC_RATE_RP_MAX  -- default is 18000

     My guess is it's the first one.  They're both floats so you can make them as big as you'd like.  Maybe double or triple them to see if that helps.

     If that doesn't help then we will have to dig into it further and I'm not immediately in a good position to do that 'cuz I'm travelling around a bit with my parents this week and don't have access to my copter.  Still, I'm sure it's something we can sort out before we push out AC3.2-rc1.

-Randy

[john...@gmail.com]

 smooth != lag

Again this topic is showing the growing divide between experienced RC pilots and those that are more interested in UAS point and click navigation.
With to much lag, it is almost impossible to fine control RC vehicles. An experienced RC pilot controls by use of a visual feed-back loop, and instinctive stick movements. Movements learned by many years of experience. There is no "I must now pull the elevator down" thought process, if the copter does an unwanted pitch, the corresponding stick is instinctively moved in the opposite direction without any thought. It then becomes imperative that the copter reacts to this instinctive stick movements as fast as possible to give visual feedback to the pilot. Without this you end up over correcting and having to fight your hard earned instincts.

- JAB

[Marco Robustini]

Superb explanation JAB, is exactly what happens to me in this case!
However if this "smooth" helps most of the users in quiet and safe driving then I conformer to the other, even if I repeat imho, forgive me the word, is a crap.

Marco

[Randy Mackay]

     I think too much is being read into this change.  A lot of additional features have gone into master and there are bound to be issues.  There are even more changes (Parachute, Hybrid) going in over the next few weeks because we're still in the dev phase.

     I appreciate the feedback but when you're testing and turrning up issues please remember we are not yet in pre-release testing phase so it'll take some time to sort things out.

-Randy

[Robert Lefebvre]

I don't think anybody ever said smooth = lag.  LPF = lag, that much is true.  And bounce_back != smooth, that is also true.  The trick is trying to improve smoothness, without introducing lag.  What we had before this change, made it impossible to be smooth, even with a good pilot.  Even the smallest movement on the sticks caused jitters in the motors when the PID was tuned up to the max stability.  The only way to make it smooth was reducing the pids, but then it was loose which also doesn't work very well.

--

[john...@gmail.com]

Luckily, lag is very easy to define in this case. Standard RC control is ~50hz, meaning 20ms updates. 20ms also just happens to be the magic number for perceived visual lag in Visual Reality applications. Imagine that.

- JAB

[Marco Robustini]

Thanks Rob and Randy to point me in the right direction, problem solved (apparently).
Tested in flight now and with ATC_ACCEL_RP_MAX to 108000 the feeling is the same as 3.1.2.
I think you can put this value as the default.

Bests, Marco

[Leonard Hall]

Holy crap batman the sky is falling!

This is pre beta people :)

First up I would like to say a couple of things:

- A big first up. Everybody please try to keep the feedback constructive until you understand what the new features are.

- Thanks Marco for your feedback! and... relax I am confident you will like these features once you understand them.

- As far as I can see this isn't lag, it is doing exactly what it is supposed to do.

- These features are designed to improve the performance for the sharpest acro pilot, the gun fpv pilot, the instructor for a new beginner (on the gun acro quad), and the massive camera ship. If you don't understand how this can be true then you have some learning to do. :)

- Finally my whole interest in the control code of Arducopter is to make it possible to squeeze every last bit of performance out of a frame. And I understand I need to do this in a way, that keeps tuning parameters to a minimum, and makes it easy for a beginner to start using arducopter.

First up you should be able to get back to the sharp feel you like by setting:

RC_FEEL_RP to 100
ATC_ACCEL_RP_MAX to 216000 but anything over 108000 shouldn't be noticeable. I would suggest 94500.
ATC_RATE_RP_MAX to 54000 but don't do this on your big copter! I also don't think this parameter is your problem.

This should make things very similar to your original experience.

Ok so what are these parameters doing and how have I chosen the defaults. The defaults are chosen to make a sharp-as-hell copter feel like a stock 3dr quad on the old default setting before we discovered that autotune could turn it into a razor blade. So if you had a sharp-as-hell copter before, expect it to feel like a docile beginner quad.

So how have we done this? There are three layers.

1. RC_FEEL_RP

2. ATC_ACCEL_RP_MAX

3. ATC_RATE_RP_MAX 

1. For the old hats, RC_FEEL_RP is basically an artificial Stab_P. It controls how aggressively the copter reacts to small changes in the stick inputs. A value of 25 will give you the equivalent of Stab_P of 4.5 and a value of 100 will give you an equivalent Stab_P of 12. "12!" I hear you say, "that will make it oscillate". Well, that is the point, it won't. If your value is higher than the copter is capable of, all that will happen is your commanded position will leave your actual position behind and your copter will just do it's best to keep up. 

Why use 0 to 100? That was just to make it easy for people to adjust the way it feels. 

Finally for those of you digging into the physics of motion that we design these control systems around. RC_Feel_RP basically defines the Jerk and therefore stops the hunting around zero.

2. Now the big one, ATC_ACCEL_RP_MAX. This is the maximum acceleration you can request of your frame. If you set this to 18000 it will feel like you are flying the avengers aircraft carrier. I would not recommend going below 36000 and 54000 is a nice number for everyday relaxed flying. Most agile frames, running 10" props, are capable of 100000 to 120000 (on high powered micro quads this could easily double again). How do I know this? Because I have been looking at this on everybodies autotune logs since it was released. This brings me to my next point. The next release of Autotune will set this parameter to something like 75% of the maximum your copter is capable of while staying in control.

Ok, so why did we want to include this. There are 3 basic reasons. Many people were detuning their Stab_P after autotune because they found it too aggressive and fast. Camera ships need smooth movements to get the best video. And finally my favorite, FPV and acro pilots get a slight bounce back or digital feel to acro.

For people that aren't ready or don't like the ultra sharp control afforded by autotune on many copters can make their copter feel like a larger, lower powered copter without sacrificing the stability of a small agile tune. This is where 54000 is a good number.

Camera ships are able to make much smoother movements without relying as heavily on the steady hands of a talented pilot. The camera ship operator is effectively able to control both the Jerk (change in acceleration per unit time) and the angular acceleration with the RC_FEEL_RP and ATC_ACCEL_RP_MAX parameters respectively. The aggressiveness of copter movement can then be controlled to ensure that camera gimbals can stay perfectly level or to remove that last little wobble on very large copters.

Finally Acro and especially FPV pilots, flying in ACRO, can choose ATC_ACCEL_RP_MAX just under what their frame is capable of. What this does is slow the desired point as it reaches the final target. Without this the pilot can request changes in rate the copter is capable of, the result of which is a small overshoot and bounce back. This means that a well setup copter (one that has done autotune) will stop reliably and repeatedly without bounce back or overshoot when performing aggressive maneuvers like rolls or loops. This is where the last little bit of precise control is squeezed out of the copter. This is the pointy end of the stick that all but the most talented pilots won't even notice and even the pilots that do will only be able to describe the performance in terms of confidence or feel. Of course the FPV pilot will be able to pick this up much easier. The most obvious axis that this improves is Yaw.

3. Now ATC_RATE_RP_MAX is the safety net that sits below everything else to ensure the copter is always in control. The two parameters I just described bypass the stabilised controller and feed their commands directly into the rate controller. This provides a very fast response (faster than any other Arducopter release) because we don't need to wait for the position error to build up before the copter reacts. The ATC_RATE_RP_MAX acts on the output of the Stability controller that is working to minimise the remaining error between where the pilot's filtered input says it should be and where it is. 

We choose ATC_RATE_RP_MAX to be a rate we know the copter can safely stop from and again I can calculate this from Autotune. Here I will probably go to something like 30 to 50% the maximum value calculated by Autotune.

This addresses the problem with large copters that fly fine until they are commanded to go from full right 45 degrees to full left. The copter then overshoots and flips. This is being caused by the Stab controller asking for a higher de-acceleration than the copter can achieve because of a large Stab_P value. When correcting small angle errors, say 45 degrees, the copter doesn't build up too much speed. However, when the angle error becomes large the copter is able to get a real head of steam up and it is like comparing the stopping distance of a car from 60 km/h to doing 120 km/h (the stopping distance isn't double, it is quadruple).

The beauty of this parameter in the new system is we are able to set this to very conservative values without compromising the performance of the copter. This value is really only used when the copter is forced away from it's desired attitude by an outside force, impact, or mechanical failure.

Ok, it looks like I have finished my essay just in time for Marco to have worked out the settings without my help but I hope this has explained a couple of things here. Thanks again for everybodies feedback! And remember that the ATC_ACCEL_RP_MAX and ATC_RATE_RP_MAX parameters will be set by Autotune based on measurements of the system. It is only RC_FEEL_RP that is purely a user defined parameter. The defaults for the ATC_ACCEL_RP_MAX and ATC_RATE_RP_MAX parameters should be chosen as safe numbers for everybody to start with and leave autotune to update them or experienced users to tune them as they please.

Ok, this has taken me longer than I thought.

Good night everybody and sorry I didn't discover this earlier!!!

[Maurice Barnes]

Brilliant!!!

[Robert Lefebvre]

Thanks for the explanation Leonard.  I have a question...  autotune doesn't work for helis.  So not sure what to do with the parameters that you say are tuned in auto-tune.  I've just been adjusting them heuristically in my implementation. 

Is ATC_RATE_RP_MAX analogous to the old g.angle_rate_max?  Or something else entirely? 

[Holger Steinhaus]

Hi Leonard,

thanks for this very good piece of documentation :-)

I did some testing with your suggested params, with great success. My copter (15" props, 2100g) is now very agile, never expected that level ;-)

I can confirm that there is no lag at all after rising the ATC_ACCE_RP to 216k

 

ATC_ACCEL_RP_MAX to 216000 but anything over 108000 shouldn't be noticeable. I would suggest 94500.

I noticed a big difference between 216000 and 108000, almost as big as the difference between 50k and 100k. Personally, I prefer the 216k setting.

 

ATC_RATE_RP_MAX to 54000 but don't do this on your big copter! I also don't think this parameter is your problem.

I did not notice any effect after lowering this param (finally down to 2000) - may be there is something not working properly yet.

RC_FEEL_RP to 100

still to be tested 

Holger 

[Marco Robustini]

Thanks Leonard, you are the man!
Now that I have realized the potential of these parameters can not wait to try Acro! :-)
Sorry but I was out of the copter world for one month and i've lost these innovations, big thanks for your excellent explanation, tomorrow i try to tune better my drones following your info.

Regards, Marco

[Leonard Hall]

No problem Marco :) This is so new that only a handful of people have any understanding of this at all and we haven't added the new functionality to autotune yet so this is very early days!

Holger, thanks for the feedback. The best setting for ATC_ACCEL_RP_MAX should be just before it doesn't do anything anymore. But it is interesting that you had to go all the way to 216k before you didn't get any change. You shouldn't see any change when you adjust ATC_RATE_RP_MAX unless you are flying a BIG copter and then the change will be it starts to flip and crash if you make it too big :)

Robert, yeh, heli's will probably need some well chosen defaults. heli's are hard and the absense of autotune is going to make it that much harder to keep up here :(. ATC_RATE_RP_MAX is the old g.angle_rate_max, however because we use feedforward of the desired rate, this no longer limits the responsiveness of the copter to your commands, only how fast the copter corrects an external disturbance.

The other thing I really need to emphasise, this is a MASSIVE rewrite of the core control code of Arducopter followed by a VERY significant upgrade. It is a testament to the quality of Randy's work and the simplicity of onion that we could get this far, so quickly, with so few problems. I fully expect that we will need to do a significant amount of polishing and tuning of the code before we get back to the shine of 3.1.

Thanks again to everybody that is willing to risk your copters to make this code better!!!!!!! and !!!! for good measure :)

Chat soon,

Leonard

[Robert Lefebvre]

Hmmm...  I really need to look at this.  If it doesn't limit the desired rate, that isn't going to work at all for me.  I guess luckily, I've continue to refine my original work, and got rid of the jitter.  So I might just have to plug that in for helis.  But I'm not sure how far down the line the repercussions would be. :(

[frank vitale]

greetings, I just wanted to add that I installed 3.2 on my 650 quad copter with my pixhawk.my first impressions with the default were OMG! No way could I fly this and be happy. I understand the problem marco was talking about I believe but I do not consider a lag well as a big delay like a huge dead band. There was almost a disconnect between when it is in a hover and you start to move the stick before it actually starts to move.it felt actually very strange. After reading all of the notes,and then Leonard explain everything, I've changed my atc acceL an ATC rate from the default and now all I can say is wow! I have been a strict fan of aPM and pixhawk from day one,but always kept a NAZA around because of the way it flies in GPS. All I can say is now is that the naza is out the window. This flies so much better than the naza ever could. The flight on hybrid is excellent. I spent extensive time on doing some tweaking and I am sure when the final comes out it will even be better Although if it stayed as is,I would be one happy person and never change. All I can say is Bravo to all of you developers and all of the extensive time and effort you have put in.the only criticism that I can find so far maybe you can change it maybe you will leave it as it is, would be the throttle acceleration on hybrid mode from half stick on up. It is not aggressive enough for me. Actually that goes for stabilize mode is well but really shows up on hybrid. I tried changing the throttle acceleration and some other numbers and I could not get much better, although it flies well as is.Anyway,thank you for this,as I have been waiting to this.I will say though that disconnect the quarter was talking about, are with me calm a lad was very very troublesome for me in this liked it very much I cannot explain but all I can say was I did not like that feeling at all and I honestly can't see what anybody else would enjoy that but after making my adjustment aTC accel and a atC rate, it was very good. Keep up the good work. Frank.

[Robert Lefebvre]

Hi Frank,

So what did you change ATC Accel  and Rate to that you like?

Try flying something like a 16lb helicopter with an expensive camera on it, and then you will appreciate why some people would like those settings to smooth out the flight.  I use an accel rate of 540 deg/sec/sec on my 600.  On my 450 heli, I have it at 1440!  And it still could be a bit sharper.

But this is why these settings were created.

On 10 June 2014 00:26, frank vitale <rotorboy...@gmail.com> wrote:

greetings, I just wanted to add that I installed 3.2 on my 650 quad copter with my pixhawk.my first impressions with the default were OMG! No way could I fly this and be happy. I understand the problem marco was talking about I believe but I do not consider a lag well as a big delay like a huge dead band. There was almost a disconnect between when it is in a hover and you start to move the stick before it actually starts to move.it felt actually very strange. After reading all of the notes,and then Leonard explain everything, I've changed my atc acceL an ATC rate from the default and now all I can say is wow! I have been a strict fan of aPM and pixhawk from day one,but always kept a NAZA around because of the way it flies in GPS. All I can say is now is that the naza is out the window. This flies  so much better than the naza ever could. The flight on hybrid is excellent. I spent extensive time on doing some tweaking and I am sure when the final comes out it will even be better Although if it stayed as is,I would be one happy person and never change. All I can say is Bravo to all of you developers and all of the extensive time and effort you have put in.the only criticism that I can find so far maybe you can change it maybe you will leave it as it is, would be the throttle acceleration on hybrid mode from half stick on up. It is not aggressive enough for me. Actually that goes for stabilize mode is well but really shows up on hybrid. I tried changing the throttle acceleration and some other numbers and I could not get much better, although it flies well as is.Anyway,thank you for this,as I have been waiting to this.I will say though that disconnect the quarter was talking about, are with me calm a lad was very very troublesome for me in this liked it very much I cannot explain but all I can say was I did not like that feeling at all and I honestly can't see what anybody else would enjoy that but after making my adjustment aTC accel and a atC rate, it was very good. Keep up the good work. Frank.

[Svein Alexander Frotjold]

I have my ATC_Parameters ACCEL AND RATE at 9 000 000 and the copter still don't respond as fast as i would like. RC_FEEL = 1000, ARCO_YAW_P = 10
it's especially yaw that is slow. nothing seems to happen over 180 000 and it still takes about 7 seconds to do 360 Deg yaw.

I have tried increasing ATC_SLEW_YAW also but i cant remember how by how much now. Description says it's only for auto modes

I have also tried setting the ATC_ Parameters to 0 but that left me without control.




I'm running the code with some small modifications but i don't think they make a difference.

[Emile Castelnuovo]

I can confirm te Yaw with default values is re

[Emile Castelnuovo]

I can confirm YAW is really slow with default parameters.

This is with master.

Emile

[Matthias Badaire]

Try setting ATC_FF_ENAB to 1. It solved it for me. It is a new parameter from randy that is 0 by default. See a thread below about this

[frank vitale]

First off let me say then I have not had a complaint about the responsiveness at all. It was the total disconnect feel orthe lag marco was talking about was not a lack of response to me it was like a huge Dead band on the stick.it was like when you move the stick nothing nothing nothing then bam!,it grabs. Tt was just a very strange feel for me,and just could not be enjoyable for me to fly that way. So I adjusted my atc accel to 94500,and rate to 54000. That has gotten rid of that issue for me. and even at those settings I do not get a lack of response. I have been flying 3d helicopters for 15 to 20 years and helicopters since the crickets days with no gyros,and Even if these settings it flies very well for me.I've been flying the pants off of it.If nothing changed at this point I couldn't be happier,3.2 as it is now flies remarkable. Having said that I did try it with my Tarot 810 hexa,fully loaded, and at that weight its still with the default settings had that disconnect feel, and when I change it to the settings I had mentioned, if flies remarkable as well. That lag Marco was talking about, for what I described as the disconnect feel just felt like a huge RC dead band in the sticks that when you first started moving the sticks absolutely nothing happened and then it grabs that is what I was trying to describe it was just a very odd feeling.I I am NOT using the decoder but an orange receiver with sbus,and it works great. I did try it with the decoder and got the same results.again, I want to mention 3.2 flies absolutely flawless for me after making the changes to the settings. I believe the default were around 18,000. Frank

[Leonard Hall]

Thanks for your feedback Frank!

It will take some time and experience to work out how to set these parameters to get the most confidence enspiring feel for people on different classes of copter. It would be nice if the same settings worked for a wide range of copters :)

Keep the feedback coming mate!!

[Arshish Maneckji]

On Wednesday, April 2, 2014 4:33:21 PM UTC+5:30, Marco Robustini wrote:
> Today I tried the last master with APM Copter and I noticed a lag on the response of the controls.
> A little bad delay, 0.1/0.2 seconds of lag from my sticks input and the quad reaction.
> Analyzing the flashlog I noticed that there is no delay between my input and the movements of the quad, so I think there is a problem in the last PX4IO.
> I tried with FR-Sky X8R sbus receiver (Taranis tx) and Futaba 7008 sbus rx (Futaba T14SG tx), same result, I've not tried yet with a ppmsum rx.
> Dongrade the firmware to the official 3.1.2 and all work fine.
> Has anyone else experienced this?
> For those who make a flew as fast as me, this lag makes the quad ungovernable, I don't know if this will depend on the latest sbus changes or others, I tried without EKF.
>
> Bests, Marco

I am so eagre to try this but have only one quad... When will this go to production release?

[Randy Mackay]

Arshish,

     Thanks for your enthusiasm.  No firm date on the final release.  You can try out the latest release candidate (-rc2) using the mission planner's beta firmware's link.  There's a special discussion on diydrones for the beta testers.

          ArduCopter-3.2 beta testing

		ArduCopter-3.2 beta testing Warning #1: PX4/Pixhawk users upgrading from AC3.1.5 (or earlier) should re-do their accelerometer calibration because AC3.2 also uses the backup acceleromet…
		View on diydrones.com	Preview by Yahoo

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsub...@googlegroups.com.

[Marco Robustini]

Hi Frank, i respect your point of view but i'm sorry, with APM Copter 3.1.2 the rc feeling is totally different, is tangible.

Bests, Marco

[Robert Lefebvre]

Marco, have you tried the settings we suggested?  I'm flying 3D with my heli with 1800 deg/s/s.

I can't remember, but do you also have the parameter... ATC_FF_ENABLE turned on?  For some period of time, that was set to off, I'm not sure why.  That definitely is bad, I'm not even sure why it's an option. Could be your problem.

With the settings right, the feel is really no different than 3.1

--

[Marco Robustini]

Hi Rob, yes, ATC is on, but there's lag, but the rc feeling is not like the 3.1.5 release, i'm sure 100%.
Here the ATC parameters of my F550 with Pixhawk:

ATC_ACCEL_RP_MAX,94500
ATC_ACCEL_Y_MAX,20000
ATC_RATE_FF_ENAB,1
ATC_RATE_RP_MAX,18000
ATC_RATE_Y_MAX,12000
ATC_SLEW_YAW,1000

Bests, Marco

[Lorenzo Cascone]

Hello guys, I'm a tester friend of Marco... 

Today i tried last beta (rc4), with ATC disabled the quad was unflyable so under Marco's advice I enabled ATC and flyed with those params:

ATC_ACCEL_RP_MAX,100000

ATC_ACCEL_Y_MAX,20000
ATC_RATE_FF_ENAB,1
ATC_RATE_RP_MAX,18000
ATC_RATE_Y_MAX,12000
ATC_SLEW_YAW,1000

The quad was much better and the feeling is like 3.1.5 but i think that a little lag between radio command and execution is still present, I noticed that doing fast roll changes and in comparison to 3.1.5 there is a little difference. 

There is a fix or It's a problem introduced by the new 3.2 controller?

[Robert Lefebvre]

Keep going up, try:

ATC_ACCEL_RP_MAX,144000

ATC_ACCEL_Y_MAX,36000
ATC_RATE_FF_ENAB,1
ATC_RATE_RP_MAX,36000
ATC_RATE_Y_MAX,36000
ATC_SLEW_YAW,1000

[Lorenzo Cascone]

Tried and it's better than before but with those settings i have a very very crisp feeling and a little lag is still present... Today I re-switched to 3.1.5 and command feeling is totally different, I can't notice any lag and the feeling is smooth as it should be...

[Leonard Hall]

Try setting ATC_Accel_XX_Max to zero and ATC_RATE_FF_ENAB to zero.

You received this message because you are subscribed to a topic in the Google Groups "drones-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/drones-discuss/JUeGZjVJ6GI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to drones-discus...@googlegroups.com.

[Marco Robustini]

Hi Leonardo, is not the right solution.
Me and Lorenzo we have done many tests with ATC_RATE_FF_ENAB to zero, the lag is still present.
There's something different than the 3.1.5, the feeling is totally different, are months that I repeat it, and I reported the problem immediately, I would not be the lead tester if I these things from getting out... :P
But I am sure that 99% of users will not be aware of this problem, only the pilot who have a lot of experience even notice it immediately.
My two cents...

Marco

[Robert Lefebvre]

Then keep going higher guys.

I'm doing 3D Acro on a 500 Heli with ATC_ACCEL_RP_MAX at 180000.  I tried 210000, but that led to an oscillation.  I'm not sure if this is an airframe limitation, or a something in the algorithm.  So try it on a test machine first.

With the way my heli flies with those settings, I have trouble understanding why anybody would be complaining about the feel or lag, other than just to complain...  I'm sorry but... The lag is almost imperceptible, and given the mission of Arducopter, this is not intended for IRCHA 3D competition.

To be more frank, without the filtering, the feel of the copter is so horrible when the PIDS are cranked up to the max, I don't know why anybody would want to turn it off.  It's like driving a 125cc GoKart on a gravel road.  Sure it's sharp and responsive, and fun for a few minutes maybe, but eventually your kidneys start to bleed.  I hated the feel of a really sharply tuned quad without damping.

Marco, specifically, I suspect what Leonard is suggesting, setting ATC_Accel_XX_Max to zero and ATC_RATE_FF_ENAB to zero, probably turns the damping function off completely and should get you back to where you were with 3.1.5.

[Leonard Hall]

No problem mate,

Just making sure I wasn't causing the problem and that people need to set ATC_RATE_FF_ENAB = 0, ATC_ACCEL_RP_MAX = 0 and ATC_ACCEL_Y_MAX = 0 if they want to compare the feel of the current code with previous releases.

If people are already aware of this then I am relieved :)

[Jesus Alvarez]

Leonard.

Is it going to be any changes/improvements on the autotune routines for the 3.2 copter version?

Thanks!