Hello, I’m new to the forum, but I’ve been spending time with helicopters controlled by Ardupilot for a while. In my opinion, I am interested in the control system background and technique part of the job.
What I’m curious about is that each axis has its own characteristics, its natural frequency and its own damping ratio. Based on this basis, it would be more correct for the time constants of each axis to be different. But when I examine the angle inner loop, I see that only one time constant input is entered. Is there an explanation on this subject? (You can assume that I have detailed knowledge about the use of time constant and similar control parameters.)
@gareth_mark Thanks for pinging me on this. I don’t monitor the other channels as often so I missed this the first time.
As I’m sure you are aware, the aircraft dynamics in the pitch and roll axes for a helicopter are quite different due to the body shape as opposed to a multirotor, where in most cases, the shape of the aircraft is pretty symmetric between the pitch and roll axes. So I don’t have the background on why the control system design choice was made initially to make the pitch and roll axes time constants the same. It could be due to the symmetry of the multirotor aircraft since this code was primarily designed for multirotors. However I believe the reason is really due to the fact that position controller does not consider the heading of the aircraft to determine the requested lean angles. Therefore if the pitch and roll dynamics were different, then it could affect the position controller. It makes sense to keep the pitch and roll dynamics the same. One thing to remember is that the control law design is a model following design and as such, the desire is to not set the time constants to what the aircraft is capable of but to a level that provides good flying qualities, especially with autonomous flight. However the time constants of the model must be within the capability of the aircraft. For example, using a time constant of 0.15 seconds for a large 700 size helicopter may not provide good flight qualities because the aircraft probably can’t achieve a time constant in attitude of 0.15 seconds. Thus, a time constant would be selected that would guarantee the aircraft can meet the dynamics requirements.
Hopefully this answers your question and makes sense.
Thank you very much for your detailed answer. Due to my amateurishness in the forum, I may not have opened the topic in the desired place.
In conventional helicopters, the pitch and roll axes can be considered coincident in most situations. For this reason, even if the time constant capacities are not the same, they can be considered very close to each other. But I know that the yaw axis is not coincident with these two axes (you can correct me if I’m wrong). Therefore, choosing a time constant different from the roll and pitch axes may be good for improving helicopter behavior.
Since, as you said, our main goal is to provide good flight qualities in autonomous flight, my design logic basically consists of knowing or detecting the dynamics of the aircraft well. As a result of this determination, I think that the axes, especially the yaw axis, should have different time constants from each other. For this reason, I think that applying the time constant for the pitch and roll axes to the yaw axis does not cause a problem in a mid-level controller design, but should be in an advanced control system design.
Sorry that I didn’t discuss the yaw axis. I thought you were more concerned about the pitch and roll axes. The yaw axis does have its own command model. Up to and including 4.2, it was a just a linear, acceleration limited, rate command model. The controller would achieve the requested rate by commanding max acceleration (user defined parameter) to get there. After 4.2, I added a first order rate response type to the command model. This is completely different from the pitch and roll axes and has separate parameters for acro and then all other modes. The parameter that defines the time constant for all modes except acro is PILOT_Y_RATE_TC. However this first order command model for yaw is defaulted off when you first load the firmware. You’ll have to change the parameter to have it start working.
I apologize for not explaining in more detail. Of course, I’m generally interested in 3 axes. Thank you again for your detailed response.
I was wondering about setting the time constant directly for the attitude controller rather than via pilot input. Don’t you think it would be more accurate and functional to have separate time constants for the attitude controller rather than the pilot input?
So the time constant for pitch and roll for the attitude controller is set by the user directly in the attitude controller. The parameter
Is ATC_INPUT_TC. This sets the time constant for the first order attitude response type. Pitch and Roll axes in Acro have a similar rate command model to the yaw but the pitch and roll rate time constant is the same but can be set differently from the yaw
