I have looked through all the parameters but I can’t find a parameter that limits the distance between the aircrafts desired location and actual location. Assuming there is no parameter, this can easily lead to a dangerous situation and has scared the hell out of me a few times.
For example: if you manually command the aircraft full stick forward and the aircraft cannot keep up to the desired location (strong head wind), the aircraft will continue speeding forward at its max set angle to the desired location even after the operator has centered the pitch stick. The temporary work around if you get into this situation is to switch out of loiter mode, but should there not be something to prevent the desired vs actual not to vary by say 5 meters or something?
I have never seen this happen. It will start to pitch back immediately upon stick action and then brake as per the parameters set for Loiter braking. Post a link to a flight log of a flight where this has happened.
BTW-You can set Fence Failsafe action.
Here is a flight I just made. It’s very windy, not that it would make a difference. I apply full pitch forward and it reaches max loiter speed at max angle. I release the pitch stick back to center and it immediately starts pitching back and then brake action occurs.
Hi Dave,
This log should show the issue well. I’m still learning to read logs but I can’t seem to find the desired position data. Regardless this should show the aircraft maintained max angle forward (20 degs) for about 3 seconds after the RC pitch input was returned to center.
Here is the log (1.6Mb): https://www.dropbox.com/s/7dgrs5o5y2wkk00/log_4_2020-5-8-16-50-34.bin?dl=1
The graph clearly shows the issue:
You graph makes sense but it doesn’t show the issue because the aircraft was able to keep up to the desired position. Try setting PSC_ANGLE_MAX to 20 deg so the aircraft can’t keep up and conduct the same test.
Chris
Hi Chris- I graphed a section of your flight similar to mine and I see what you are describing. You are talking about the delay from when you start to move your pitch stick back to center (~92.5s) and the corresponding starting pitch change of the craft at ~95s. And the resulting delay in forward speed. You are moving the stick rather slowly but this can still be seen. Some of this can be addressed right away with some changes to the LOIT_BRK parameters.
LOIT_BRK_ACCELL (I use 350)
LOIT_BRK_DELAY (I use .5)
I’m not suggesting you use my parameters but you can modify yours in steps and check the result.
The other factor is general Tuning and what can be expected based on the size of the craft. It looks like you have done some tuning with PID’s off of default and it looks pretty good. You could revise some of the parameters from the tuning guide:
https://ardupilot.org/copter/docs/tuning-process-instructions.html
What size Octo is this? I fear the craft I used for comaprison is not the best. It’s a finely tuned 210 5:". I should have used a larger craft for this comparison. But, you can make some improvement anyway!
You could try changing
PSC_VELXY_P,2
and see if that makes any difference.
These might help too:
PSC_ACCZ_I,0.457124
PSC_ACCZ_P,0.228562
ATC_THR_MIX_MAN,0.5
I highly recommend you examine and set these:
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
BATT_ARM_VOLT,22.1
BATT_CRT_VOLT,21
BATT_LOW_VOLT,21.6
MOT_BAT_VOLT_MAX,25.2
MOT_BAT_VOLT_MIN,19.8
The MOT_BAT parameters will help scaling PIDs with battery voltage.
The battery voltage was a touch on the low side, like an old battery or low C battery - maybe follow the voltage calibration process to check that your BATT_VOLT_MULT is accurate.
The battery current monitoring is wrong, and will be wise to set this correctly, default for a Cube power brick is 17.0 amps/volt.
If you get the current monitoring correct, you can run the Compass/Motor calibration too, it’s nice to have.
After all that - run an Autotune, even 1 axis at a time. You should be able to get it all working well so AltHold performs really great, then dive into those Loiter parameters.
Our Loiter settings:
LOIT_ANG_MAX,0 (relies on ANGLE_MAX in our case)
LOIT_SPEED,1250
LOIT_ACC_MAX,500
LOIT_BRK_ACCEL,300
LOIT_BRK_JERK,300
LOIT_BRK_DELAY,0.30
And if we wish to fly faster, we use Stabilise or AltHold
Tired playing around with the brakes settings but they have no effect on the issue. This is a 900mm X8.
Shawn: Thanks for also looking into the log. I should have mentioned earlier, this is just a test rig. As mentioned it’s a 900mm X8 weighting about 5kg. The intention of the test rig is to see if Ardupilot is reliable enough and can safely perform for motion picture film work. All our 25-35kg aircraft currently use DJI A2 and A3’s and we really want to try to get away from DJI flight controllers. Reliability and predictability is everything for us.
I just roughly tuned in the gains so I could play around with other parameters and get a feel of the flight characteristics, especially in loiter which is critical for film work. I have a separate power sensor through our radio that I am using on this rig with current.
I don’t believe the issue here is gain related (although I have tried everything already mentioned). Gains change how the aircraft “tries” to get to the desired position. Regardless of gains, if the desired position moves say 100 meter away from the actual position, the aircraft is going to try to go there.
Oddly enough DJI seemed to have solve this issue even in it early flight controllers Naza etc.
I have also noticed this same behavior happens in YAW in any flight mode. If the desired YAW angle gets say 180 degree ahead of the actual YAW angle, the craft will continue spinning to the desired YAW, even if the operator has centered the stick. Once again there should be code to prevent the desired YAW from getting too far from the actual YAW.
@rmackay9 Do you have any suggestions?
Sorry but your conclusions are wrong on many ways.
- Max leash length IS limited to 2meters in the code.
- During the flight when you released the stick the difference of target position and the actual position was around 1.2meters, no more. But the speed was 8m/s
- You had a 1second break delay and a low deceleration (0.125m/s/s) for break. These two things combined caused a slowly ramping on break after you released the stick. As Dave pointed out correctly it is a settings issue not a systematic error in the loiter controller.
Hi Andras,
- Thanks, this is exactly what was interested in.
- This is interesting and makes me even more confused (see next point). Also thanks, you helped me find the positional and velocity data in the logs which I was having trouble finding.
- Unfortunately this makes no sense to me. Regardless of the Brake settings the pitch should back off almost instantly (which the desired vel graph below supports) when the pitch input is centered (not brake, but back off). Even if I set the Brake Delay to 0s and set a dangerously high brake setting, the aircraft will still hold its forward pitch. I’ll conduct another test to show this soon, unfortunately there is a snow storm right now.
The position graph doesn’t seem to show anything, but I believe the velocity graph shows the problem. At about 75 sec the desired velocity starts running away from the actual velocity. Should there not be a leash for this? From about 80-83s even though the pitch input is set back to center the aircraft accelerates towards the desired velocity.
Nope, It is the braking acceleration/deceleration. If look the desired velocity starts decreasing as long as you let the stick go, even before you start breaking. But since the deceleration in the position controller is limited (can be set) as well it needs time to decrease, also when breaking kicks in it also have a breaking deceleration set so it also needs time.
What you saying makes does make sense to me, but can’t there can’t be a leash on DesVel vs ActVel to prevent this run away? As I mentioned, even DJI’s earliest FC don’t experience this 2-3s lag. My only idea of how they did it was a leash on Vel.
I realize you can change the acc/dec of the position controller through PSC_POSXY_P. The issue here is it is a double edge sword. If you increase this gain yes, it does more aggressively slow the desired velocity, but on the other side it more aggressively increases the delta between DesVel and ActVel if the aircraft can’t keep up (ex because of a max angle parameter).
On the contrary, decreasing this gain does limit the delta between DesVel and ActVel, the problem is it decreases the acceleration of DesVel towards ActVel.
Ultimately this leads to a approx 2-3 sec lag (regardless of gains) where the aircraft will continue accelerating forward after the pitch/acceleration command has been relieved.
It is not position and position difference, but the velocity so it should be the POS_VELXY_xxx
BUT before you start tweaking, set LOIT_BRK_DELAY = 0.1 and LOIT_BRK_ACC to 250 to enable immediately hard breaking then check the log about what happening.
I realize this, my last post didn’t say this. It changes the desired velocity curve.
I have tried setting the LOIT_BRK_DELAY=0 and LOIT_BRK_ACC to 500. It has very little effect. It will still maintain forward pitch for 2-2.5sec (instead of 3sec)
Changing PSC_VELXY_xxx has no effect on the issue.
Do you happen to have a log with those settings ?
I fully understand the “reliability and consistency” point of using the DJI flight controller - pick up a remote and away you go - they’re all the same to fly.
Arducopter is so generic it will work on a wide variety of hardware and is able to fly almost anything - However by it’s nature it requires extensive tuning.
I’d still highly recommend setting up battery voltage and current monitoring correctly, and running Autotune. If it’s flying reasonable Autotune should help a noticeable amount - test in AltHold then attack those Loiter settings.
Here is a new flight: https://www.dropbox.com/s/pzcayepej6qknk3/log_283_2020-5-10-11-40-38.bin?dl=1
LOIT_BRAKE_DELAY = 0
LOIT_BRAKE_ACCEL = 500
PSC_ANGLE_MAX = 14
Flight 1:
PSC_POSXY_P = 1.5
PSC_VELXY_P = 1.5
Flight 2:
PSC_POSXY_P = 1.5
PSC_VELXY_P = 4.0
Flight 3:
PSC_POSXY_P = 0.75
PSC_VELXY_P = 1.5
Regardless of gains there is always a minimum of a 2 sec delay before the DesVel meets the ActVel and the aircraft slows down.
Shawn: The aircraft flies amazing in all modes (especially Alt/Stab). It also flies very well in loiter, but this issue doesn’t have to do with rate/angle gains.
It looks to me that the issue is not the stopping but that the actual velocity gets left behind the target when accelerating. Its hard against your 14 deg angle limit so that is what is constraining the maneuverability. So you either need to increase the limit so the velocity can keep up or reduce the PSC_POSXY_P so its not demanding such a high velocity. I think I would advise putting the PSC params back to default and raising the angle limit. You have the loiter angle limit set to 30 but because the PSC limit is lower it is using that.
Hi Peter,
The 14deg angle limit was purposely set low to simulate the aircraft not being able to reach the desired speed (strong head wind for example). I am only doing this because I have space constraints for testing and 30deg makes it move too fast. Regardless of the angle (I have tried 30deg as well) the issue is still the exact same if the aircraft can’t keep up (high wind).
Changing PSC_POSXY_P does not help this issue. As you will see in Test 1 and Test 3 (high vs low POSXY_P gains), the aircraft maintains accelerating forward for roughly the same amount of time after the command to slow down (about 2.5s). You are correct, reducing POSXY_P will reduce the difference between DesVel and ActVel, but like I mentioned in an earlier post it is a double edge sword. This also decrease the deceleration of DesVel towards ActVel which in return sums to the approx same amount of time (2.5s). Without some sort of hard leash between DesVel and ActVel, I believe this delay will always occur regardless of the parameter setup. Maybe a leash isn’t possible or the right way to approach the problem, all I know is it is possible (based on DJI controllers).
This issue will only happen when its prevented from meeting the velocity target due to angle limits. Admittedly it would be nice if it did a better job. I think this is never something you would see in a more realistic flight, in wind you have the integrator term to prevent such a large error in the first place and of course the wind will make you slow down faster.
If you were to hold the stick for a longer time or accelerate smoothly before you release it back to center it should stop as expected.
Andras: I must have changed these after boot up so the correct values don’t show in the log. If you compare the slope of the DesVel curve during acceleration and deceleration, the deceleration curve is significantly steeper meaning there was a high LOIT_BRK _ACCEL (the values I listed above).
I really appreciate all your help, but I think I am going to give up on this one. It’s a limitation of the current code.
Peter I do agree this limitation probably isn’t a major safety concern for most users, but it does come into play for some people like me. For example:
For film work we do lots of “sprints.” A quick move from point A to point B that is 100 meters apart. Many peoples first comment is always, just fly manual or Alt Hold. This isn’t an option. Good GPS/Loiter flight is very important for us. Most of the time, once the aircraft gets 100+ meters away we need it accurately hold is position at point B. No human operator can “manually” do this.
In the perfect world with no wind you would just make sure your LOIT_SPEED is always a little lower than what is possible based on your PSC_ANGLE_MAX and you would never have any concerns. Unfortunately with unpredictable head winds this issue will always persist (with the current code) unless your Max Loiter speed is realllly low and the aircraft will not hit the PSC_ANGLE_MAX limit.