My team is having this problem with the climb rate of our quad-plane in different modes, from what they’ve relayed to me when they fly the plane in FBWA the drone is able to climb at a rate of about 7m/s, but when they try in both auto and FBWB they find it can only climb at a rate of 3m/s.
We are using a Pixhawk cube
Attached are some binary files of the drone in flight and the parameters list the drone had when in flight.
The maximum climb rate in Auto mode is specified by TECS_CLMB_MAX, but this value must be determined by TECS tuning.
In your FBWA mode, you are achieving a climb rate of 7m/s at maximum throttle, but the airspeed is decreasing during that time, so it is safer to set TECS_CLMB_MAX to less than 7.
Thank you for your response, but the team has already tried adjusting TECS_CLMB_MAX, along with TECS tuning.
as for the 7m/s airspeed decrease, this is not a concern for the team, we would only achieve this climb rate when we’re about to collide with an obstacle, thus it won’t be sustained.
In your latest configuration file (Tula Canada Latest Flight Updates.param), both TECS_CLMB_MAX and FBWB_CLIMB_RATE are set to 3. Therefore, it is reasonable that the maximum climb rate is only 3 m/s.
In flight log 00000076.BIN, both TECS_CLMB_MAX and FBWB_CLIMB_RATE are set to 5. The maximum climb rate is approximately 4.8 m/s. And since the throttle at that time has reached 100%, I think this is the limit of the climb rate.
In Auto or FBWB mode, the FC attempts to maintain a constant airspeed, so if airspeed cannot be maintained during climb, the climb rate set by TECS_CLMB_MAX or FBWB_CLIMB_RATE may not be achieved.
Thank you for this information, I’ll present it to my team. I also want to know if there’s a way to override the FC’s air speed limiting the climb rate; I know that a reduction in airspeed is dangerous but the objective is to only climb at this rate to avoid an obstacle in an emergency. So for us avoiding an obstacle that will definitely destroy our plane by risking the plane falling out of the sky is a worthy goal. In the mean time could you let me know what program you used to view this log?
It is not possible to disable the airspeed limit in Auto mode as far as I know. Does anyone know how to make that possible?
Possible solutions:
Switch to FBWA mode for emergencies: Switching to FBWA allows for a large pitch angle (LIM_PITCH_MAX) regardless of airspeed.
Set STICK_MIXING to 1: Even in Auto mode, operating the pitch stick enables the same pitch angle operation as FBWA.
Use an engine with a large thrust: If there is a margin of thrust, a constant speed can be maintained even with a large pitch angle.
I don’t think it makes sense to disable the airspeed limit, because if raising the pitch causes the airspeed to drop, the climb rate will not increase after all.
The purpopse is to maximize the best angle of climb (Vx) for this particular craft to optimize for quickly avoiding terrain. Vx = the target airspeed that results in maximum angle of climb at full throttle. Vx vs. Vy - FLYING Magazine
In normal manned airplanes, you are expected to target a reduced airspeed for a climb. In testing our craft, we determined that we can get the best performance at about 16m/s at full throttle in a climb.
Reguardless, in FBWA we are able to manually induce sustained climbs at full throttle at 7m/s. We’ve even tried using a twin motor plane that is way overpowerd.
In all cases we can never seem to get the craft to climb any better than 4m/s in FBWB or AUTO modes. It sounds like the primary limiter is the airspeed issue. Is there anything else we can test to confirm this or potentially maximize climb rates?
I understood that there is an emergency situation where you want to increase altitude even if the airspeed decreases, that is, you want to gain potential energy at the expense of kinetic energy.
However, I don’t think the current ArduPilot’s Auto mode has a function to deal with such situations. I think Auto mode is a mode that requires you to carefully plan your mission to prevent such emergencies from occurring.
By the way, how about using terrain following mode?
The team has tried with and without terrain following mode already the problem persists.
with regard to the “plan missions carefully” to prevent emergencies from happening, this is meant to be insurance in the event an unforeseen obstacle enters the path of the vehicle. In the scenarios we are running our drone in, having this insurance is paramount.
It does seem though that this is something hardcoded into ardupilot, to alleviate this I’m delving into the ardupilot source code to see if I can modify it to remove this hard limit, does anyone know where in the code this hard limit may exist or have any resources regarding increasing it?
To address Allister, my team is telling me that they’ve tried both of those and they haven’t worked
To address LupusTheCanine ,from what I gather from my team FBWA is a manual control mode, we run our missions in auto mode, so it can follow a predetermined path, controlling it in FBWA is counter to the objective.
If there is any information that anyone has regarding modifying the arudpilot source code directly I would appreciate that.
What are you considering an “unforeseen obstacle”? If this is terrain, planning is the best option. An ounce of prevention is worth a pound of cure. My organization conducts BVLOS flights with larger (+100kg), expensive RPAS, and terrain issues is one reason, of many, that mission planning is so detailed. However if you are flying low, then you may need to look into some kind of active terrain following because unless you are producing your own DEM or DSM you can’t trust the basic Google data.
