Increasing the values of these parameters? Or increase H_COL_LAND_MIN?
Sorry, you will need to wait for Bill. I don’t want to give bad advice here.
It doesn’t appear that takeoff Collective is one of the conditions to set the land complete flag false for the takeoff logic. I looked briefly at his collective set up last night, and didn’t see anything out of the ordinary. I did see the hover collective parameter was set to 0.8 which is pretty high. but I don’t think that factors into the takeoff logic.
It is important that the collective parameters be set up as accurately as possible. You do not want to adjust these to compensate for another problem. For example, improperly setting H_COL_LAND_MIN could cause the landing detection to not work correctly and cause your helicopter crash.
I couldn’t work out what is triggering it in the take unless there is higher frequency spikes I can’t see. We have a secondary check in the land detector that sets the heli code to flying if it goes above take-off collective.
I thought that could be it. If it isn’t we must be just missing the sample. It is hard to tell with so much variation.
But that only works if the aircraft is not in the “taking off” state which is the althold takeoff logic. I don’t think that is true in this case because the aircraft is in the “taking off” state.
Yes, you are right. Sorry.
@Leonardthall @bnsgeyer
Thank you for your reply, but how can I solve this problem? All I can think of right now is turning off the integral control while on the ground, or limiting it to a certain range and only restoring it when the helicopter is off the ground.
Although the helicopter’s vibration was not small, it was able to take off completely normally in stabilize mode, but not in loiter mode. Based on the stable takeoff of the helicopter in stabilize mode, I think the control algorithm can definitely make it take off normally in loiter mode.
Two UBlox F9 GPS modules are used to estimate yaw. Will the GPS Settings affect take-off in loiter mode?
We used a multi-rotor to test the WP_NAVALT_MIN , and the effect was not very good. It seemed that the multi-rotor would drift badly after takeoff, so we were afraid to use it on the helicopter.
@Leonardthall @bnsgeyer
During the take-off phase, can we set a collective pitch parameter to determine whether the helicopter is off the ground when the total pitch of the helicopter is higher than this value?
In addition, I am considering adding a pressure sensor to the landing gear to determine whether the helicopter is off the ground by the amount of pressure on the landing gear. When the helicopter is in the air, the force on the landing gear should be almost zero. That should be very accurate. What changes do we need to make to our flight control procedures if we’re going to do this?
Ardupilot supports weight on wheels sensor on GPIO pins but it has to provide digital output, though both polarities are supported. You can use end stop style switch to detect ground contact.
We would need to make a few changes in the take-off parts of the code.
@Flying2015 Leonard and I will need to discuss these options. As he said, it will require modification of the code for either option to work.
@LupusTheCanine is correct that a weight on wheels switch could be used for landing detection however it is not used to determine takeoff. Even with landing detection, it is another criteria that has to be satisfied in order to declare the landed state. I haven’t gotten into this much but at some point it would be good to redesign the code to just use weight on wheel switch to declare landing but there would need to be some failure logic to go with it. Also it would be prudent to use more than one switch for redundancy. Once the switch was fully implemented then it would be used to declare takeoff too.
1 Like
Thank you for participating in the discussion on this topic. Your information is very valuable.
Yes, this will require some additional modification work.
Yes, I agree with you that it is safer and more secure to judge take-off and landing by multiple conditions.
I have a question about the current problem. Since the helicopter can take off normally in the stabilize mode, whether the take-off algorithm in other modes such as loiter can refer to the take-off algorithm in the stabilize mode.
To avoid improper integral control on the ground, we now take off in stabilize mode, then switch to loiter mode in the air, and then immediately switch to stabilize mode upon landing. This operation process, I do not know whether it can be implemented in code.
I don’t think it can be as the helicopter doesn’t know it is about to land and takeoff logic that internally handles the control loops so they don’t wind up thinks it took off earlier. Besides it always is best to solve problems with hardware (like excessive vibrations) first.
Yes, you are right, the processing accuracy is higher on the hardware. I’m just wondering if the takeoff and landing algorithm in the stabilize mode has any implications for the loiter mode. Because the takeoff and landing in stabilize mode are excellent.
AFAIK logic for keeping controllers in sane state is the same minus position and velocity loops that need to be taken care of for Loiter. The problem is that the helicopter doesn’t know when it is in the air and when not. Since it is unsafe to fly while thinking we are on the ground it is fairly sensitive to takeoff.
In Stabilize mode you are directly controlling attitude so it is fairly easy to take out any integral windup that happened between takeoff detection and actual takeoff, in Loiter you are controlling position and velocity demands and if there is GPS drift it will try to correct that from the moment it thinks it took off so it is harder to unwind them.
Edit: clarified which parts of the logic are similar.
Thank you for your clear explanation. The GPS drift is really the biggest difference.
So can we add the judgment of collective pitch to the judgment of take-off in loiter mode? In loiter mode, the helicopter is determined to be off the ground when the collective pitch is greater than a certain value.