Ability to use Waypoint actions with curved turns

Ideas & Suggestions
1

My understanding is that when using waypoints with a curved change of direction, the camera instructions don’t work. This because these are “triggered” by the waypoint co-ordinates, for the want of a better explanation.

In order that this functionality is incorporated for such waypoints has consideration been given to: -

Either incorporate an algorithm that will force exact overflight of the waypoint, whereby the curved path passes over the Waypoint

Or to use an algorithm to approximate the halfway point of the curved track, and make that the “trigger” to release the camera instructions?

This would enhance the performance of the application.

2

I would prefer this method.

2 Likes
3

You CAN use the intervalometer to take photos on a curved turns flight. Set it to turn it on at one waypoint and off at the next. It can be set by time or distance. Look for it on the individual waypoint settings, under Interval (just above waypoint actions) or you can have it do photos for the entire mission using Interval in Mission Settings, either on Mission Hub or the app.

4

Thank You DragonFly_Aerials.

I have taken onboard your advice and the clear detail of where to find this.

For sure that would work nicely for photos and I shall certainly try this. I have has a quick look but need to understand a bit more to understand. I have a Mavic Mini and a Mini 2. Maybe this does not work for these small drones??

My comment was more to Video filming where the camera needs to be instructed coincident to the drone being at the way point. Case in point, to take an outward looking continuous view, for a set radius circle, I fly the drone manually from the home point to above all obstructions. Once clear, I set the planned mission in action. The drone flies to the first way point, is instructed to say for 10s to stabilize and ensure it at the way point, then start the camera and flying the circle commences, (in fact circle has 12+2 30° way points, one before and one after the selected view. This allows a rather steady, but not perfect flight, as the first and last points were is starts and stops can be cut on editing. This maybe can be addressed by using your method as a “time-lapse”?

5

Not sure what you mean by 12+2 30°, but if you are flying an orbit around something, you can do it either via an Orbit flight, or use Google Earth and the circle tool, to draw the orbit (click and drag) and then export it as a KML file and import it into a Litchi waypoint flight and drag your first waypoint out to where you are taking off from and drag the last one out to where you want it to go after the orbit. If you set a POI and Use Focus POI, you can fly the orbit looking in and set the height to look up or down, or looking out, or looking forward and flying forward, or looking forward and flying backward around the circle. The Google Earth Method might sound difficult, but it takes seconds to do.

6

Retired graphics engineer here.

This does not seem like a hard problem given that you do know where the path location is in the parametric equation. You have something called the “target waypoint” that you are tracking.

Yes - you are using an unusual curve (I believe to give you C2 continuity) but it is still a parametric. I don’t think you have a better definition of being at the right spot then when the “target waypoint” changes. Given that you have C2 continuity, the answer is good enough.

7

Litchi is using either Quadratic B-Splines or Quadratic Bezier curves for the curved turns at the waypoints. In either case, both are computed using a “t” value that goes from 0 (zero) to 1 (one) to create the curve. You are correct in that it wouldn’t be hard to use t=0.5 to signify that the drone is “at the waypoint”.

I have not checked to see if where the legs of the spline meet the straight flight path has C1 or C2 continuity.

8

I read yesterday that Litchi is using “centripetal catmull–rom spline”. I then looked that up, and it is still a parametric equation, but it doesn’t draw the first and last parts of the spline.

They do keep track of the current waypoint, so it does know t.

BTW - I am not clear why they are not using Beziers since this is what everyone else uses. Believe it or not there is a trivial way to get the location at the midpoint if they were using waypoints. Early bezier renderers used recursive subdivide. Just do the first recursive subdivide, and you would have the exact location of the midpoint.

9

I believe it is DJI that uses the Centripetal Catmull-Rom spline
@wesbarris has a great document that explains this.
https://www.litchiutilities.com/docs/splines.php

10

If that is the case, the solution for Litchi is trivially easy. Just do the first recursive subdivide and you have the exact location.

Here is the code.

11

The exact location of what?

a: Where the drone is at any point in time?
b: Where the theoretical apex of the curve should be?

At what point are you suggesting that the action be triggered if the drone never reaches the coordinates of the mission waypoint?

I apologize if my message sounds ‘rough’ but I dont understand the curve calculations.

12

Hi Sam,

People are suggesting the solution is hard. I am giving them the benefit of the doubt.

My understanding is that an action is triggered when the drone reaches an exact location. If the waypoint is the vertex of a polygon, then drone would reach the point and the action is triggered.

If the waypoint is instead a control point of a bezier curve, the drone would never hit the vertex (unless it is a straight line). So the engineers have declared it a hard problem.

So yesterday I thought why is this hard? If it is a non-standard curve, then changing the code to trigger on the parametric instead of a location would work. I can see why this code would be non-trivial, but not hard. This was my original post.

Then everyone said the curve is a bezier, This makes the solution trivial, since you would not have to change the action trigger code at all! Just make the trigger location set to the first recursive subdivide instead of the waypoint, and you could minimize the code change.

I could be wrong about why this solution is deemed to be hard.

I forgot to mention how recursive subdivide works. The endpoints of the curve are always on the curve, so therefore the drone would always hit the endpoint. The bezier algorithm splits the curve into two subcurve. The endpoint of the first curve is guaranteed to always be on the curve at t=0.5. This is the only location you need to calculate.

Actually the solution is simpler than that.

For a 3 vertex bezier, (b0, b1, b2), the location will be midpoint(midpoint(b0,b1),midpoint(b1,b2))

This point is on the curve at t=0.5, so the drone following a bezier curve will go through this point.