While its great to have an autotune feature, the get there users need to have realiable accurate documentation.
Im not an expert, so i cant write the docs because i wouldnt want others to trust my dodgy advice, but i think i do speak for many with suggestions that can improve the documentation. I think the feature release needs to be improved, im not criticizing im just trying to help with constructive criticism.
After code, documentation is the most important aspect to get right. Code is hard and you can get headaches from it. Doco relatively is easy but it makes things profession and its the part that end users come to read to get help.
Maybe its me but this is the main tuning page that the public sees and it should *always* be accurate and up to date. Every new release that affects performance should require this page to be updated and fixed.
#1
Since people might not always be on the latest different pages should be provided for different versions.
The documentation should include at the top what APM version and it should be dated. At least people will know which page to trust if they have both have dates and APM versions. Simple stuff like this helps users ignore old pages and use the latest and greatest where ever possible. I have read many of the wikis and nearly all are missing this info and if there are any they are too few. This is especially important as every minor release changes how all the params work together.
#2
The main tuning page for example is out of date. The image points to a screen that no longer exists in MP. This is perhaps the main page that all new and not experienced users will read and its really wrong.
The wizard (in MP) no longer exists. Users are going to read this page and not know how to repeat the tips in an up to date MP.
#3
Many major parameters are referenced using English while the code uses constants. Whenever a param is referenced it should have its constant. Maybe a glossary should map the one to the other. Its not exactly obvious which term is the constant. Given the wizard (in the pic) is gone i often goto the big params list simply because the wizards keep changing and its confusing. Maybe thats just me but thats how i work.
This section in the above wiki is half wrong and useless because of this.
#4
All params should mention how the values work. For param X, higher values do this, lower values do that. Warnings like if this value gets too high eg really big value you copter will go up too fast etc. A range should be mentioned. Many of the tips include ranges that are contradicted by MP.
Sorry to hijack this thread, im just trying to help improve the introductory and help experience for everyone.
Since i wouldnt want to crash people with bad advice, i can help by proof reading or making suggestions to text after an edit where something needs clarification or appears to me to be wrong because it is out of date.
If the team wants me to read all the wikis i would be happy to go over them with a critical eye so they can be correct/improved.
Odd Behaviour during my auto-tune attempt: Once i convinced my APM that we should be able to start Autotune (needed to re-cal my accelerometer) we gave it a shot today.
First off, let me state that the quad flies acceptably in stabilize mode with default tuning.
When i attempted auto-tune, the roll tuning completes without obvious issue. When i see the pitch tuning start I observe something strange - as the motion of the quad becomes more aggressive, it begins to exhibit some coupling of the roll and pitch axis. That is to say, as the quad attempts an aggressive pitch, it also rolls somewhat.
As the quad moved through the routine, to more and more aggressive pitch maneuvers, it exhibited stronger and stronger simultaneous roll response, until the quad actually went unstable and inverted, plummeting quite a ways towards the dirt. Fortunately, i had started with enough altitude that the quad was able to right itself and recover altitude without crashing. Unfortunately, the tuning routine did not stop there! The next attempted cycle resulted in the same effect, only this time, the quad didn't right in time and we hit the dirt.
The question is: Is this coupled motion response a function of tuning? The geometry of my quad? A bad motor or ESC? I see a similar behaviour when i perform a hard yaw maneuver, (hard yaw also accompanied by a roll) and de-tuning yaw did not correct it. Is this precession due to battery being oriented along my roll axis?
Any ideas are apprecieated. Not sure if I'll attempt an auto tune again even after the quad is repaired....
As on future Amazon service using drones for delivery?. My question is regarding the landing with respect to security. I think the best way to make delivery is that the drone is positioned about 10 meters high and release the load from the air to a kind of basket or mesh retention, after user confirmation.
APM 2.0 external GPS with separate antena(u-blox 7N)
433Mhz 3DR radio
motors: Turnigy Multistar 4830 420KV
ESC:Turnigy Plush 40A (no simonK)
batt: Turnigy Nanotech 6S 8000MAh 25-50C 1.1 kg x2= 16 000 MAh
props 14x5 top 15x5.5 bottom(actually is 14x5 on motor 4 and 6,bcs i didnt have anything else,others are broken)
RTF 5kg,70 cm from motor to motor,center of APM is 1cm to front from center of frame
So what changed since my last unsuccesful attempts of autotune...not much EXCEPT
-I DID SWAP MOTOR 4 AND 6 SIGNAL WIRES AND ALSO CHANGE ROTATION of them SO all props on top have a same size and direction(CW)
-ONE OF TwO BATTS(in paralel) I HAD ON FIRST AUTOTUNE TRY IS HAVING A BAD CELL OR TWO(i dunno how,those expensive batts was never under 3.5V per cell and never charged with more than 3A)
-no gimbal,no sonar this time...and my attopilot sensor still have stupid values sometime(90% of time is ok but sometimes is not,ussually if i leave setting to other is ok but mistakes happen when i set to Attopilot 180A..not always..??)
-since i was aware my PIDs are not good i just entered the values someone else in this thread get from autotune of y6(ATTACHMENT)
-now about the PIDS...i must say i was never even close,very big numbers
-my 433 radio stoped working(on my home laptop is perfect 99%,on my field one is not,never above 50%) so i run home with powered y6 to save pids first
- i will try how it flys later today,but from hoovering at home i can tell it is better
Another autotune attempt, this time on a hexa Tarot 680. After parking for a while in AltHold the process started. Took around 3 mins then stopped again. Initial PIDs were not optimal so that's why you can see in the log files how hexa ascends up to 100m. However when everything finished (standing still for 20(?) sec) the copter was switched back to Stabilize and eventually landed, motors were disarmed. When connected to MP via USB there were no new PIDs displayed - just the old numbers.
What could have been wrong? Is it possible that the autotuning was in fact still in progress and the pilot interrupted it? Can you extract the final PID values from the log?
Just wanted to add my very good experience with autotune. I had run it for 3-4 times already and the results are very good. Copter is absolutery steady with the recommended PIDs. I will check how it behaves when Stabilize P are a bit lower than final 8.85, that seems (and also feels) a bit too high. But it's good to know where is the limit of the frame.
However may I kindly ask anyone skilled to check my thread on copter ascending rapidly after swift moves in AltHold or Loiter? The thread is here:
And it seems that it's not just me with rather not typical TBS Discovery clone seeing this issue. Unfortunately this issue prevents me from using AltHold and Loiter modes, e.g. effectivelly from easy FPV flying.
Thanks in advance for any comments. And thanks once again for all this great work you are doing for the ArduCopter project.
Result of my recent AutoTune w/3.1RC7. Rock solid:
I gave another try to Auto Tune with rc7 and this time it failed. The roll axis tuning seems to be fine but pitch axis failed on the first step of calibration. From the log it looks like it hit the bottom limit of rate_p (0.02) on this axis. There was a little breeze (5-10 km/h max), can it be the reason for this auto tuning failed ? The quad (qav400) is pretty powerfull, about 1kg on 4S with 1000 kV motors, may it be a problem for autotune?
I just tried the rc5 and the auto-tune worked perfectly. I think everything is working fine but holding the altitude in alt_hold and loiter. My quad losses altitude when I move it forward/backward/right or left. Is this normal? I think version 3.0.1 have this bug.
I've just had my first attempts with Autotune on -rc7... unfortunately unsuccessful so far. Dataflash log for one of the flights is attached, IMU logging was also turned on in this log and I have other logs without it.
I can see from the logs that Autotune reached the minimum rate P value and so this is why it must have stopped. I'm not sure why it would have done so, though.
This is on a DJI F450, with stock ESCs / motors / DJI 10" props. The APM is mounted on an O-ring suspended platform to which it is fixed with moongel. The o-ring coupling is very short so I would be surprised if this was too soft. The weather was pretty much flat calm. I tried in both Stabilize and Alt Hold modes.
It normally flies pretty well (to my eyes) with Rate P ~0.175 and Stab P at 4.5, although I have recently manually set Stab P to around 6.5 and Rate P to around 0.15 seeing as moving the numbers in these directions seems to be the most common result of Autotuning.
Any ideas on why Autotune was failing here would be welcomed!
In other news, Drift mode is awesome! Makes me look like a far better pilot than I am ;-)
Replies
While its great to have an autotune feature, the get there users need to have realiable accurate documentation.
Im not an expert, so i cant write the docs because i wouldnt want others to trust my dodgy advice, but i think i do speak for many with suggestions that can improve the documentation. I think the feature release needs to be improved, im not criticizing im just trying to help with constructive criticism.
After code, documentation is the most important aspect to get right. Code is hard and you can get headaches from it. Doco relatively is easy but it makes things profession and its the part that end users come to read to get help.
http://copter.ardupilot.com/wiki/tuning/
Maybe its me but this is the main tuning page that the public sees and it should *always* be accurate and up to date. Every new release that affects performance should require this page to be updated and fixed.
#1
Since people might not always be on the latest different pages should be provided for different versions.
The documentation should include at the top what APM version and it should be dated. At least people will know which page to trust if they have both have dates and APM versions. Simple stuff like this helps users ignore old pages and use the latest and greatest where ever possible. I have read many of the wikis and nearly all are missing this info and if there are any they are too few. This is especially important as every minor release changes how all the params work together.
#2
The main tuning page for example is out of date. The image points to a screen that no longer exists in MP. This is perhaps the main page that all new and not experienced users will read and its really wrong.
The wizard (in MP) no longer exists. Users are going to read this page and not know how to repeat the tips in an up to date MP.
#3
Many major parameters are referenced using English while the code uses constants. Whenever a param is referenced it should have its constant. Maybe a glossary should map the one to the other. Its not exactly obvious which term is the constant. Given the wizard (in the pic) is gone i often goto the big params list simply because the wizards keep changing and its confusing. Maybe thats just me but thats how i work.
This section in the above wiki is half wrong and useless because of this.
#4
All params should mention how the values work. For param X, higher values do this, lower values do that. Warnings like if this value gets too high eg really big value you copter will go up too fast etc. A range should be mentioned. Many of the tips include ranges that are contradicted by MP.
Sorry to hijack this thread, im just trying to help improve the introductory and help experience for everyone.
Since i wouldnt want to crash people with bad advice, i can help by proof reading or making suggestions to text after an edit where something needs clarification or appears to me to be wrong because it is out of date.
If the team wants me to read all the wikis i would be happy to go over them with a critical eye so they can be correct/improved.
Odd Behaviour during my auto-tune attempt:
Once i convinced my APM that we should be able to start Autotune (needed to re-cal my accelerometer) we gave it a shot today.
First off, let me state that the quad flies acceptably in stabilize mode with default tuning.
When i attempted auto-tune, the roll tuning completes without obvious issue. When i see the pitch tuning start I observe something strange - as the motion of the quad becomes more aggressive, it begins to exhibit some coupling of the roll and pitch axis. That is to say, as the quad attempts an aggressive pitch, it also rolls somewhat.
As the quad moved through the routine, to more and more aggressive pitch maneuvers, it exhibited stronger and stronger simultaneous roll response, until the quad actually went unstable and inverted, plummeting quite a ways towards the dirt. Fortunately, i had started with enough altitude that the quad was able to right itself and recover altitude without crashing. Unfortunately, the tuning routine did not stop there! The next attempted cycle resulted in the same effect, only this time, the quad didn't right in time and we hit the dirt.
The question is: Is this coupled motion response a function of tuning? The geometry of my quad? A bad motor or ESC? I see a similar behaviour when i perform a hard yaw maneuver, (hard yaw also accompanied by a roll) and de-tuning yaw did not correct it.
Is this precession due to battery being oriented along my roll axis?
Any ideas are apprecieated. Not sure if I'll attempt an auto tune again even after the quad is repaired....
Hi Randy.
As on future Amazon service using drones for delivery?. My question is regarding the landing with respect to security. I think the best way to make delivery is that the drone is positioned about 10 meters high and release the load from the air to a kind of basket or mesh retention, after user confirmation.
You think your? ?
here we go again..
finally successful AUTOTUNE for my big Y6
APM 2.0 external GPS with separate antena(u-blox 7N)
433Mhz 3DR radio
motors: Turnigy Multistar 4830 420KV
ESC:Turnigy Plush 40A (no simonK)
batt: Turnigy Nanotech 6S 8000MAh 25-50C 1.1 kg x2= 16 000 MAh
props 14x5 top 15x5.5 bottom(actually is 14x5 on motor 4 and 6,bcs i didnt have anything else,others are broken)
RTF 5kg,70 cm from motor to motor,center of APM is 1cm to front from center of frame
So what changed since my last unsuccesful attempts of autotune...not much EXCEPT
-I DID SWAP MOTOR 4 AND 6 SIGNAL WIRES AND ALSO CHANGE ROTATION of them SO all props on top have a same size and direction(CW)
-ONE OF TwO BATTS(in paralel) I HAD ON FIRST AUTOTUNE TRY IS HAVING A BAD CELL OR TWO(i dunno how,those expensive batts was never under 3.5V per cell and never charged with more than 3A)
-no gimbal,no sonar this time...and my attopilot sensor still have stupid values sometime(90% of time is ok but sometimes is not,ussually if i leave setting to other is ok but mistakes happen when i set to Attopilot 180A..not always..??)
-since i was aware my PIDs are not good i just entered the values someone else in this thread get from autotune of y6(ATTACHMENT)
-now about the PIDS...i must say i was never even close,very big numbers
-my 433 radio stoped working(on my home laptop is perfect 99%,on my field one is not,never above 50%) so i run home with powered y6 to save pids first
- i will try how it flys later today,but from hoovering at home i can tell it is better
-logs...hm i hope i uploaded correct ones....
y6autotunedPIDs.jpg
2013-12-05 15-50 12.log
2013-12-05 15-51 13.log
Another autotune attempt, this time on a hexa Tarot 680. After parking for a while in AltHold the process started. Took around 3 mins then stopped again. Initial PIDs were not optimal so that's why you can see in the log files how hexa ascends up to 100m. However when everything finished (standing still for 20(?) sec) the copter was switched back to Stabilize and eventually landed, motors were disarmed. When connected to MP via USB there were no new PIDs displayed - just the old numbers.
What could have been wrong? Is it possible that the autotuning was in fact still in progress and the pilot interrupted it? Can you extract the final PID values from the log?
2013-12-04 12-43 3.log
Just wanted to add my very good experience with autotune. I had run it for 3-4 times already and the results are very good. Copter is absolutery steady with the recommended PIDs. I will check how it behaves when Stabilize P are a bit lower than final 8.85, that seems (and also feels) a bit too high. But it's good to know where is the limit of the frame.
However may I kindly ask anyone skilled to check my thread on copter ascending rapidly after swift moves in AltHold or Loiter? The thread is here:
http://diydrones.com/forum/topics/when-moving-in-althold-or-loiter-...
And it seems that it's not just me with rather not typical TBS Discovery clone seeing this issue. Unfortunately this issue prevents me from using AltHold and Loiter modes, e.g. effectivelly from easy FPV flying.
Thanks in advance for any comments. And thanks once again for all this great work you are doing for the ArduCopter project.
Result of my recent AutoTune w/3.1RC7. Rock solid:
Hi,
I gave another try to Auto Tune with rc7 and this time it failed. The roll axis tuning seems to be fine but pitch axis failed on the first step of calibration. From the log it looks like it hit the bottom limit of rate_p (0.02) on this axis.
There was a little breeze (5-10 km/h max), can it be the reason for this auto tuning failed ?
The quad (qav400) is pretty powerfull, about 1kg on 4S with 1000 kV motors, may it be a problem for autotune?
Thanks
2013-12-02 00-33 276.log
I just tried the rc5 and the auto-tune worked perfectly. I think everything is working fine but holding the altitude in alt_hold and loiter. My quad losses altitude when I move it forward/backward/right or left. Is this normal? I think version 3.0.1 have this bug.
I've just had my first attempts with Autotune on -rc7... unfortunately unsuccessful so far. Dataflash log for one of the flights is attached, IMU logging was also turned on in this log and I have other logs without it.
I can see from the logs that Autotune reached the minimum rate P value and so this is why it must have stopped. I'm not sure why it would have done so, though.
This is on a DJI F450, with stock ESCs / motors / DJI 10" props. The APM is mounted on an O-ring suspended platform to which it is fixed with moongel. The o-ring coupling is very short so I would be surprised if this was too soft. The weather was pretty much flat calm. I tried in both Stabilize and Alt Hold modes.
It normally flies pretty well (to my eyes) with Rate P ~0.175 and Stab P at 4.5, although I have recently manually set Stab P to around 6.5 and Rate P to around 0.15 seeing as moving the numbers in these directions seems to be the most common result of Autotuning.
Any ideas on why Autotune was failing here would be welcomed!
In other news, Drift mode is awesome! Makes me look like a far better pilot than I am ;-)
2013-12-01 17-25 26.log
Nice autotune on a HK Hal quad 2830 on 10x5 pprops.
keep up the good work