Just-in-time flight plan generation or modification

[ivangayton]

Just-in-time flight plan modification

It might be much safer to generate (or modify) the flight plans only after the drone operator has arrived at their intended takeoff/landing site (the drone defines this as the "home" location).

This is difficult for a few reasons.

1. We have a clunky, PC-based method using a USB cable to place the flight plans on the drone controller. This isn't a great thing to deal with in the field.
2. We've written our flight plan generation modules in Python, which isn't awesome for offline use on mobile (there are a few Android frameworks for using Python, but for client-side Web the situation looks very grim).
3. We'd in any case have to be very careful about what we allow drone operators to modify if we want the data to be consistent for processing between multiple flights.

Nevertheless, there are a few reasons why we might need to consider it, mostly related to a user needing to modify things based on site-specific factors or risks. For example:

Home point setting

At the end of a waypoint mission, the Mini 4 Pro returns to a position 30 m above its home point before descending vertically to land. If, for example, the mission is at 120 m, the drone descends smoothly from 120 m to 30 m on the way from the final waypoint back to the home position.

This can pose a problem; if there's an obstacle higher than 30 m such as a TV antenna or power line between the final mission waypoint and the home position, the drone could crash into that obstacle (a mountain or building might be a problem too, but less likely to cause a crash due to the Mini 4 Pro's obstacle avoidance, but that system often doesn't detect wires and antennas).

Our workaround: we create an extra waypoint at the beginning and end of the mission, just above the mission centroid. As long as the operator doesn't take off too far from the centroid of the area being flown, the drone will come down in a near-vertical path. However, if for some reason the operator needs to take off and land far from the centroid (which we've already seen a few times), the problem actually becomes worse (because now the extra waypoints cause extra flight distance/time as well as risk during the gradual descent).

The ideal would be to either:

1. Somehow configure the drone to return to just above the home point at the same altitude as the flight, or
2. Create the start & end waypoints once the user is already sure where they will fly from.

Flightline angle setting for slope or wind

At the moment we're only creating east-west flight lines. This actually isn't necessarily totally bad; it does make for very consistent data when processing multiple flights. I actually think it might be a decent default. However, there are a number of situations in which a different flightline angle would make sense, mostly related to slope and wind.

The drone uses less energy when moving along a level path than gaining & losing altitude. If there's a slope, the most efficient flight path will be along the contour lines of the slope. This is something that we could build in from the DEM, so it doesn't require just-in-time flight plan tweaking.

However, something similar applies to wind; it's generally better to fly perpendicular to the wind than to fly upwind and downwind (both for energy efficiency and for reducing vibration as the drone fights the wind). There's no reliable way to know the wind direction in advance (theoretically we could look up the weather in a given area and take wind direction into account, but that would assume we know more or less exactly when the flight will take place). Again, this is the kind of thing best done when the user is ready to fly.

Unexpected obstacles

The global DEM will not take into account all buildings or obstacles. There are definitely circumstances in which the flight plan would be safer if modified—possibly changing the flightline directions or even removing areas—just before takeoff.

Shortened flight times

We will be calibrating our flight plans to get as much area as safely possible with a single battery. However, people might be experiencing shorter flight times if:

• It's windy
• It's hot (thinner air, more energy to stay aloft)
• They're at high elevation (same, thinner air)
• Their battery is old and partially worn-out

In this case, we probably want people to be able to split a single flight into multiple chunks.

[ivangayton]

I'm not sure how we might approach this!

To be clear, I'm not suggesting we do it now. But I think it would be worth a conversation to figure out what our potential options are if we need to implement just-in-time flight plan modification.

[ivangayton]

Our commercial competition (Pix4D Capture, DroneDeploy, Dronelink, Litchi, and friends) all generate flight plans dynamically on mobile. Which doesn't mean we must do the same, but it's likely going to be an expectation for a lot of users.

[spwoodcock]

Very nice write up - looking forward to solving this challenge 😁

We should definitely research / evaluate our possible options!

Based on what you suggested, a few off the top of my head:

• The first attempt could just be via API, allowing us to use our Python code. It's the easiest approach to get us started. If requiring mobile data is a huge obstacle, then this isn't an option.

• I agree that having the code on the device is probably best:

  • Compiling Python into an Android app frankly sucks. Kivy is the best option I know of, but you can't design a professional looking UI really.

  • Using Python via WASM for web is possible but not optimal. We also have the problem of needing to pre-cache the mobile site while the user has internet (they can't cold start the app out in the field / need to load it at least once).

  • Rewriting the Python code as PostGIS SQL with supporting JavaScript wrappers would enable running via PGLite WASM (postgres in browser, although still alpha/beta tech right now)

  • Writing an Android app entirely in Kotlin, along with rewriting Python code. Well, aren't doing this! 😆

  • Using Flutter, either natively in Dart, also rewriting some logic possibly to Dart or JS. Or we could evaluate using a framework like Flet to basically use our Python code in a Flutter app!

Out of all the options I listed there, long term we should consider the Flutter app, ideally using Flet to reuse our existing Python code.

(I'm sure there are other options too!)

[ivangayton]

Via API seems like the obvious starting point. At this stage, I'm fine with requiring testers to have mobile data.

Postgres in browser? Damn, that sounds interesting! I do like PostGIS a lot...