# What factors affect the minimum time to go from point A to point B?

I've created this trajectory for a small RC aircraft to go from 15m to 61m as quickly as possible (e.g. quickest time to get from point A to point B). I'm trying to perform a sanity check for why the aircraft would go to the lowest allowed altitude to maximize velocity before beginning it's climb. Can anyone provide an explanation for why this would be most time-efficient for this problem?

The reason that the aircraft does not fly lower than 5m is because I set 5m as the lowest possible constraint. If that constraint was not in place, it would try to fly at 0m.

Edit: The reference listed for this type of problem is given as 'J. Betts. SOCS Release 6.5.0, 2007.'. This is an inappropriate place to ask for this, but I have tried searching for whatever this paper/journal this may be referencing and cannot find it. If anyone has any tips/tricks on how to actually find this source, please let me know

• You might consider including the formula(s) you used to these numbers. There are quite a few very smart people 'round here who might spot an error, be able to explain why that formula gives the response you're seeing, or suggest a better alternative. Dec 5 '18 at 19:33
• Unfortunately this was created from a software package with a Matlab interface, and they did not provide the mathematical model. I have contacted the publishers, but they have yet to get back from them Dec 5 '18 at 19:38
• Are your points fixed in 3D space, or are you just fixing altitudes no matter where they are reached? Dec 5 '18 at 20:36
• The altitude points were produced as a response to a control input and then interpolated to form a solid line Dec 5 '18 at 20:46

It looks to me like your airplane, starting with a very low velocity, is trying to climb a height of 46m (61m - 15m).

Because it has a low initial velocity, your basic choices are:

• Start climbing immediately, demanding engine power both for velocity and climb rate, and climbing very slowly.
• Fly level for a period of time to build up velocity, then begin the climb.
• Use gravity and engine power together to get more velocity quickly, then begin climbing at a much faster rate.

The velocity you need to achieve is called $$V_y$$, or best rate of climb. Based on the Yellow color on the main segment of the climb, it looks like this plane's $$V_y$$ is about 26 $$m\over s$$.

It looks like your software package chose #3. While it makes intuitive sense, without the math behind it, I cannot tell you the details.

• Thank you for the response! The only correction I'll make is that the the velocity being traveled in climb is it's maximum velocity, which is 27m/s. Everything else makes perfect sense to me Dec 5 '18 at 20:43
• @RocketSocks22, 27 m/s is maximum velocity during this manoeuvre, but it is way less than maximum velocity the aircraft is capable of achieving. If you let it fly level, it will accelerate until all engine power goes to compensate drag, but then there is no power left for climbing, so at maximum speed for level flight, no climb is possible. Rather, the speed in climb is the minimum drag speed (that is called $V_y$), so maximum of power is left for climbing (drag times velocity equals power, and weight times vertical velocity also equals power). Dec 5 '18 at 21:14
• @JanHudec, 27 m/s is the maximum velocity for this aircraft based on the motors that I am using. However, you bring up a good point that the aircraft will almost certainly not be able to reach this speed while in climb. I am not certain how I can account for this without seeing the mathematical model being used. Dec 5 '18 at 21:20
• @RocketSocks22, NO, the aircraft can't sustain it's maximum level flight speed in climb. Since the climb from 5 m all the way to almost 24 m is constant speed, it is not its maximum speed for level flight. It is the best climb rate (= minimum drag) speed (the final meter and a bit is a zoom climb that trades some of the speed for a bit more altitude, but the rest only uses engine power). Dec 5 '18 at 21:24
• @StephenSprunk, if the craft is initially flying slower than minimum drag speed, then that tradeoff can make sense. The energy loss due to drag is cumulative and isn't ever paid back. The dive allows that drag to be reduced more quickly. Dec 6 '18 at 0:46

The graph itself presents issues as there is no loss of speed once the plane begins its climb.

Assuming throttle setting is constant, this is impossible. The plane starts the maneuver at around 15 m/s. What you need to define is:

1. stall speed
2. weight to thrust ratio of your model
3. best time to climb speed (Vy)

Pulling the plane up at the end to reach altitude would risk stalling and there for would not be very practical in the real world. Your Vy climb will be the maximum RATE (feet per minute) of climb at full throttle. Note this is different from Vx, which is the maximum climb per forward distance covered. Vy is the faster rate of climb.

The climb angle will be a function of weight to thrust (propulsive force) available. Higher thrust will enable an aircraft to hold Vy at a steeper climb angle. Based on your data, Vy seems to be around 24.5 m/s. Notice at the higher angle of climb at the end you start to lose speed. This is drawn correctly. Don't stall! The part where you begin your climb seems to show a climb at a speed greater than Vy, there for is not the best way.

Notice when you fly a Vy, throttle is at full and you control pitch (climb angle) with the elevator to hold a specific Vy speed (around 70 knots in a Cessna 172).

The dive and zoom is used to reach Vy more quickly and is used in GA aircraft, but is not critical to the analysis. You might just as easily start from the ground at 0m/s and take off, climbing out at Vy.

That's an example of an optimization problem, the mathematics of which is a significant field in itself. Your case is similar to the renowned "Brachistochrone curve" problem (see Wikipedia).

• Yes, I was hoping that someone that someone may have seen a similar optimization problem in their time and could point me towards some resources, as the publishers of the software package I am using have not gotten back to me. Unfortunately it seems that this problem may not be encountered as commonly as I thought it would be. I have not researched the Brachistochrone curve, but I will look into it. Thank you! Dec 5 '18 at 20:50
• This is not an answer to the question. It does, however, provide some useful information so it would be good as a comment to the original question. Dec 5 '18 at 23:09