Hi PittRBM,
Yeh. I would also want to check the servos before flight and Acro would be an obvious choice. In Copter we always reset the ghost before arming and in doing so ensure there is no I term build up or mismatch between real and ghost. Limiting the error between real and ghost does not prevent I term build up and would not stop the rotor disk hitting the ground.
I suspect that you should not be able to run any controller in the disarmed and pre-spool-up states and your stick outputs should map directly to the maximum throws of the roll, pitch, yaw, and collective output to the mixers. That would enable the pilot to check the servo throws and connections without fear of anything bad happening. The attitude controllers should only kick in when the aircraft may take off. At this point if the pilot gives a command to roll over the aircraft should roll over and put the disk into the dirt if instructed.
Hopefully this will mean there is a clear process that everybody can use, new or experienced, that does not have traps set for people that attempt to deviate from the path.
Is there anything I am missing here. What I have said seems obvious but does not appear to have been done and I assume it is for a good reason or to avoid a particular problem.
I believe a better choice would be to ensure all the initialisation features used in copter are present in heli. I have been working to add features to copter that enable things like spool up states and servo feed through. So hopefully you are able to check the servo movement before spooling up and not excite the attitude controller. These differences between heli and copter are one of the main reason heli is so hard to maintain. Randy and I have already removed much of the heli specific code from the body of Arducopter, I think it is mainly the heli frame in the motors library that needs to be brought up to speed. While I was comfortable to bring all the other frames up to speed Heli is much more complicated and messier. It also requires a deeper knowledge of the code and an understanding of all the little problems and issues that have been avoided and worked around to do the job correctly. It will take me quite a while and a lot of discussion with people before I am comfortable to work on Heli myself.
Coincidentally the attitude controller makes the heli library look like a tic-tac-toe game next to Chess or Go. That is why there are a number of ways to address problems and many more ways of creating them. It is easy to see ways of fixing a problem but much harder to see all the ways that fix can create problems. This is why I insist on a thorough description of the problems, discussion of the possible solutions before attempting to work out the best changes in the code.
To answer your questions (and maybe ask a couple):
I assume you are doing this with the rotor head stationary and not spooled up, is that right? If it was spooled up you would see the whole disk tilt to match the ghost and the error would stay small anyway.
I completely agree. I hope that the initialisation stuff present in copter but missing in Heli would take care of that as I described above.
The problem with this approach is the real aircraft is always a little way from the desired angle. How do we define “unable to reach the desired angle”. More than 10 degrees, maximum output, moving away from the desired angle? Each of these creates different problems from reduced ability to fight a disturbance to jerky movement or potentially complete loss of control. For example if we limited the pitch error to 10 degrees but during forward flight you needed an 11 degree error before the attitude controller would fight hard enough to overcome the pitch up moment. In that case it is a race between the I term limited by Imax and the time it takes to rotate upside down and crash. There are better, easier, safer places to implement these things that I built into the code. We just need to have the discussion so we understand the desired behaviour across all similar situations.
I do appreciate that but from the attitude controllers perspective all it is doing is following that stick swirling as closely as possible given the information it has. Loss of control from the pilot is often not loss of control from the attitude controller. If the attitude controller loses control of roll or pitch then the pilot has no hope. The narrow margin between these points is when the attitude controller briefly loses control of roll or pitch and then regains it again and is working to close the very temporary error between ghost and real. If it wasn’t temporary the aircraft is gone anyway. Stick swirling or not the error should be very quickly reduced to near zero and the pilot inputs should be directly reflected in the aircraft response again.
I hope that explains things…