# Caveats using Spline Waypoints

Problem #1 - If you set spline waypoints #1 and #2 let’s say 4 miles apart at 200 ft altitude, and if the 3rd waypoint is 20 ft away from wp #2 and 400ft higher, your drone will descend into trees while traveling to wp #2.

Problem #2 - The distance indicator in MIssion Planner in the top left corner of the map does not include a spline’s track. Instead, it is showing the straight line distance between each point. So, in a mission using splines that is actually 12-13 miles long, the indicated distance can be as low as 10 miles.

I think these are 2 critical oversights since it’s possible to not notice both issues until you’ve lost a drone and then thoroughly investigate the cause.

It’s not a bug it’s expected behavior. The Spline Function is fit to both horizontal position and altitude. So just as your horizontal position track has to be considered for Spline Waypoints so does altitude. In the example given changing WP #3 to a standard Waypoint will prevent a drop in altitude between 1&2 because it’s not considering WP #3 in the solution. Running some of these scenarios in SITL and viewing the resulting KMZ can be quite enlightening. Picture a roller coaster track in 3D space…

Keith, this is not a critical oversight, except in flight planning. When flying splines it is in 3D space and the mathematical spline applies in both the horizontal and vertical planes.

So when flight planning, due to the nature of mathematical splines, it is not a wise choice to fly long spline tracks without inserting intermediate waypoints, or using a combination of regular and spline waypoints, to shorten the spline curves.

In your flight planning example you used a non-uniform spline with the knot vectors piled up on one end, causing a parametric curve into terrain. A spline is an interpolation, where in this example the knots establish a spline of three cubic polynomials and triple knots at both ends ensure interpolation of the spline path to be linear at the end points. And note the equidistant spacing of the knots.

This is basic navigation in full size aircraft, or marine, using mathematical spline tracks. I suppose it could be possible for the ground stations to pop up a warning if a user establishes a spline track with sharp curves using non-uniform splines. But there is only so much code that can be piled on to try to catch every mistake a user might make.

I understand. My point is, where is the indication that the curve can descend into terrain? Or that there is a vertical curve at all that first goes down, then up? The documentation states “(both horizontally and vertically)”… that’s the extent of the detail. I think a little more documentation/warnings are warranted considering how critical both issues are.

The example I gave does not need to be that exaggerated, since in that example, the copter will descend into trees in the FIRST MILE of the 4 miles… that’s how large the curve is (ask me how I know)

I agree that the wiki could be a bit more explanatory on the use of spline waypoints, and the proper way to apply them.

Calculating a flight trajectory below ground might be not a bug technically, but it is definitely not good airmanship

May be add some kind of minimum safe altitude parameter?

Well, yes. Historically all aircraft crashes end up in a catastrophic discontinuation of controlled aviation with earth

Would also be difficult because some flights start on high terrain and use negative relative altitude values to fly to lower terrain. And terrain following data is only accurate +/- ~30 meters.

It must be realized there is only so much automation can do. In the end the pilot has to be responsible for proper flight planning, and to abort an auto flight and take over manually when it becomes apparent the flight planning was bad, or the automation fails.

There is no limit to the number of waypoints you can use for an auto flight. So when planning using splines it is prudent to use equidistant waypoints on spline flights to interpolate the spline curves smoothly. In the world of full-size aircraft pilots receive a lot training before he/she is even allowed to touch the controls of an aircraft. In RC this is not the case. So I think the “training” part could be better explained in the wiki on proper use of splines for navigation, and maybe even have some examples in illustrations to show users what happens with improper application of spline waypoints. We strive to produce a professional, commercial-grade autopilot and software suite - we should also always strive to provide good documentation and “training” on how to properly use it. Because what is apparent or obvious to a developer or experienced user, may not be immediately apparent or obvious to a new user. And I think most new users do study the documentation.

So I have to agree with Keith on that point.

You can also run into objects between Spine Waypoints in the horizontal plane if you don’t plan the mission carefully. I don’t think it’s a matter of adding more safeguard features it’s just understanding how the Spline function works. To get a good appreciation for it run some missions in the SITL. Watch the path and the altimeter to get a good feel for what will happen with various Waypoint configurations. Then review the resulting KML to graphically see what happened.

What would be useful is a 3-Dimensional Flight plan screen. Easier said than done no doubt.

Or just get rid of vertical splining. Vertical splining is not only pointless, but also inefficient.

I should say, it’s inefficient to use without a 3D planner, and also dangerous. You can have a spline unintentionally climb several hundred feet than you intended.

Problem 2 is taken care of as of yesterday in mission planner beta.

I have been looking at different drone makers and one told me that the latest version of Arducopter does not support splines… based on what I see in the forum can I assume they are mistaken?

I do seem to see though that it is not available in QGC

Yes, they are mistaken.